Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Identities"]
N2["19.2 Secrets in images"]
N3["Lab — Lab — secrets in image layers"]
N4["19.3 Lab result"]
N5["19.4 Cryptography for integrity"]
N6["19.5 Secrets management"]
N7["19.6 Rotation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Identities"]
N2["19.2 Secrets in images"]
N3["Lab — Lab — secrets in image layers"]
N4["19.3 Lab result"]
N5["19.4 Cryptography for integrity"]
N6["19.5 Secrets management"]
N7["19.6 Rotation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Identities]
|
v
[19.2 Secrets in images]
|
v
[Lab — Lab — secrets in image layers]
|
v
[19.3 Lab result]
|
v
[19.4 Cryptography for integrity]
|
v
[19.5 Secrets management]
|
v
[19.6 Rotation]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) manage cloud and workload identities; (2) apply cryptography for data and images; (3) detect secrets in images; (4) prefer short-lived credentials.
19.1 Identities
Humans sign in through the organisation's identity provider with multi-factor authentication; workloads use workload identity; pipelines use federated identity from the build system. Long-lived access keys are avoided.
Each kind of identity uses the strongest method available for it. Humans have MFA because passwords are easily stolen. Workloads use identities issued by the platform, so no key is stored in code. Pipelines use federated identity, obtaining short-lived credentials from the build system's own identity rather than holding a permanent key.
19.2 Secrets in images
Image layers are archives; anything copied in remains even if deleted in a later layer. The opening case's key sat in layer 3 of the image. Shu, Gu and Enck (2017) found widespread vulnerabilities in public container images, a reminder that what is pushed publicly is visible to anyone.
Deleting a file in a later layer only hides it in the final view; the earlier layer still contains it and can be extracted by anyone who pulls the image. That is how the key in layer 3 remained exposed. Public registries are scanned constantly by people looking for exactly this, so a pushed secret should be treated as compromised immediately.
Lab — Lab — secrets in image layers
"""Flag key-like strings in synthetic image layer files using pattern and entropy (stdlib only)."""
import math, re
from collections import Counter
layers = {
"layer3/app/config.env": "LOG_LEVEL=info\nCLOUD_ACCESS_KEY=SYNTHKEY7Qx9Lp2Vw8Rt4Zm6\n",
"layer4/app/settings.py": "TIMEOUT = 30\nEXAMPLE_TOKEN = 'xxxxxxxxxxxxxxxxxxxx'\n",
"layer5/app/readme.txt": "Meter data platform.\n",
}
def H(s):
c = Counter(s); return -sum(v/len(s) * math.log2(v/len(s)) for v in c.values())
for path, text in layers.items():
for m in re.finditer(r"([A-Z_]*(?:KEY|TOKEN|SECRET)[A-Z_]*)\s*=\s*'?([A-Za-z0-9]{16,})", text):
h = H(m.group(2))
print(f"{path:24} {m.group(1):17} entropy {abs(h):.2f} {'LIKELY SECRET' if h > 3.5 else 'placeholder'}")
Run with python3 lab_secrets.py. Verified output:
layer3/app/config.env CLOUD_ACCESS_KEY entropy 4.50 LIKELY SECRET
layer4/app/settings.py EXAMPLE_TOKEN entropy 0.00 placeholder
19.3 Lab result
The scan finds CLOUD_ACCESS_KEY in layer3/app/config.env with character entropy 4.50, above the 3.5 threshold: LIKELY SECRET. EXAMPLE_TOKEN in layer4/app/settings.py is twenty repeated characters with entropy 0.00: a placeholder. Entropy helps separate real-looking keys from obvious placeholders, but a reviewer confirms each finding.
Entropy measures how varied the characters are. Random keys have high entropy; repeated characters have none. The threshold separates likely secrets from placeholders, but some real secrets have lower entropy and some harmless strings have higher, so a reviewer checks each finding. The key found here was revoked and its uses investigated.
19.4 Cryptography for integrity
Images are signed after build and verified at admission, so only images built by Solent's pipeline can run. Keys for signing are held in a managed key service.
A signature proves the image came from Solent's pipeline and has not changed since. Admission control refuses unsigned or wrongly signed images, so an image pushed by someone else, or tampered with in the registry, cannot run. Holding signing keys in a managed key service keeps them out of the pipeline's file system.
19.5 Secrets management
Runtime secrets come from a secret manager or Kubernetes Secrets with encryption at rest, never from images; the Kubernetes good-practice guidance for Secrets recommends least-privilege access to them.
Secrets delivered at runtime are never part of the image, so pushing an image cannot leak them. A secret manager also logs access and supports rotation. Limiting which service accounts can read which Secrets means a compromised pod cannot read every credential in the namespace. Elena's checker flags any pod spec that mounts all Secrets in a namespace.
19.6 Rotation
Remaining long-lived secrets are rotated on a schedule and immediately after exposure.
Rotation limits how long a stolen secret stays useful. Scheduled rotation handles slow leaks that nobody noticed; immediate rotation after exposure handles known incidents. Automating rotation removes the temptation to postpone it because it is tedious or risky. Each secret has a recorded owner, a rotation interval and the date of its last rotation. Elena's report lists any secret past its interval. Rotation is tested on the test cluster first, so services that cache old credentials are found before production rotation breaks them.
Human access
Engineers' production access is granted just in time for a ticket and expires automatically after a few hours.
Worked example
Elena adds the layer scan to the pipeline before any push. In the first month it blocks two builds containing test credentials, both caught before leaving the build system.
Synthetic case. Keys and images are synthetic.
Errors and limits
Entropy checks miss low-entropy secrets such as simple passwords; combine with pattern rules.
Exercises
- EX055 — Deleted files. Why does deleting a file in a later layer not help? Rubric: 3 = earlier layer still contains it; 2 = partial; 1 = vague; 0 = none.
- EX056 — Lab result. What did the scan report? Rubric: 3 = CLOUD_ACCESS_KEY 4.50 likely secret; EXAMPLE_TOKEN 0.00 placeholder; 2 = one; 1 = vague; 0 = none.
- EX057 — Image signing. What does image signing achieve? Rubric: 3 = only pipeline-built images run; 2 = partial; 1 = vague; 0 = none.
Synthesis
Short-lived identities and secret-free images remove whole classes of leaks.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →