cloud-identity-and-authlisted

# Cloud Identity and Authentication Identity is the bedrock of cloud security. Every API call, every internal RPC, every resource access must ultimately be attributable to a principal — a user, a service account, a workload — and must be authorized against a policy that the platform enforces uniformly. Getting this layer right is what separates a cloud platform from a collection of servers. Getting it wrong is the source of most breach post-mortems. This skill covers the core concepts and failure modes a cloud-systems practitioner has to handle. **Agent affinity:** hamilton-cloud (IAM at AWS scale), vogels (service-to-service identity in SOA), lamport (formal reasoning about capability and delegation) **Concept IDs:** cloud-keystone-auth, cloud-security-groups-policies, cloud-requirements-tracing ## The Three Questions Every identity system answers three questions in order: 1. **Authentication (authn).** Who are you? Prove it. 2. **Authorization (authz).** What are you allowed to do? 3. **Accounting.** What did you do? (Audit logs.) Separating these cleanly is the first design decision. Authentication produces an attested identity (a token, a certificate, a signed assertion). Authorization consumes that identity and a resource reference and returns allow/deny. Accounting records both. ## The Keystone Model: Scoped Tokens OpenStack Keystone — and most cloud platforms that followed — use a scoped token model. A user authenticates and requests a token scoped to a projec