Cloud Config Sanitizer

Why offline?

Kubernetes manifests and Terraform configs frequently contain secrets: API keys hardcoded into environment variables, database connection strings in ConfigMaps, cloud provider bearer tokens in CronJob templates, or JWT signing secrets embedded in Deployment specs.¹² The moment you paste one of these files into an online linter, attach it to a ticket, or share it in a chat for debugging help, the secret is effectively exposed to every system that touches the request.

Browser-only parsing

CapyToolkit runs the entire analysis in your browser using JavaScript. All parsing, pattern matching, and redaction happen locally with the yaml library. No manifest content is ever uploaded, transmitted, or written to disk. You can verify this yourself by opening DevTools and watching the Network tab while you work, and you will see no outbound requests when you paste or drop a file.

Because the tool works fully offline after the initial page load, you can use it on air-gapped machines, in CI pipelines with no external egress, or behind strict network proxies that block third-party services. There are no API calls, no analytics pings, and no tokens stored in localStorage between sessions.

Supported formats

The tool accepts YAML (including multi-document files separated by ---) and JSON.³ You can paste a manifest directly into the input area or drop a .yaml, .yml, .json, or .tf file onto the page. Kubernetes manifests, Terraform HCL-in-JSON, and Crossplane compositions all parse correctly, and the sanitizer detects which format you are using before running any rules.

Input methods

Native HCL (.tf syntax without a JSON wrapper) is not yet supported because the parser relies on standard YAML or JSON deserialization. If your workflow uses raw HCL, convert your files to JSON first with terraform show -json or a similar converter before pasting them here. Once the file is loaded, the sanitizer splits multi-document YAML files on the --- separator and analyzes each document independently so that every resource in a bundle gets its own findings section.

Rule engine

The analyzer walks every string value in the parsed document once and runs through three layers of detection in sequence: provider patterns for known token formats, entropy and key-name heuristics for values that look secret but do not match a known prefix, and then Kubernetes-specific security flags for non-string fields like booleans on a pod’s securityContext. The pipeline runs in a single pass so that large manifests stay responsive.

Provider-specific patterns

Each string value is checked in order against known provider token formats, including AWS access key IDs beginning with AKIA.⁴ GitHub classic personal access tokens begin with ghp_, and GitLab personal access tokens default to glpat-.⁵⁶ Slack access tokens use xox[bprs]- style prefixes,⁷ Stripe secret keys use sk_live_ or sk_test_,⁸ Google API keys use the AIza prefix,⁹ npm tokens use npm_,¹⁰ and Twilio Account SIDs start with AC followed by 32 hexadecimal characters.¹¹

A concrete example ties the rule to the output. A ConfigMap entry reading AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE matches the AKIA prefix pattern and appears in the sanitized manifest as AWS_ACCESS_KEY_ID: __REDACTED_AWS_ACCESS_KEY_1__, with the real value moved into the downloaded .env template under the same key. AKIAIOSFODNN7EXAMPLE is AWS's own published example key ID, used throughout their documentation specifically because it never resolves to a real account.

Entropy and key-name heuristics

After the provider rules run, every string is checked against a Shannon entropy threshold of 4.5 on strings of 16 or more characters (high severity).¹² The analyzer then compares each parent key name against a list of suspicious labels that frequently hold secrets, including password, secret, and api_key (medium severity). This catches values that do not match a known provider format but are stored under obviously sensitive key names.

Kubernetes security flags

Non-string values and numeric or boolean fields are checked for Kubernetes security smell flags that increase the blast radius of a compromised pod. The analyzer flags privileged: true, hostNetwork: true, and hostPID: true at info severity.¹³ Missing or false readOnlyRootFilesystem and runAsNonRoot on a container’s securityContext are also flagged, since a writable root filesystem and a root user both make it easier for an attacker who gains code execution inside the container to persist or escalate.¹⁴

All values inside a Kubernetes Secret’s .data or .stringData map are always flagged critical regardless of their content, since those fields are the canonical place where Kubernetes stores credentials and the sanitized output should never include the raw values.¹ Placeholder names use the redacted key type so you can find and replace each one with a real secret from your environment.

Security model

The sanitized manifest replaces each detected value with a unique placeholder like __REDACTED_AWS_ACCESS_KEY_1__ that preserves the key path and value type so you can find and replace each secret in your environment. The placeholder name includes both the matched rule and a sequential counter so that two AWS keys in the same document never collide. The original values are never stored, cached, or transmitted anywhere. When you close the tab or reload the page, the parsed document and all findings are discarded with it.

What redaction covers

The sanitizer redacts string values that match a known provider pattern or exceed the entropy threshold, plus boolean and numeric fields that trigger a Kubernetes security smell. Each finding records the exact dotted key path into the nested document so that you can locate the original line in your source file. The .env template lists every redacted key on its own line, ready for you to fill in real values from a secrets manager or your local environment.

How secrets end up in manifests

Credentials in configuration files typically arrive through one of a few common paths. A developer testing a deployment locally hard-codes a database password in a ConfigMap rather than setting up a proper Secret reference, intending to fix it before merge but forgetting. A Helm values file gets a real SendGrid API key placed in a comment used as a placeholder example. A Terraform workspace stores sensitive outputs in state that gets committed alongside the configuration.² In each case the credential was never intended to persist, but it ends up in version control. Tools that only check committed code miss in-progress files; this sanitizer checks whatever you paste, including working drafts before they are staged.

High-entropy strings are the harder case. A random 32-character string used as a session signing key does not look like a known credential format, so pattern-based tools that only check for known prefixes like AKIA or ghp_ will miss it. Consequently, this tool adds a Shannon entropy threshold: any string of 16 or more characters with entropy above 4.5 bits per character is flagged as a probable secret.¹² This catches custom-generated tokens and opaque API keys that real-pattern rules miss, at the cost of occasional false positives on machine-generated identifiers that are not actually sensitive.

Kubernetes security posture beyond secrets

Besides credential leakage, Kubernetes manifests commonly contain configuration patterns that create privilege escalation or container escape risks. Containers running with privileged: true have essentially the same capabilities as root on the node and can mount host filesystems, modify kernel parameters, and break out of the container namespace. The hostNetwork: true setting shares the node's network namespace, giving the container direct access to services bound to localhost on the host that should not be reachable from pods. Similarly, hostPID: true allows the container to see and signal all processes on the node.¹³

Missing readOnlyRootFilesystem: true and runAsNonRoot: true in a container's securityContext are weaker signals but worth flagging in a review. A writable root filesystem makes it easier for an attacker who gains code execution inside the container to modify binaries or install tools. Running as root inside the container increases the blast radius if the container runtime has a privilege escalation vulnerability.¹⁴ The sanitizer flags all five of these patterns at info severity so that each one prompts a deliberate decision rather than slipping through unnoticed in a large manifest.