The least-privilege decision — what to lock down first

The decision of what to lock down first is driven by four factors: blast radius, frequency of use, time-to- revoke, and audit cost. A team cannot tighten every identity at once; the priority order determines which production surfaces are defended first and which are left exposed for the longest. The wrong priority is to start with the easiest identity to tighten — the read- only validator — and call the project done. The right priority is to start with the production deploy identity, even though it is harder.

The four-factor ranking

flowchart TB
    B["Blast radius"] --> R["Rank"]
    F["Frequency of use"] --> R
    T["Time-to-revoke"] --> R
    A["Audit cost"] --> R

The four factors multiply rather than add:

• Blast radius. What does the identity touch? Production deploy identities touch production systems; CI plan identities touch state; read-only validators touch configuration. Higher blast radius is higher priority.
• Frequency of use. How often is the identity assumed? An identity used 50 times a day is assumed 50 times a day; an identity used monthly is assumed 12 times a year. Higher frequency means higher exposure to fork-PR exploits.
• Time-to-revoke. How long does the identity live? A long-lived AWS access key has 90 days to revoke; a per-job STS session has one hour. Longer time-to-revoke is higher priority.
• Audit cost. How expensive is it to verify the identity is locked down? An identity whose lock- down requires inspecting 12 IAM policies has higher audit cost than one with a single policy.

The product of the four factors is the priority. The identity with the highest product gets locked down first.

The priority order

flowchart LR
    P1["1. Production deploy identity\nAdministratorAccess, cluster-admin"] --> P2["2. Long-lived secrets\nAWS keys, kubeconfigs, registry tokens"]
    P2 --> P3["3. CI plan identity\nread on production state"]
    P3 --> P4["4. Repo server / GitOps controller\nnamespace-scoped"]
    P4 --> P5["5. Read-only validators\nstatic analysis, lint, format"]

The five tiers in priority order:

1. Production deploy identity. The role that runs terraform apply, kubectl apply, and helm upgrade against production. The blast radius is the production system; the frequency is every deploy; the time-to-revoke is the session duration. Highest priority.
2. Long-lived secrets. AWS access keys, kubeconfigs stored in GitHub secrets, registry push tokens, Vault tokens. The time-to-revoke is the rotation cadence. Second priority.
3. CI plan identity. The role that runs terraform plan, kubectl diff, helm template. The blast radius is read-only state — still sensitive because state may contain secrets, but not write. Third priority.
4. Repo server and GitOps controller. The ServiceAccounts that reconcile the cluster to Git. The blast radius is the namespace they manage; the frequency is continuous. Fourth priority.
5. Read-only validators. Linters, formatters, static analysers, policy checkers that do not need any cloud or cluster identity. The blast radius is the build artefact and the test fixture. Fifth priority.

Estimating audit cost

The audit cost is the cost of a false negative. A false negative is an identity that the audit reports as scoped but is actually wide. The cost is the production incident the audit failed to prevent.

For each tier, the audit cost is:

• Tier 1 (production deploy). A false negative is a production compromise. The cost is the incident response, the customer impact, the regulatory disclosure. Highest audit cost.
• Tier 2 (long-lived secrets). A false negative is the credential lifetime of access. The cost is the incident response plus the rotation window for every credential. High audit cost.
• Tier 3 (CI plan). A false negative is read access to state for the rotation window. Medium audit cost.
• Tier 4 (GitOps controller). A false negative is continuous write to the managed namespace. Medium audit cost.
• Tier 5 (read-only validators). A false negative is read access to the fixture. Low audit cost.

The audit must verify the highest-cost tiers first. aws iam list-attached-role-policies, kubectl auth can-i --list --as, and the IAM Access Analyzer policy generation are the audit commands; running them on tier 1 before tier 5 is the discipline.

The lock-down workflow

The lock-down for each tier follows the same pattern, but the effort differs:

1. Enumerate. Run aws iam list-attached-role-policies, kubectl auth can-i --list --as, and the IAM Access Analyzer against the identity.
2. Compare. Match the actual permissions against the minimum the identity needs. Identify the excess.
3. Tighten. Replace the broad policy with a narrow one. Use StringEquals, specific resource ARNs, and condition keys.
4. Test. Run the job under the new policy. Verify the job succeeds at the legitimate actions and fails at the excess.
5. Audit quarterly. Re-run the enumeration and confirm the identity has not widened.

The pattern is identical for cloud IAM and Kubernetes RBAC. The audit commands are platform-specific; the discipline is the same.

Production discipline

1. Lock down tier 1 first. Production deploy identities before anything else.
2. Audit before tightening. The audit finds the excess the team’s memory missed.
3. Tighten one identity at a time. A change to ten identities at once is a change the team cannot roll back; a change to one is a change the team can.
4. Test the new policy against legitimate and illegitimate actions. The policy must allow the job to succeed and reject the actions the job does not need.
5. Re-audit quarterly. New commands, new workflows, new dependencies each expand the permission set.

Cross-course references

• Part XCI-01 (The validation versus deployment identity) covers the structural split that drives the priority order.
• Part XLII-05 (Secret rotation cadence) covers the time-to-revoke factor for tier 2 identities.
• Part L (GitOps) covers the controller identities in tier 4.

Quiz