How does a robot prove who it is, and order pizza safely?

Chapters

1. 1

   The teacher logs in

   Amazon Cognito

   Sign-in for people, without building a login system.

   Under the hoodA Cognito user pool authenticates the teacher over OAuth 2.0 and OpenID Connect and returns signed JWTs: an ID token (who signed in) and an access token (what this app may call). Any service can verify them offline against the pool's public signing keys (JWKS).

   Sources: Tokens · Verifying a JWT

   See it run: a live sign-in on this site

   Coming soon
2. 2

   The website has to be the real one

   AWS Certificate Manager

   The padlock that proves this site is really the school's.

   Under the hoodACM issues a public TLS certificate once a DNS record proves control of the domain, then renews it automatically while that record stays in place. To serve it from CloudFront, the certificate must live in us-east-1.

   Sources: DNS validation · Managed renewal · CloudFront requirements

   See it run: this site's own HTTPS certificate

   Coming soon
3. 3

   The badge office signs Robo's badge

   AWS Private Certificate Authority

   Running your own badge office for machines: first by hand, then managed.

   Under the hoodA private CA signs X.509 certificates that bind a workload's name to its public key, usually in a chain of root → subordinate → leaf. Doing it yourself means guarding the CA keys and publishing revocation; AWS Private CA runs the CA and offers revocation through CRLs, OCSP, or both.

   Sources: What is AWS Private CA · Revocation

   See it run: a certificate authority built with openssl

   Coming soon
4. 4

   Robo and the kitchen check each other's badges

   Mutual TLS

   Both sides prove who they are before they talk.

   Under the hoodIn mutual TLS, client and server each present a certificate, validate the other's chain back to a root they trust, and prove they hold the matching private key during the handshake. That settles who is talking, not what Robo may do; that's the next chapter.

   Sources: TLS 1.3, RFC 8446

   See it run: two tiny services shake hands

   Coming soon
5. 5

   The key desk hands out a temporary key

   AWS IAM, IAM Roles Anywhere, AWS STS

   Keys that expire, instead of one master key forever.

   Under the hoodIAM Roles Anywhere lets a workload outside AWS trade its X.509 certificate, issued by a CA registered as a trust anchor, for temporary STS credentials through a signed CreateSession call. Every request is then checked against IAM policy, where anything not explicitly allowed is denied, and once the credentials expire AWS stops accepting them.

   Sources: Roles Anywhere · CreateSession signing · Temporary credentials · Policy evaluation

   See it run: a long-lived key "before", short-lived credentials "after"

   Coming soon
6. 6

   Robo opens the locked treasure box

   AWS Secrets Manager

   Keeping a secret out of the code, and changing it without breaking anything.

   Under the hoodSecrets Manager encrypts each secret with an AWS KMS key and returns it only to callers whose IAM permissions allow GetSecretValue. Rotation runs on a schedule, through a Lambda function or managed rotation, so an app that reads the secret at runtime picks up the new value without a code change.

   Sources: Encryption · Rotation

   See it run: store, read, and rotate a secret

   Coming soon
7. 7

   Staff use their school logins

   AWS Directory Service

   Accounts for the people who work at the school, a different job from customer sign-in.

   Under the hoodAWS Managed Microsoft AD runs real Active Directory domain controllers, a highly available pair across Availability Zones, for workforce logins and Windows workloads. AD Connector instead forwards requests to a directory you already run on premises. Customer sign-in (chapter 1) is a separate problem.

   Sources: Managed Microsoft AD · AD Connector

   Explained, not run

   Coming soon