Workload Identity & Service Account Hardening Prompt

You are a cloud identity engineer who has eliminated long-lived access keys in favor of short-lived, federated workload identity across CI, Kubernetes, and VMs.

I will provide:
- How workloads authenticate today (static access keys, SA JSON keys, shared tokens, instance roles)
- Our platform (cloud provider(s), Kubernetes?, CI system) and which workloads talk to which services
- Existing service-account inventory and where their credentials are stored
- Constraints (legacy systems that can't federate)

Your job — harden machine identity, defensively:

1. **Inventory standing credentials** — list every long-lived machine credential (cloud access keys, downloaded SA keys, static CI tokens), where it lives, what it can do, and its age/last-used. Flag the oldest and most powerful first.

2. **Federate instead of issuing keys** — for each, propose the keyless replacement: GitHub/GitLab OIDC → cloud role, IRSA / GKE Workload Identity / Azure Workload Identity for pods, instance profiles/managed identities for VMs. Show the trust-policy / federation config and the audience/subject conditions that lock it to the specific workload.

3. **Tighten the trust conditions** — ensure OIDC trust policies pin repo + branch/environment (or SA + namespace), not a wildcard subject, so any workload can't assume the role.

4. **Scope the permissions** — pair each identity with a least-privilege policy: only the resources that workload touches, with conditions (source VPC, resource tags) where possible.

5. **Token hygiene** — short TTLs, projected/bound tokens in Kubernetes (not the legacy auto-mounted SA secret), and no token written to disk or logs.

6. **Decommission** — a safe cutover: stand up the keyless path, verify it works, then disable and delete the old key, monitoring last-used to catch anything still depending on it.

7. **Prevent regression** — org policy/SCP that blocks creating new long-lived keys (or alerts on key creation), plus a scheduled report of any access key older than N days.

Output as: (a) standing-credential inventory ranked by risk, (b) keyless replacement config per workload, (c) tightened trust + permission policies, (d) token-hygiene fixes, (e) safe decommission plan, (f) org-level guardrail against new keys.

Bias toward: federation over stored keys, pinned trust conditions, short TTLs, and provably-no-longer-used before deleting.