IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Cloud identity 101 — principals, roles & policies
Kai's app just started in the cloud. Its first job is to read one file from a storage bucket. The cloud asks two questions first: who is this app, and what may it do? Your goal: answer both questions for a machine.
- Every identity that makes a request is a principal.
- A role is a bundle of permissions. A policy holds the rules.
- The default answer is deny.
- Assume a role to get temporary keys. Do not store long-lived keys.
Who is asking? The principal
The cloud calls every identity that can make a request a principal. A human principal is a person, like Priya signing in to the console. A workload principal is a machine identity for a running app, a job or a function. Kai's app is a workload principal.
Picture a delivery robot at an apartment gate. It is not the flat owner, so it must not use the owner's key. It carries a pass of its own, with its own name. In the cloud, that named pass is a principal.
Code needs an identity of its own, as in the non-human identities lesson. It must never borrow a person's login.
What may it do? Roles and policies
A role is a named bundle of permissions that a principal can take on. A role is not a person. Nobody logs in as a role. Kai's app steps into the "read-only" role for a short time.
A policy says what the role may do. It is a set of rules: who may do which action on which resource. For example: allow read on bucket/reports/*. The cloud checks the policy on every request. The default answer is deny. You get only what a rule clearly allows.
a hotel. You (the principal) show your ID at the desk. You get a keycard for the "housekeeping" role. It opens some doors, until checkout. The lock's rulebook (the policy) decides at each door.
Assume the role, get temporary keys
Do not paste a long-lived key into Kai's app. Let the app assume a role instead. The cloud's identity service then gives back temporary credentials. These are keys that expire soon, often in about an hour. They work for that one role only. Nothing lasting sits on disk. Compare the two:
🔑 Long-lived static key
A permanent secret in a config file. It never expires. It leaks in logs and screenshots. A stolen copy works until somebody notices.
⏱️ Temporary credentials
Made on demand. They expire in about an hour. A leaked copy soon stops working. This is the modern default.
Give the "read-only" role no delete permission, and a hacked app cannot delete. Temporary credentials shrink the damage more. A stolen key opens little, for a short time.
Go deeper: two kinds of policy, and when they disagree
Rules can be attached in two places. An identity-based policy is attached to the principal or the role. It says: this identity may read that bucket. A resource-based policy is attached to the resource. It says: this bucket may be read by that identity.
Both say "who may do what on which resource", from opposite ends. This is like policy as code.
Clouds differ in the details, but the usual rules are the same. If no rule allows the action, the answer is deny. If one rule allows it and another clearly denies it, the deny wins. Read your own cloud's rules before you mix policies.
Clouds also use different words. One says role, another says service account, another says managed identity. The idea is the same. A workload takes on an identity and gets short-lived credentials.
🧪 Interactive lab — enable JavaScript to play with this one.
Grade a cloud trust or resource policy for confused-deputy and wildcard risk with IAM Trust Check. Inspect the workload identity behind an assumed role with SPIFFE Scan.