Chapter 17 — Cryptography concepts
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Encryption in transit"]
N2["17.2 Encryption at rest"]
N3["17.3 Key management"]
N4["17.4 Hashes"]
N5["17.5 Signatures"]
N6["17.6 Mistakes"]
N7["17.7 Secrets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Encryption in transit"]
N2["17.2 Encryption at rest"]
N3["17.3 Key management"]
N4["17.4 Hashes"]
N5["17.5 Signatures"]
N6["17.6 Mistakes"]
N7["17.7 Secrets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Encryption in transit]
|
v
[17.2 Encryption at rest]
|
v
[17.3 Key management]
|
v
[17.4 Hashes]
|
v
[17.5 Signatures]
|
v
[17.6 Mistakes]
|
v
[17.7 Secrets]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) explain encryption at rest and in transit; (2) describe key management in the cloud; (3) use hashes and signatures for images; (4) avoid common cryptographic mistakes.
17.1 Encryption in transit
TLS protects traffic between users and StudyHub and between services. Certificates are issued and renewed automatically.
Between services inside the cluster, TLS stops a compromised node or a misrouted network from exposing student records as they travel. Automatic issuance and renewal removes the expired-certificate outages that once tempted developers to switch off verification, which is the mistake Samuel found in records-api. Internal certificates come from a private authority with short lifetimes. Samuel's checker reports any service that accepts plain connections or skips certificate verification, and the first run found exactly one, records-api, as the worked example below describes.
17.2 Encryption at rest
Managed storage and databases encrypt data at rest. Provider-managed keys are simplest; customer-managed keys in a key service add control over use and rotation, with audit logs of each use.
StudyHub's student records database uses a customer-managed key, so Westmere can see every use of the key in the audit log and could disable it in an emergency. Less sensitive stores such as application logs use provider-managed keys, which are simpler and adequate for their risk. The choice is recorded in the data register for each store.
17.3 Key management
Keys live in a managed key service, never in code or images. Access to use a key is granted to specific identities.
Granting key use to specific identities means that even someone with storage access cannot decrypt the student records database's backups without also being allowed to use its key. This two-part check limits the effect of a mistake in either permission. The key service logs each use, which feeds the access review below. Samuel's checker also searches images and code for anything that looks like a key, which complements secret scanning.
17.4 Hashes
An image digest is a hash of its content. Deploying by digest guarantees the exact image tested is the one running.
A tag such as latest can be moved to point at a different image at any time, so two deployments of the same tag may run different code. Deploying by digest removes that doubt. StudyHub's deployment files record digests, and the evidence for a release includes the digest that passed testing. Samuel's checker flags deployments that use tags instead of digests, so drift is visible.
17.5 Signatures
The build system signs images; the cluster verifies signatures before running them, so images from elsewhere are refused.
Since the sandbox gained its own registry, a research image could only reach production by being signed by StudyHub's build system, which does not build research images. Signature verification adds a second barrier beyond registry separation. A failed verification blocks the pod and raises an alert. Signing keys are held in the key service and used only by the build system's identity, so a developer cannot sign an image from a laptop. Exceptions for third-party system images are verified with the publisher's own signature where one exists.
17.6 Mistakes
Hard-coded keys, home-made encryption schemes and disabled certificate checks. All are avoided by using platform services.
Each has a familiar cause: hard-coded keys are quick in development, home-made schemes seem simpler than learning a library, and disabled checks make a certificate error go away. Platform services make the secure option the easy one. Samuel's checker searches code and configuration for the most common signs of all three. Findings are explained to developers with the safer alternative, so the fix is easy to apply and the habit changes rather than just the line of code.
17.7 Secrets
Connection strings and passwords belong in a secret manager, delivered to pods at run time, never baked into images like the one in the opening case.
After the opening case, records-api receives its database credentials from the secret manager when the pod starts, and the credentials expire and are replaced automatically. The rebuilt image contains no connection string at all. Pre-push scanning now looks for secret patterns, so a repeat would be stopped before the image reached the registry. The old password was rotated as well.
Rotation
Customer-managed keys are rotated automatically each year; data encrypted with older key versions remains readable because the key service keeps previous versions for decryption. TLS certificates renew automatically weeks before expiry, and an alert fires if renewal fails. Samuel lists every certificate and key with its owner and renewal method so nothing depends on memory.
Key access reviews
Who can use each key is reviewed quarterly alongside role reviews.
Worked example
Samuel finds that records-api checked TLS certificates with verification disabled, a leftover from development. Enabling verification in the test cluster reveals no issues, and the setting is fixed in all environments.
Synthetic case. Settings are synthetic.
Errors and limits
Encryption protects data from some threats but not from authorised identities misusing access.
Exercises
- EX049 — Customer-managed keys. What do customer-managed keys add? Rubric: 3 = control and audit of key use; 2 = partial; 1 = vague; 0 = none.
- EX050 — Digest benefit. Why deploy by digest? Rubric: 3 = exact tested image runs; 2 = partial; 1 = vague; 0 = none.
- EX051 — TLS finding. What TLS issue was found? Rubric: 3 = certificate verification disabled; 2 = partial; 1 = vague; 0 = none.
Synthesis
Use platform cryptography services and never bake secrets into images.
Continue studying — chapter 17 of 40
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →