Keys, Badges, and Locked Boxes

01Two Questions at Every Door

I’ll be honest: identity and access management has a reputation for being the dull week. It is also the week that decides whether everything you built in Weeks 3 through 5 gets stolen. Almost every bad cloud story you will ever hear ends in this topic. So let’s make it simple, and let’s start with a hotel.

You walk up to the front desk. The clerk asks for your ID and your booking. That’s question one: who are you? Then they hand you a key card. That card opens room 412 and the gym. It does not open room 413, and it does not open the kitchen. That’s question two: what are you allowed to do? At checkout, the card stops working, even if you keep it in your pocket.

Every request in the cloud goes through the same two questions, every single time. They have names:

Keep them apart in your head. They fail in different ways. If authentication fails, a stranger gets in wearing your name. If authorization is sloppy, a real, honest user — or a real, honest program — can do far more damage than it ever needed to. The rest of these notes is mostly about the second question, because that’s where the cloud gives you the most rope.

1.1 Passwords are not enough. Add a second lock.

Passwords leak. People reuse them, phishing pages collect them, and old breaches at unrelated websites get sold in bulk. A very common story goes like this: someone uses the same password for a forum and their cloud console. The forum gets breached. A bot tries that email-and-password pair on every major service. It works. Nobody had to “hack” anything — they just logged in.

The fix is multi-factor authentication (MFA): you prove who you are with two different kinds of evidence, so one stolen thing is not enough.

• Something you know — a password or PIN.
• Something you have — your phone with an authenticator app, or a small hardware security key.
• Something you are — a fingerprint or face scan, usually used to unlock the “something you have.”

With MFA on, the bot in that story has the password and nothing else. The door stays shut. Turning MFA on takes about two minutes, and it is the single best security move you can make today. (Passkeys, which you may have seen on your phone, bundle “have” and “are” together and skip the password entirely. Use them where your provider offers them.)

02Users, Groups, and Roles

Cloud providers have three kinds of “who.” Think of an office building.

• A user is one specific person (or, sadly, sometimes one specific program) with a permanent login. It’s an employee badge with your photo on it. It works every day until someone cancels it.
• A group is a bundle of users who need the same access. It’s the rule “everyone in Accounting can enter floor 3.” You attach permissions to the group once, then add and remove people. When Dana moves from Accounting to Sales, you move her between groups. You don’t hunt down and edit forty separate permissions.
• A role is a set of permissions that nobody owns permanently. Someone (or something) steps into the role for a while, then steps out. It’s a visitor pass handed out at the lobby desk: it opens the doors on the pass, and it expires at 6 p.m. no matter what.

That last idea — access that expires on its own — is the most important idea this week. Hold on to it. Section 05 explains why it matters so much for servers.

03Policies: The Rules on the Card

A policy is a written list of rules about what’s allowed. On AWS it is a small JSON document. It looks scary at first glance. It isn’t. Here is a complete one:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadPhotos",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-photos/*"
    }
  ]
}

Read it line by line:

Line 2

Version is the version of the policy language, not today’s date. It is always this exact string. Copy it and forget it.

Line 3

Statement is a list of rules. This policy has one rule. Real ones often have a few.

Line 5

Sid is a nickname for the rule (“statement ID”). Optional, but it makes rules easy to talk about.

Line 6

Effect is either Allow or Deny. That’s the whole menu.

Line 7

Action is the verb: what you’re allowed to do. s3:GetObject means “in the S3 storage service, download a file.” The part before the colon is the service; the part after is the operation.

Line 8

Resource is the noun: which thing you may do it to. This long string is an ARN, AWS’s full address for a thing. Here it means “any file inside the bucket called my-photos.” The * is a wildcard: it matches anything, including folders inside folders.

