◇ OpenCyber Academy
Engineering · Chapter 28 · English

Chapter 28 — Cloud and container security: implementation I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 28 — Cloud and container security: implementation I

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 Plan"]
  N2["28.2 Inventory"]
  N3["28.3 Unused keys"]
  N4["28.4 Active keys"]
  N5["28.5 Storage guardrail"]
  N6["28.6 Verification"]
  N7["Communicating the migration"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 Plan"]
  N2["28.2 Inventory"]
  N3["28.3 Unused keys"]
  N4["28.4 Active keys"]
  N5["28.5 Storage guardrail"]
  N6["28.6 Verification"]
  N7["Communicating the migration"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 Plan]
    |
    v
[28.2 Inventory]
    |
    v
[28.3 Unused keys]
    |
    v
[28.4 Active keys]
    |
    v
[28.5 Storage guardrail]
    |
    v
[28.6 Verification]
    |
    v
[Communicating the migration]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) implement workload identity and storage guardrails; (2) migrate services off long-lived keys; (3) verify each step; (4) manage rollout risk.

28.1 Plan

Migrate services one at a time from long-lived keys to workload identity: create the role binding, deploy the service using it, confirm it works, then disable and delete the old key.

Migrating one service at a time limits the impact of any problem and lets the team learn from early migrations. Confirming the service works before removing the old key ensures there is always a working credential. Deleting the key at the end closes the exposure. Each step is recorded for audit, so Solent can show when every key disappeared.

28.2 Inventory

A query lists all service account keys in Solent's cloud accounts: 23 keys, of which 9 had not been used in 90 days.

Knowing how many keys exist and which are used is the starting point for removing them. Nine unused keys represent risk with no benefit: if any were leaked, they could be used without anyone noticing a change in legitimate activity. The query also shows creation dates and owners, helping trace why each key exists. Elena assigns each key to an owner before any change is made.

28.3 Unused keys

Unused keys are disabled first, not deleted, for two weeks. If nothing breaks, they are deleted.

Disabling first is a safe test: if some forgotten job did use a key, it fails visibly and the key can be re-enabled quickly. After two weeks without problems, deletion is low risk. This two-step approach avoids breaking things while still removing the keys reasonably fast. Owners are told before each key is disabled, with the date and how to report a failure. Re-enabled keys are recorded with the reason, since a key that something still needs moves to the active migration list.

28.4 Active keys

Active keys are migrated service by service, with each service owner present.

Owners know their services' behaviour and can spot problems quickly during migration. Each migration follows the same steps and checklist, so the process is consistent. Problems found in early migrations, such as a library that does not support workload identity, are fixed before later services move. Migrations are booked outside the evening ingest peak. Each one ends with the owner confirming normal traffic for a full day before the old key is disabled, and the checklist records any library or configuration change the service needed.

28.5 Storage guardrail

Account-level public access blocking is enabled on test accounts first, then production. A query beforehand lists buckets with public access and their documented reasons: none in production after chapter 13's fixes.

Enabling the guardrail in test first reveals any surprises without affecting production. Listing public buckets beforehand ensures that nothing legitimate depends on public access. Finding none in production confirms earlier fixes held, and the guardrail now prevents any future public bucket. Elena records the before-and-after query results as evidence that the guardrail did not break anything.

28.6 Verification

After each migration, a check confirms the service has no keys and that its role has only the expected permissions.

Checking for keys confirms the old credential is gone. Checking permissions confirms the new role has exactly what the service needs, no more. Both checks are scripted so they can run again later to catch drift, such as someone adding a permission without review. The checks run weekly afterwards, and any key that reappears raises an alert to the platform team, together with the identity that created it.

Communicating the migration

Each service owner receives a short note before their migration: what changes, when, how to tell if it worked and who to contact. After migration, they confirm their service's health. Clear communication keeps trust high, and owners volunteer their services for earlier slots once the first migrations go smoothly. Elena keeps a migration log with each service, date, result and any issues, which becomes evidence for the regulator.

Rollback plan

Each migration keeps the old key disabled, not deleted, for a week as a rollback path.

Worked example

Migration takes six weeks. One legacy import job cannot use workload identity because it runs outside the cluster on a scheduled VM; it receives a VM-attached identity instead, also short-lived, and the last long-lived key is deleted. Elena records "long-lived workload keys: 0" as evidence for R1.

Synthetic case. Keys and services are synthetic.

Errors and limits

Disabling before deleting avoids irreversible mistakes.

Exercises

Synthesis

Migrate carefully, verify each step and record evidence.

Continue studying — chapter 28 of 50

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →