Encoding a credential
The manifest, plus the reminder that base64 protects nothing
password: hunter2 api-key: abc123
base64-encode values into a Secret manifest, in your browser. base64 is encoding, not encryption: anyone who can read the manifest can read the value, so read the findings before this goes near a repository.
Nothing you type leaves your browser. stringData keeps the values readable and the API server encodes them on write, which is exactly as unencrypted.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Encode. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The manifest, plus the reminder that base64 protects nothing
password: hunter2 api-key: abc123
The two keys a kubernetes.io/tls Secret must carry
tls.crt: PEM CONTENT HERE tls.key: PEM CONTENT HERE
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
base64 is encoding. Anyone reading the manifest reads the value.
Instead:Encrypt before committing, with Sealed Secrets or SOPS.
The whole point of the encoding is transport, not secrecy. A repository scanner recovers it instantly.
Instead:Generate at deploy time, or commit only encrypted output.
Encoding a value with a newline gives a credential with a newline, and the failure is an authentication error with no clue.
Instead:Trim before encoding. echo -n rather than echo.
Both halves matter. `base64 -d` is the whole attack on a manifest, and without an EncryptionConfiguration on the API server, Secrets sit in etcd base64-encoded and nothing more.
Anyone with repository access has it, and so does every clone, every fork and every backup, including after it is deleted from the branch: git keeps history. Rotating the credential is the only remedy once it has been pushed. Sealed Secrets, External Secrets and your platform's own secret store all put an encrypted or referenced value in git and the real one only in the cluster.
A ServiceAccount granted `get secrets` in a namespace can read every Secret in it, not only the ones it mounts. That is worth checking before deciding a Secret is adequately protected: the RBAC analyzer on this site shows what a binding actually grants.
Whether your cluster has encryption at rest enabled, which is an API server flag. Whether the value is a real credential or a placeholder. And it cannot stop you committing the output, which is the risk this tool exists alongside rather than solves.