Introduction

Updating a Kubernetes Secret with kubectl is common during credential rotation, environment fixes, or certificate updates. The risky part is not the syntax. The real risk is changing the value safely, avoiding plaintext leaks, and making sure the workload actually starts using the updated secret afterward.

Understand What You Are Editing

Kubernetes stores secret values in base64 form inside the object. Base64 is encoding, not encryption. That means:

• values in the data field must be base64-encoded
• reading the YAML does not mean the secret is protected by the encoding itself

Common update workflows include:

• 'kubectl edit secret'
• 'kubectl patch secret'
• export, edit, and kubectl apply
• recreate from literals or files with kubectl create secret ... --dry-run=client -o yaml

For repeatable and reviewable changes, declarative apply is usually safer than interactive terminal edits.

Create and Inspect a Secret

Here is a basic example:

1kubectl create secret generic app-secret \
2  --from-literal=username=admin \
3  --from-literal=password='initial-pass' \
4  -n app
5
6kubectl get secret app-secret -n app -o yaml

Be careful when inspecting secrets. Decoded values can leak into terminal history, shell logs, screen recordings, or chat transcripts if you are not deliberate.

Patch One Key Quickly

For a small targeted update, kubectl patch is concise.

1NEW_PASSWORD_B64=$(printf 'newpassword' | base64)
2
3kubectl patch secret app-secret -n app \
4  --type merge \
5  -p "{\"data\":{\"password\":\"${NEW_PASSWORD_B64}\"}}"

This is useful for focused changes, but it becomes error-prone when many keys need to be updated quickly under pressure.

Use Declarative Apply for Safer Repeatability

If the change should be reviewed or repeated, export the object, edit the manifest, and apply it back.

kubectl get secret app-secret -n app -o yaml > app-secret.yaml

After editing the file:

kubectl apply -f app-secret.yaml

In that workflow, be careful with server-generated metadata you do not actually want to manage manually.

Update Behavior Depends on How the Secret Is Consumed

Changing the Secret object does not automatically mean the application is now using the new value.

Typical behavior:

• environment-variable consumption usually requires a pod restart
• mounted secret volumes may update on disk, but the application may still need explicit reload logic

A real rotation sequence is often:

1. update the Secret
2. restart or roll the workload if necessary
3. verify that the application uses the new value
4. revoke the old credential

Skipping the rollout or verification step is one of the most common secret-rotation failures.

Verify Both the Object and the Workload

After the update, check Kubernetes state and application behavior.

kubectl describe secret app-secret -n app
kubectl rollout restart deployment app -n app
kubectl rollout status deployment app -n app

Then validate from the application side that the new credential, token, or certificate is actually in use. Kubernetes object state alone is not enough.

Prefer File or Literal Regeneration for Complex Secrets

When a secret has many keys or comes from a file such as a certificate bundle, regenerating the object from source data is often less error-prone than editing encoded YAML by hand.

1kubectl create secret generic tls-bundle \
2  --from-file=tls.crt=./tls.crt \
3  --from-file=tls.key=./tls.key \
4  --dry-run=client -o yaml | kubectl apply -f -

That reduces manual base64 handling and keeps the source of truth clearer.

Common Pitfalls

The biggest mistake is treating base64 encoding as if it were a security boundary. It is not.

Another issue is updating the Secret object and forgetting that the running workload may still be using the old value.

Teams also often do urgent interactive edits with no review trail and accidentally leak secret material into terminal history or shared tooling.

Finally, do not decode and recode large secrets manually unless you have to. Regenerating from source files or literals is often safer.

Summary

• 'kubectl can update Secrets through patch, edit, or declarative apply workflows.'
• Secret data fields require base64-encoded values, but base64 is not protection.
• Patch is convenient for small updates; declarative apply is better for repeatable controlled changes.
• Updating the Secret object is only part of a real credential rotation.
• Always verify that the workload actually picked up the new secret value.