Decode an individual Secret value with kubectl and base64, or mount the Secret into a Pod so its keys appear as files. Secret volume mounts are read-only by design; setting readOnly: true makes that intent explicit. Base64 decoding is not decryption, and a read-only mount does not prevent an authorized process from reading the value.
Decode one Secret value with kubectl
Kubernetes represents Secret values in the API’s data field as base64-encoded strings. To inspect one value, retrieve just that field and decode it:
kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 --decodeReplace my-secret with the Secret name and password with the key to inspect. The decoded value is printed to standard output. This is reversible encoding, not decryption; base64 provides no confidentiality. See Kubernetes’ guidance on Secrets and its kubectl Secret workflow.
Because the command prints the value, run it only where output is not exposed to unauthorized people or captured in logs. Avoid putting secret values directly into shell commands, scripts, or shell history.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute#1 Best Overall
Mount a Secret as files in a Pod
A Secret volume makes each projected key available as a file, with the decoded value in that file. The Secret must exist in the same namespace as the Pod. Mount it only into the container that needs it.
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: example/app:stable
volumeMounts:
- name: app-secret
mountPath: /etc/app-secret
readOnly: true
volumes:
- name: app-secret
secret:
secretName: my-secretWith this mapping, an application can read the password key from /etc/app-secret/password. The manifest shows the structure; the image and Secret name are examples, not a tested deployment. Secret volumes are read-only, so readOnly: true documents the desired mount mode in the container configuration. Kubernetes also describes Secret volumes as memory-backed. See the Secret volume documentation.
Expose only the keys the application needs
By default, each Secret key appears in the mount directory under its key name. Use items to allowlist keys and optionally give a key a different relative path:
volumes:
- name: app-secret
secret:
secretName: my-secret
items:
- key: password
path: credentials/passwordMounted at /etc/app-secret, that mapping places the value at /etc/app-secret/credentials/password. When items is specified, only the listed keys are projected. Every listed key must exist; if one is missing, Kubernetes cannot create the volume. Projecting only required keys reduces unnecessary exposure. See Distribute Credentials Securely Using Secrets.
Choose file permissions deliberately
Secret volume files default to mode 0644. Set defaultMode on the Secret volume to choose a mode for all projected files, or set mode on an individual item to override it. For example:
volumes:
- name: app-secret
secret:
secretName: my-secret
defaultMode: 0400
items:
- key: password
path: password
mode: 0400Use permissions that work for the container’s user and the application. YAML accepts octal notation such as 0400; JSON does not support octal numeric literals, so express the same mode in decimal when writing JSON. Restrictive file permissions help control access inside the container, but they do not replace access controls on the Secret or Pod. The Kubernetes credential-distribution guide documents the defaults and overrides.
Plan for Secret updates and rotation
When Secret data changes, Kubernetes updates mounted Secret volumes eventually consistently; the change is not necessarily visible immediately. An application that relies on rotation should tolerate propagation delay and reload or reopen the relevant files as appropriate.
A Secret mounted using subPath does not receive automated updates. If an application must see rotated data without replacing its Pod, avoid relying on a subPath mount for that value. See the Kubernetes documentation on Secret updates and Secret volume behavior.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteBest Value
Understand what read-only does—and does not—protect
Read-only prevents the container from writing through that mount. It does not hide the file from the process or from users and processes with permission to read it, and it does not protect the Secret API object from an authorized reader. Base64 encoding likewise does not encrypt the data. Kubernetes notes that Secret objects are stored unencrypted in etcd by default.
- Enable encryption at rest for Secret data in the cluster’s storage configuration.
- Apply least-privilege RBAC to Secret access and Pod creation.
- Mount or inject a Secret only into the containers that require it.
- Protect values after the application reads them: avoid cleartext logs and untrusted transmission.
- Consider an external Secret store when it fits the deployment’s security and operational needs.
Pod creation permissions matter: someone who can create Pods in a namespace may be able to arrange for a Pod to access Secrets in that namespace. Review Kubernetes’ Secret security guidance alongside the mount configuration.
Use a projected volume only when you need multiple sources
A direct Secret volume is the simpler choice when an application needs files from one Secret. A projected volume can combine sources such as Secrets, ConfigMaps, and downward API data into one directory; its Secret source uses name and can map selected keys to paths.
| Approach | Best fit | What appears in the container |
|---|---|---|
| Direct Secret volume | Files from one Secret | Secret keys as files, optionally filtered or remapped with items |
| Projected volume | A unified directory assembled from multiple supported sources | Files from the configured sources, with Secret keys optionally mapped to paths |
Use a projected volume when the shared directory is useful to the application; for a Secret alone, the direct volume avoids unnecessary configuration. See Kubernetes’ Projected Volumes documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