So the whole policy says, in English: “You may download any file from the my-photos bucket.” That’s it. Not upload. Not delete. Not look at any other bucket. Wildcards work in actions too: s3:Get* means every S3 action whose name starts with Get, and s3:* means every S3 action at all. Wildcards are handy, and they are also how people accidentally hand out far too much.

3.1 The three rules of the decision

When a request arrives, the cloud gathers every rule that applies to whoever is asking and decides with three simple rules, in this order:

1. Deny by default. If no rule says “Allow,” the answer is no. Silence means no. This is called an implicit deny.
2. An Allow opens the door — if a rule matches both the action and the resource.
3. An explicit Deny always wins. If any matching rule says “Deny,” the answer is no, no matter how many rules say “Allow.” One “no” beats any number of “yes.”

Why does Deny win? Because it lets you build guardrails. A team lead can say “nobody, ever, deletes the backups,” and it stays true even if someone later writes a sloppy s3:* Allow for a new hire. (Real AWS has a few more layers stacked on top — organization-wide limits and so on — but they all follow these same three rules.)

Try it. Below is a tiny company with three identities and a handful of rules. Pick who is asking, what they want to do, and to which thing, and the simulator shows the answer — and, more importantly, which rule decided it. Resource names are shortened from full ARNs so they fit.

Two things to notice from the challenges. First, Maya’s rule s3:* on backups/* really does say “everything” — and she still can’t delete a backup, because the company-wide Deny wins. That’s a guardrail doing its job. Second, the web server can’t terminate anything, and nobody wrote a rule saying so. Nobody had to. Silence means no.

04Least Privilege: The Valet Key

Some cars come with a valet key. It starts the car and opens the driver’s door. It does not open the trunk or the glove box. The valet can do their job — park the car — and nothing else. If the valet turns out to be dishonest, the damage is limited to a joyride. Your laptop bag in the trunk is safe.

That is the principle of least privilege: give every person and every program exactly the access its job needs, and nothing more. Not “a bit extra, just in case.” Not “admin, because it was faster.” Exactly what the job needs.

Why be so strict? Because you have to plan for the day something goes wrong. A bug, a stolen laptop, a hijacked program. On that day, the only thing that matters is: what can this identity do? Security people call that the blast radius — how much damage spreads from one broken piece. Least privilege keeps the blast radius small.

Here is a real job from a real kind of app. A small program called thumbnailer runs every time someone uploads a photo. It reads the photo, makes a small preview image, saves the preview, and writes a line to the log. Tick the permissions you would give it. Then look at the two lists: does the job still work, and what could an attacker do if they took over the program?

Press the lazy preset and look at the right-hand list. The job works fine. It also hands an attacker your backups, your database password, and the power to launch servers on your bill. That’s the trap: a policy that’s too big never shows an error. Everything works, every day, until the one bad day. A policy that’s too small shows an error right away, which you then fix. So start small and add what’s missing. It’s the only direction that tells you when you’re wrong.

Also notice the sneaky middle ground: s3:GetObject on photos/* makes the job work too, but it also reads the private folder. Wildcards in the wrong place quietly widen the door. Point them at the narrowest folder that does the job.

05Machines Need Badges Too

Your code also has to prove who it is. When your web server downloads a photo from storage, the storage service asks the same two questions: who are you, and are you allowed? So the server needs an identity and some kind of credential.

The old way — and still the most common mistake — is to create an access key: a long ID plus a long secret string that works like a username and password for a program. You paste the key onto the server, and it works. Forever. That “forever” is the problem.

Permanent keys have three problems. They never expire, so a key leaked today works next year. They get copied — into images, backups, laptops, chat messages — and you lose track of where. And they are hard to change, because changing one means finding every copy.

5.1 The better way: a role, and keys that expire

Instead, you give the server a role — the visitor pass from Section 02. You attach the role to the server when you create it. When your code needs to call a cloud service, it quietly asks the provider for temporary credentials. The provider checks “yes, this is that server, and it holds that role” and hands back keys that expire on their own, typically after about an hour. Before they expire, the cloud’s own tools (the SDK and command-line tools) fetch fresh ones automatically. You write zero lines of code for this.

It’s the hotel key card again. You never take home a permanent key to the hotel. You get a card at check-in, it opens your room, and it stops working at checkout. If you lose it on the street, it’s useless by tomorrow.

The rule for this course is short: programs running in the cloud use roles, not keys. If your code has an access key in it, something is wrong. Project 1 already asked for scoped IAM roles; this section is the reason why. (There is one honest exception: your own laptop, which isn’t in the cloud. Even there, prefer your provider’s login command — for example aws sso login, gcloud auth login, or az login — which also hands out short-lived credentials.)

06Secrets: Where the Passwords Live

A secret is any piece of text that lets someone in. Database passwords. API keys for a payment or email service. Access keys. Private keys for TLS certificates. If a stranger who saw it could use it to get in somewhere, it’s a secret.

Not everything is a secret. A database’s hostname, a username, or a port number are just settings. Knowing them alone doesn’t open anything. The test: if this showed up on a billboard, would I need to change it? If yes, it’s a secret.

6.1 The golden rule: never in code, never in Git

Code gets shared. It gets pushed to GitHub, pasted into Stack Overflow questions, copied into container images, and shown on screen during class. And Git remembers everything: if a password was in a file for one commit, it is in the history forever, even after you delete it in the next commit. So:

• Keep secrets out of source files. Your code should say where to get the secret, never what it is.
• Use environment variables to hand secrets to a program at run time. An environment variable is a named value the operating system passes to a program when it starts, like DB_PASSWORD. Your code reads os.environ["DB_PASSWORD"] (Python) or process.env.DB_PASSWORD (Node). The value lives outside the code.
• On your laptop, it’s fine to keep these in a local .env file — as long as .env is listed in your .gitignore so Git never picks it up. Check this today.
• Don’t print secrets. Logs get copied and shared too. “Connected to database” is a good log line. “Connected with password X” is a leak.

6.2 Secrets managers: a safe-deposit box for passwords

Environment variables solve “not in the code.” But in production, someone still has to put the value there, and keep it current. The cloud answer is a secrets manager — AWS Secrets Manager, Google Secret Manager, or Azure Key Vault. Think of a bank’s safe-deposit box. The secret sits inside, encrypted. Only identities on the list can open it. Every opening is written in a logbook. And you can swap what’s inside — rotate the password — without touching the code.

Now watch how the pieces from this week click together. Your server has a role (Section 05). The role’s policy allows reading exactly one secret (Sections 03–04). At start-up, the program asks the secrets manager for that secret and gets it. There is no password anywhere in your code, your repo, or your image. That chain — role → policy → secrets manager — is the pattern to use in Project 2.

Now let’s train your eye. Each snippet below has zero, one, or two lines that leak a secret. Click the line you think leaks. If you think the snippet is clean, press “Nothing leaks here.”

07Encryption, in Plain Words

Encryption scrambles data so it looks like random noise to anyone without the right key. With the key, you can unscramble it back. That’s all you need to know about the math. We won’t do any. What matters for cloud work is where data is encrypted and who holds the keys.

Data is in one of two places: moving, or sitting still. Each needs its own protection.

7.1 Whoever holds the key holds the data

Encryption doesn’t make the problem disappear. It turns a big problem (“protect all this data”) into a small one (“protect this one key”). So where does the key live?

In the cloud, the answer is a key management service (KMS): AWS KMS, Google Cloud KMS, or Azure Key Vault. A KMS is a vault for keys with one clever rule: the main key never leaves the vault. You don’t download it. Instead, you send data in and ask “please lock this” or “please unlock this,” and the vault does it for you — if your identity is allowed to ask. Every request is logged.

(For big files, the vault uses a neat trick: it makes a fresh small key for each file, uses that to lock the file, and then locks the small key with the main key. A key in a lockbox, inside a vault. It’s called envelope encryption, and you’ll see the term in docs. You never have to do it by hand; the storage services do it for you.)

You get two choices of who controls the key:

• Provider-managed key — the default. The provider creates and handles the key. Zero effort, and it protects you against stolen hardware.
• Customer-managed key — you create the key in the KMS and decide, with an IAM policy, who may use it. More control: you can see every use, and you can disable the key to lock everything it protects at once. Some companies and regulations require this.

08Shared Responsibility, Revisited

Back in Notes 01, Plate 3.1 showed the stack of layers — from the building and its power at the bottom, up to your data and access control at the top — and showed how IaaS, PaaS, FaaS, and SaaS each move the line between “the provider runs it” and “you run it.” I promised then that Week 6 would add security to that picture. Here it is, and it’s simple: whoever operates a layer secures it.

Think of renting an apartment. The landlord takes care of the building: the front door lock, the walls, the wiring, the fire alarms. You take care of your own place: you lock your door, you decide who gets a spare key, and you don’t leave the window open when you go on vacation. If you hand your spare key to a stranger, that’s not the landlord’s fault. AWS’s own short version is that the provider handles security “of the cloud” and you handle security “in the cloud.”

Look at the top two rows. They say “You” in every column. That’s the dashed floor from Plate 3.1 — the part that never transfers. No matter how much you hand to the provider, who can reach your data is always your job. Which is exactly what Sections 01 through 07 were about.

One more honest detail: even in the provider’s rows, you often get a switch to flip. The provider builds the encryption, but you choose the key setting. The provider builds the firewall, but you write its rules (Week 5’s networking topic). The provider builds the storage service, but you decide whether a bucket is public. The provider gives you safe tools. Using them safely is on you.

09The Open-Door Problem

When you picture a “cloud breach,” you might picture a hacker in a hoodie breaking through clever defenses. That does happen. But it’s not the common story. The common story is much more boring: somebody left a door open. Security reports from the major providers and research firms say the same thing year after year: most cloud incidents trace back to the customer’s own settings — misconfiguration — not to the provider being broken into.

The classic example is the public bucket. Someone makes a storage bucket public “just for a minute” to test a download link. They forget to switch it back. Months later, someone running a tool that scans the internet for open buckets finds it — along with a spreadsheet of customer records that somebody else saved there later. Nobody broke in. The door was open, and the scanner simply walked through it. Stories like this have made news again and again, involving millions of records at a time. It happens often enough that the providers now make you click through extra steps before a new bucket can go public.

The good news: open doors are easy to close, and you can check them yourself. Here is the lock-down checklist for your own account. Do it this week. The list remembers your progress on this device.

• MFA on the root / owner login, then put that login away. Don’t use it for daily work.
• Make a separate everyday identity for yourself, with MFA too. Use it for all your project work.
• No long-lived access keys on servers. Programs in the cloud get roles (Section 05). Delete any keys you aren’t using.
• No public buckets unless the files are truly meant for the whole world (like a public website’s images). Leave “block public access” switched on everywhere else.
• No secrets in code or Git. Search your repos. Check that .env is in .gitignore.
• No “admin for convenience.” Every role your project uses gets only what its job needs (Section 04).
• Audit logging on — AWS CloudTrail, Google Cloud Audit Logs, or the Azure Activity Log — so you can answer “who did what, when?”
• Billing alert still set (from Week 1). A sudden bill is often the first sign of a stolen key. It’s your smoke detector.

10Self-Check

Seven quick questions. Pick an answer to see whether you’re right and why. Nothing is recorded; this is for you.

11Before Session 11 — October 12

The Project 2 specification is released this week. Project 2 is a containerized application with at least three cooperating services and a managed datastore, published to a registry and run under an orchestration platform. Every one of those pieces has to prove who it is and get permission for what it touches — which makes it a direct test of this week. The list remembers your progress on this device.

• Review Notes 06 with the labs open. In Plate 3.1, finish all four challenges. In Plate 4.1, build a policy where the job works and the attacker list is empty. In Session 11 you may be asked to explain, out loud, why an explicit Deny beats an Allow.
• Do the lock-down checklist in Section 09 on your course cloud account. All eight items. It takes less than an hour.
• Check your Project 1 repo for secrets. Search the full history, not just the current files — for example git log -p | grep -i -E "password|secret|key" — and look through what comes up. If you find a real secret, follow the three-step drill in Section 09: revoke it first.
• Read the Project 2 specification in the course repository, start to finish, before Session 11.
• Sketch your Project 2 identity map. For each service you plan, write one line: what it needs to read or write (the datastore? a bucket? the registry? a secret?) and nothing else. This becomes your least-privilege policy later.

11.1 Coming up: Notes 07 — Docker in depth (Oct 12 & 14)

Next week we go deep on container images: layers, registries, and good build practice — the foundation for Project 2. One teaser that connects straight back to Section 06: an image is built in stacked layers, and if you copy a secret into one layer and delete it in the next, it’s still sitting in the earlier layer for anyone who pulls the image. We’ll see exactly why, and how to build images that never contain a secret to begin with.

12Key Terms

Authentication (authN)

Proving who you are: password, MFA code, key. “Who are you?”

Authorization (authZ)

Deciding what an identity may do, based on policies. “What may you do?”

MFA

Multi-factor authentication: two different kinds of proof (know / have / are), so one stolen thing isn’t enough.

Root / owner account

The all-powerful login you signed up with. MFA it, store it, and don’t use it day to day.

User

One identity with a permanent login. An employee badge.

Group

A bundle of users who share the same permissions. Attach permissions once; move people in and out.

Role

AWS: an identity that people or programs step into for a while, with temporary credentials. GCP/Azure: a bundle of permissions you grant.

Policy

A written set of rules (Effect, Action, Resource) saying what is allowed or denied.

Implicit deny

The default: if no rule allows a request, it is denied.

Explicit deny

A rule with "Effect": "Deny". It beats every Allow. Used for guardrails.

ARN

Amazon Resource Name: AWS’s full address for a resource, e.g. arn:aws:s3:::my-photos/*.

Least privilege

Give each identity exactly the access its job needs, nothing more. The valet key.

Blast radius

How much damage spreads if one identity or component is compromised. Least privilege keeps it small.

Access key

A long-lived ID + secret pair for programs. Works until deleted, which is why leaks are so costly.

Temporary credentials

Short-lived keys handed out for a role, typically lasting about an hour and renewed automatically.

Service account / managed identity

Google Cloud’s and Azure’s identities for programs. The equivalent of attaching an AWS role to a server.

Secret

Any value that lets someone in: passwords, API keys, private keys. If it were on a billboard, you’d have to change it.

Environment variable

A named value passed to a program when it starts. Keeps secrets out of the code itself.

Secrets manager

A managed, encrypted, logged store for secrets (Secrets Manager / Secret Manager / Key Vault). Supports rotation.

Rotation

Replacing a secret or key with a new one on a schedule, or immediately after a leak.

Encryption in transit

Protecting data while it moves over a network, using TLS. The sealed envelope.

Encryption at rest

Protecting stored data on disks, buckets, databases, backups. The locked safe. Does not replace permissions.

KMS

Key management service: a vault where the main key never leaves; you ask it to lock and unlock data, and it logs every use.

Envelope encryption

Lock the data with a small per-file key, then lock that key with the main KMS key. A key in a lockbox.

Shared responsibility

Whoever operates a layer secures it. The provider secures the building and hardware; your data and access are always yours.

Misconfiguration

A setting left unsafe by the customer — public bucket, admin roles, leaked key. The most common cause of cloud incidents.

No term matches that filter.