API Keys, Secrets and RBAC

Why it matters: Leaked keys are one of the most common causes of breaches, and automation platforms and AI tools multiply the number of keys you hold. Good habits make leaks rare and recoverable.

By the end you can:

• Identify what counts as a secret and where it must not go
• Store, scope, and rotate credentials
• Explain RBAC and least privilege
• Respond to an exposed key

Learn (15 min)

1. What is a secret? (5 min)

Any value that grants access if disclosed: API keys, passwords, OAuth client secrets, refresh tokens, private keys, database credentials. Keep them out of source control, browser code, prompts, tickets, screenshots, container images, and logs. If exposed, treat as compromised: revoke or rotate, review use, remove copies.

## .gitignore
.env
*.pem

Scanners such as gitleaks or your host's built-in secret scanning can catch accidents; they are a safety net, not a plan.

2. Store, scope, rotate (5 min)

Use a secrets manager or the platform's vault with encryption and access logs. Prefer short-lived, identity-based credentials where available. Give each integration its own credential with the minimum permissions, an expiry, and a rotation procedure. Applications fetch secrets at runtime via a protected identity; they shouldn't carry them in files or images. Environment variables are convenient but are not a secrets manager by themselves; they can leak through crash dumps, process listings, or logs.

3. RBAC and access reviews (5 min)

Role-based access control grants permissions through roles assigned to people, groups, or service identities. Define roles by task, avoid routine use of admin roles, separate human and service identities, and review access when roles change. Log secret reads and privileged actions. Have a tested revocation procedure and a named owner.

Apply (15 min)

Worked example (3 min). A scheduled report script reads customer records and sends email. Design: a dedicated service identity with read access to one reporting view and send-only permission for one mailbox; secret in the vault, retrieved at runtime; 90-day rotation tested in staging; alert on failed auth; owner named. If the key lands in a public repo: revoke immediately, create a new key, check logs for use, remove from history, notify the owner, and note the lesson.

Lab (7 min): Secrets audit.

1. List every integration you use (automation tools, AI tools, CRMs, email).
2. For each: where its key lives, who can see it, scope, last rotated.
3. Mark the two riskiest and write the fix for each.

Deliverable: A secrets inventory table (no actual key values). You're done when: Each row has an owner and a rotation plan.

Check yourself (5 min)

1. Should an API key be committed to a private repo?
2. What does least privilege mean?
3. Why separate credentials per integration?
4. Scenario: A teammate pastes a live key into a team chat. What's the first thing you do?
5. What is RBAC?

Reference

Common mistakes

Cheat sheet: Dedicated identity → narrow role → vault/runtime retrieval → audit logs → expiry/rotation → tested revocation.

Key terms: secret, vault, RBAC, workload identity, rotation, least privilege.

Interview prompts: What do you do in the first 15 minutes after discovering a leaked key?

Go deeper: AWS Well-Architected: secrets · AWS Secrets Manager best practices · Azure: Identity and access · Azure: Protect application secrets

Next: Lesson 48 — cloud foundations.