Chapter 21 — Cloud and container security: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Managed services"]
N2["21.2 Stored keys"]
N3["21.3 Workload identity"]
N4["21.4 Least privilege for services"]
N5["21.5 Storage exposure"]
N6["21.6 Reviewing integrations"]
N7["Integration checklist"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Managed services"]
N2["21.2 Stored keys"]
N3["21.3 Workload identity"]
N4["21.4 Least privilege for services"]
N5["21.5 Storage exposure"]
N6["21.6 Reviewing integrations"]
N7["Integration checklist"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Managed services]
|
v
[21.2 Stored keys]
|
v
[21.3 Workload identity]
|
v
[21.4 Least privilege for services]
|
v
[21.5 Storage exposure]
|
v
[21.6 Reviewing integrations]
|
v
[Integration checklist]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) connect cluster workloads to managed cloud services securely; (2) use workload identities instead of stored keys; (3) review integrations.
21.1 Managed services
Client systems use managed databases, storage buckets and email services. Each connection needs an identity and permissions, and each is a place where data leaves the cluster. For Riverside Dental, the API connects to the managed database, reports writes to a storage bucket and booking sends confirmations through an email API. Each connection appears in the flow list, and each uses some credential to prove who is calling. How that credential is issued and stored decides how much damage a leak would cause, which is the focus of this chapter.
21.2 Stored keys
Older Cobalt setups stored long-lived cloud access keys as Kubernetes secrets. If leaked, these keys work from anywhere until someone revokes them. A key stored as a Kubernetes secret can leak in several ways: through a broad role that lets an identity read secrets, a backup copied without care, or a debugging session that prints environment variables. Because client-b's secrets were not encrypted at rest before its rebuild, any keys stored there were more exposed than elsewhere. Long-lived keys also tend to accumulate extra permissions as years pass.
21.3 Workload identity
Major providers let a Kubernetes service account be linked to a cloud identity, issuing short-lived credentials automatically. This removes stored keys and makes access traceable to a workload. The provider issues credentials that expire within hours, so a leaked credential stops working quickly, and there is no stored key to rotate or forget. Cloud audit logs then show which service account obtained the credential, linking cloud actions back to a specific workload. Setting it up requires a trust link between the cluster and the cloud account, which Priya tests in staging first.
21.4 Least privilege for services
The reports workload needs to write to one bucket path, not read every bucket. Priya narrows its policy accordingly. Its previous key allowed reading and writing every bucket in the account, which was convenient when it was created and far more than reports needs. The new policy allows only writes to the path where reports are stored. If the reports workload were compromised, the attacker could add files to that path but could not read other clients' data or delete existing objects elsewhere.
21.5 Storage exposure
Buckets are private by default; any public access must be an approved exception. A weekly check lists bucket access settings across client accounts. The weekly check reads the access settings of every bucket in the client accounts Cobalt manages and lists any that allow public access. Each public bucket must match an approved exception, such as one serving website images; anything else is treated as a finding and fixed the same day. The check complements the pipeline rule that blocks public buckets in proposed changes.
21.6 Reviewing integrations
When a new integration is added, the flow list, inventory and permissions are updated together, using a short checklist. Updating the three records together matters because each one answers a different question after the integration is live. The flow list says where data goes, the inventory says which workload sends it, and the permission record says what the workload's identity may do. If only one is updated, a later advisory or incident review will find the records disagreeing. The checklist itself is kept in the repository beside the flow list.
Integration checklist
Priya's checklist for new integrations asks: what data is sent, which identity is used, what permissions it has, whether traffic is encrypted, and who owns the integration. Each answer is recorded before the integration goes live. The checklist takes ten minutes and prevents the most common mistakes, such as broad storage permissions or a forgotten stored key.
She tests the checklist on two past integrations and finds that one would have been caught: a monitoring service with read access to every bucket.
Worked example
Priya migrates the reports workload from a stored key to workload identity in staging. After testing, she removes the old key and records the date. A search for other stored keys finds two more, scheduled for migration.
Synthetic case. Integrations are synthetic.
Errors and limits
Short-lived credentials reduce but do not remove risk; broad permissions are still dangerous.
Exercises
- EX061 — Stored key risk. What is risky about long-lived keys stored as secrets? Rubric: 3 = work anywhere until revoked; 2 = partial; 1 = vague; 0 = none.
- EX062 — Workload identity. What does workload identity provide? Rubric: 3 = short-lived credentials linked to service account; 2 = partial; 1 = vague; 0 = none.
- EX063 — Reports access. How was the reports workload's access narrowed? Rubric: 3 = write to one bucket path only; 2 = partial; 1 = vague; 0 = none.
Synthesis
Replace stored keys with workload identities and narrow each integration.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →