liveBook · Manning

Cryptographic key

As explained in Kubernetes in Action, Second Edition

A Secret is a Kubernetes API resource for storing sensitive data such as credentials, tokens, or keys.

A Kubernetes Secret is an API resource for sensitive values such as credentials, certificates, and private keys. Like a ConfigMap, it holds key–value pairs that an application can receive through environment variables or files. Use a Secret rather than a ConfigMap when the value needs to be kept private. section 8.3 section 8.5

Create a generic Secret directly with `kubectl create secret generic my-credentials --from-literal user=my-username --from-literal pass=my-password`. In a YAML manifest, put plain-text input under `stringData`, or Base64-encoded values under `data`. Kubernetes decodes `data` values before delivering them to a container. `stringData` is write-only: when you retrieve the Secret, its entries appear under `data`. section 8.3.1 section 8.3.2

Table 8.3 Differences in the structure of Secrets and ConfigMaps
Secret
ConfigMap
Description
data
binaryData
A map of key–value pairs. The values are Base64-encoded strings.
stringData
data
A map of key–value pairs. The values are plain text strings. The stringData field in Secrets is write-only.
immutable
immutable
A Boolean value indicating whether the data stored in the object can be updated.
type
N/A
A string indicating the type of Secret. It can be any string value, but several built-in types have special requirements.

Compare Secret fields with their ConfigMap counterparts, especially `data` and the write-only `stringData` field. section 8.3.1

Give a container one Secret value

In a container's `env` entry, set `name: INITIAL_STATUS_MESSAGE` and `valueFrom.secretKeyRef` with `name: kiada-secret-config` and `key: status-message`. Kubernetes supplies that entry as the environment variable. `envFrom.secretRef` can instead supply the entire Secret. Environment variables can leak through logs or inherited child processes, so projecting a Secret as files is often the better choice. section 8.3.3

Secrets also serve resources outside an application's environment. A pod can reference an image pull Secret for a private registry. An Ingress can reference a TLS Secret containing a certificate and private key to terminate HTTPS. A Secret volume can present certificate and key files to a container without baking them into its image. section 8.3.2 section 9.5 section 12.3.2

A Secret is not automatic encryption. Base64 encoding is reversible, and Secrets may sit unencrypted in etcd unless encryption is enabled. Control API access with RBAC, avoid committing credential manifests to version control, and plan rotation separately: Kubernetes does not rotate Secret values automatically. Dedicated secret-management tools can complement Secrets where stronger controls are needed. section 8.3.4 section 8.3.2

How Kubernetes in Action, Second Edition covers it

How deep it goes
Explains fields, creation, environment injection, and security limits; defers file projection to the treatment of volumes.
Examples
Uses kubectl-created credentials, a secretKeyRef environment variable, a private-registry pull Secret, and an Ingress TLS certificate.
What it assumes
Assumes familiarity with pods and environment variables, while introducing Secret fields and creation without requiring prior Secret knowledge.
What you can do after
Apply it via kubectl and pod manifests to supply sensitive values while recognizing encoding, access, and rotation risks.
How it connects
Connects Secrets to ConfigMaps, pod environment variables, Secret volumes, RBAC, image pulls, and Ingress TLS.

Also explained in

Compare how 5 books explain cryptographic key →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.