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
Cheat sheet & pop quiz
Here is the whole track on one page. You get a cheat sheet, a lookup table, and five scenarios to prove it stuck.
Seven ideas that harden every workload
| # | If you remember nothing else… |
|---|---|
| 1 | A cloud principal is often not a person. A workload assumes a role and gets short-lived credentials. Delete the long-lived access key. |
| 2 | Workload identity federation: a build job shows a signed identity it already has. It gets short-lived cloud credentials. No stored secret. |
| 3 | In a mesh, give every service a name that can be checked: a SPIFFE ID in an SVID. Services prove it with mTLS. No shared password. |
| 4 | A real secret goes in a secrets manager. Fetch it at run time. Keep it limited, short-lived and rotated. Never paste it in a config file. |
| 5 | To cross an account or cloud, use a trust policy. Name one principal and demand a condition, such as an external ID. That stops the confused deputy. |
| 6 | Least privilege is the exact shape of the job: verb plus resource, no wildcards. A guardrail caps the maximum. JIT elevation removes standing privilege. |
| 7 | In Kubernetes, every pod runs as a ServiceAccount with a bound token that dies with the pod. Keep RBAC to one namespace. Reading Secrets, creating pods, exec, bind/escalate and wildcards are admin in disguise. Reach the cloud by federation pinned to one ServiceAccount. |
Cloud identity need → the right move
| The need… | …the right move |
|---|---|
| An app needs cloud access | Give it a workload identity. Let it assume a role for short-lived credentials. No static key (Cloud identity 101) |
| CI needs to deploy | Workload identity federation: show the pipeline's signed identity, get short-lived credentials, store no secret (workload identity federation) |
| Service-to-service inside the mesh | SPIFFE SVIDs and mTLS: each side proves its identity on every call (SPIFFE, SVIDs & mTLS) |
| A real secret must exist | Secrets manager, short lives and automatic rotation, fetched at run time (secrets management) |
| Access across accounts or clouds | A trust policy that names the principal, plus a condition to stop the confused deputy (cross-account trust) |
| How much to grant a machine | Least privilege (verb plus resource, no wildcards) and a guardrail limit (least privilege for machines) |
| A pod in Kubernetes needs the API or the cloud | Its own ServiceAccount and bound token, a RoleBinding in one namespace with no climbing verbs, and federation pinned to that ServiceAccount. No key in a Secret (Kubernetes identity) |
Pop quiz — five questions
Q1 · A developer pastes a permanent cloud access key into the CI settings so the pipeline can deploy. Six months later the key leaks from a build log. What should they have used instead? Why does it avoid this?
Workload identity federation. The pipeline shows the signed token it already has. The cloud trusts that issuer and subject, and gives back short-lived credentials. No long-lived key sits in the settings. The credential expires soon, so it cannot be replayed later (workload identity federation).
Q2 · Account B's trust policy says "any principal in account A may assume the data-reader role". A low-privilege, multi-tenant workload in account A is tricked into assuming it for an attacker. Name the problem and the fix.
This is the confused deputy. A trusted, powerful deputy is tricked into using its power for someone else. The fix is to name the specific principal in the trust policy. Then add a condition, usually an external ID that the real caller must send. The deputy cannot be made to send the victim's external ID. So the assume-role fails with 403 AccessDenied, even though the account is otherwise allowed (cross-account & cross-cloud trust).
Q3 · An imposter workload in the service mesh calls the billing service. It claims to be the orders service. Billing accepts only a verified identity on every call. What stops the imposter?
Each service has a SPIFFE identity in an SVID. The two sides use mTLS, which is mutual TLS. Both ends show and check a certificate. The imposter has no SVID for the orders identity signed by the mesh's trust domain. The handshake fails, and billing never reads the request. Identity is proven for each connection, not claimed in a header (SPIFFE, SVIDs & mTLS).
Q4 · An app uses a static database password. It has sat in an environment variable for two years. It leaks. Besides changing it once, what is the lasting fix?
Move the secret into a secrets manager. The app fetches the credential at run time with its own workload identity. The secret is short-lived and rotated automatically. It never sits in an environment variable or config file. A leaked value stops working soon. The fetch is tied to the workload's identity, not to a shared string (secrets management & rotation).
Q5 · A workload was given admin:* "just to make it work". A bad dependency takes it over. The attacker deletes the production database and creates a new admin user. Which two controls would have contained this?
First, least privilege. Trim the policy to what the job uses, such as queue:read and storage:write on one bucket. Then the attacker inherits little. Second, a guardrail (permission boundary) that caps the maximum for every identity in the organization. Then delete-all and create-admin never go through, even if a policy grants them. Add JIT elevation so dangerous abilities are not standing privilege at all (least privilege for machines).
That is the whole Cloud & Workload track. Machines are federated instead of stored. They are checked in the mesh instead of just claiming a name. They are kept in a vault and rotated instead of pasted. They are trusted across borders by name and condition. They are trimmed so a breach gets almost nothing. In Kubernetes they carry bound tokens and tight RBAC. Next up is Identity Architecture, the drawing board for the real thing. Start at putting the whole picture together.
Put it to the test. Browse our free security micro-tools at the tools shelf, or explore our services. Talk to our team when you are ready to design the real thing.