Kubernetes / Basic: objects and execution boundaries / Lesson 5

Configuration, Secrets, and workload identity

Separate nonsecret settings, credential references, and workload identity while understanding how consumers receive updates.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of configuration, secrets, and workload identity.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

Classify the input before storing it

ConfigMaps hold nonconfidential configuration data; Secrets are intended for sensitive values and need additional access and storage controls. Neither validates the application’s business schema automatically. A public display mode differs from a database password and from a ServiceAccount identity. Put only the required input at each boundary and validate required settings before readiness. Never place credentials in labels or annotations to make them convenient to inspect. An object name such as private does not enforce confidentiality, and a namespace alone does not isolate credential access or the workloads that can consume it.

Understand encoding and protection

The first Secret uses stringData with an explicitly public synthetic value to illustrate schema. Base64 in data is encoding, not encryption. Protection depends on authorization, encryption at rest where configured, transport, audit handling, and the consumer environment. Listing or reading Secrets can reveal sensitive material, and creating a Pod can grant indirect access through mounts. Do not print a real object to debug a missing reference. Inspect safe metadata, key names, references, and events through authorized access instead. The example is never stored or submitted and is not a usable credential.

yaml Illustrative Secret with public synthetic data

apiVersion: v1
kind: Secret
metadata:
  name: synthetic-training-value
  namespace: training
type: Opaque
stringData:
  DEMO_VALUE: public-lab-value-not-a-credential

The text is deliberately public and unusable as a credential. Schema demonstration is not encryption or safe secret delivery, and this object is not created.

Choose injection and refresh semantics

Environment values are fixed for a running process; updating a referenced object does not rewrite that process environment. Mounted projections have their own update behavior, and subPath mounts do not receive the same automatic updates. An application must notice and safely reload changed files if that is the chosen contract. The second synthetic record separates store version, mounted or injected reference, and active consumer adoption. A successful object update is not evidence that every pooled connection uses a replacement credential. Review exact refresh rules for the selected mount and application rather than relying on a generic rotation timer.

yaml Synthetic credential adoption record

approved_version: lab-secret-3
store_reference: lab-secret-3
consumer_a_active_version: lab-secret-3
consumer_b_active_version: lab-secret-2
conclusion: source-updated-but-adoption-incomplete

Consumer B is not proven updated. The record contains only fictional version labels and does not expose or compare credential values.

Use service identity narrowly

A ServiceAccount supplies workload identity for Kubernetes API interactions and can integrate with external identity systems through platform-specific mechanisms. It is not a reason to grant every application cluster-admin. Prefer narrowly scoped authorization and short-lived projected credentials where supported. If a workload does not need Kubernetes API access, review whether automatic token mounting is necessary. Keep trust in issuer, audience, and consumer behavior explicit. A valid token authenticates an identity; RBAC and other policy still decide permitted actions. External cloud identity mappings have separate provider assumptions and are not configured by these examples.

Rotate with a consumer recovery plan

Coordinate replacement with the dependency owner and verify adoption without logging values. A supported overlap can allow consumers to move before revocation, while compromise may require immediate revocation and a different availability choice. Rolling back an artifact must not restore an expired credential. Record configuration and secret version references alongside release identity, with access controls appropriate to the metadata. Test startup validation, missing keys, reload failure, and mixed consumer versions with synthetic data in an authorized environment. This lesson does not inspect an environment, token, secret store, cluster, or real authentication endpoint.

Common errors and fixes

Base64 is treated as encryption

Why it happens: Encoding was confused with confidentiality.
How to fix it: Apply authorization and documented storage protection.
Prevent it next time: Review the whole credential path and logs.

Rotation changes the object but not the process

Why it happens: Injection and refresh behavior were assumed.
How to fix it: Follow the approved reload or replacement contract.
Prevent it next time: Verify adoption by each consumer without values.

An application receives excessive API authority

Why it happens: ServiceAccount identity was paired with broad roles.
How to fix it: Grant only required resource actions and scope.
Prevent it next time: Review indirect access through workload creation.

Check your understanding

1. A ConfigMap environment value changes. Does an existing process automatically receive the new value?

Show worked solution

No. The process environment is established at creation. Use the application’s reviewed replacement or reload design and verify the active configuration version. Do not infer adoption from the object’s resourceVersion or from a successful update request alone.

2. Why can permission to create Pods expose Secrets even without direct Secret read permission?