Introduction

Kubernetes stores secret data as base64-encoded values inside the Secret object. That means when you fetch a specific key with kubectl, you usually need two steps: select the key and decode the base64 output.

The most common command pattern is jsonpath plus base64 --decode. That gives you one specific value in plaintext without printing the whole secret manifest.

Get One Secret Value

If the secret is named my-secret and the key is password, use:

kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 --decode

If the secret is in another namespace:

kubectl get secret my-secret -n app-ns -o jsonpath='{.data.password}' | base64 --decode

That is the standard shell-friendly way to retrieve one field.

Why Base64 Decoding Is Needed

The value under .data is not stored as plain text in the API object. It is base64-encoded. For example, a secret might look like this:

1apiVersion: v1
2kind: Secret
3metadata:
4  name: my-secret
5data:
6  password: c2VjcmV0MTIz

The encoded string c2VjcmV0MTIz becomes secret123 after decoding.

It is important to remember that base64 is encoding, not encryption. Access control still matters.

Use jsonpath Carefully

jsonpath expressions are exact. If the key name is wrong, the output is blank and the command can look like it worked when it really did not. That is why it helps to inspect the secret keys first:

kubectl get secret my-secret -o json

or:

kubectl describe secret my-secret

Once you know the exact key name, use the focused jsonpath query.

Another Useful Output Format

If you want to inspect the whole secret structure first, -o yaml or -o json is often easier than guessing the key name immediately. Once you see the exact keys under .data, switch back to a targeted jsonpath command for the single value you actually need.

Secrets Are Usually Single-Line Values

Many shell examples assume the decoded value is a single line, such as a password or token. If the secret contains certificate data or another multiline value, decoding still works, but you should be more careful about how the shell displays and pipes the output so formatting is not accidentally lost or echoed into logs.

stringData Versus data

When creating secrets, Kubernetes lets manifests use stringData as a convenience field, but once the object exists in the API it is exposed under .data in base64 form. That difference explains why the retrieval commands target .data even if the original manifest looked more human-friendly.

Use shell history and terminal logging carefully when handling decoded secret output.

That is especially important on shared terminals and in CI logs.

Plaintext retrieval should be deliberate, brief, and limited to the exact key you need.

Avoid leaving decoded values visible longer than necessary.

Common Pitfalls

• Forgetting that secret values under .data are base64-encoded.
• Using the wrong namespace and concluding the secret is missing.
• Typing the wrong key in the jsonpath expression and getting empty output.
• Printing secret values freely in terminals, logs, or shell history.
• Assuming base64 means the value is cryptographically protected.

Summary

• Use kubectl get secret ... -o jsonpath=... | base64 --decode to retrieve one plaintext value.
• Secret values under .data are base64-encoded, not plain text.
• Add -n <namespace> when the secret is not in the current namespace.
• Verify the key name before debugging the command.
• Treat decoded output carefully because it is still sensitive information.