Authentication & Authorization
Authentication proves identity, authorization grants access. Master passwords, MFA, tokens, JWT, OAuth 2.0 / OIDC and RBAC so you can secure both humans and machines.
What is this?
Authentication answers who are you; authorization answers what may you do. In DevOps you must secure humans (SSO, MFA) and machines (service accounts, tokens, workload identity). OAuth 2.0 / OIDC provide the modern token ecosystem, and JWT is the token format almost everything uses.
Why do you need it?
- Weak or stolen credentials are the number one way attackers enter systems — identity is the new perimeter.
- Authorizing by identity instead of shared secrets lets you revoke one person without breaking everyone.
- OIDC plus short-lived tokens shrink the window in which a leaked token is useful.
- Machine identities (service accounts, workload identity) need the same rigor as human identities.
- RBAC makes who-can-do-what reviewable, auditable and revocable.
Mental model
An airport security line
Authentication and authorization
First you prove who you are with your boarding pass (authentication). Then your ticket determines which gate, seat and lounge you may enter (authorization). One step proves identity; the other grants scope.
How it works
- Authentication verifies identity via something you know (password), have (MFA device, key) or are (biometrics).
- MFA combines factors so a stolen password alone is not enough.
- The system then issues an assertion — a session cookie or token — that carries the authenticated identity.
- Authorization systems (RBAC, ABAC, policies) evaluate that identity against the permissions of the resource.
- Tokens are typically short-lived JWTs signed by the identity provider, verified by the resource without a round trip.
The OIDC authorization code flow.
Key commands
kubectl auth can-i get podsAsk the cluster whether your current identity may list pods.
kubectl auth can-i create secrets --as=system:serviceaccount:default:builderCheck permissions as if you were a given service account.
kubectl get roles,rolebindings,clusterroles,clusterrolebindings -A | head -20Dump the RBAC surface so you can audit who can do what.
id && whoamiInspect local account identity and group membership.
curl -sI https://auth.example.com/oauth2/authorize | head -5Confirm an OAuth authorization endpoint is reachable and enforcing TLS.
Examples
Inspect a token and test authorization
kubectl auth can-i get pods --as=system:serviceaccount:default:appkubectl auth can-i delete pods --as=system:serviceaccount:default:appkubectl auth can-i --list | head -15kubectl auth can-i answers authorization questions directly against the API server's RBAC engine, both for your own identity and impersonated identities like a service account. The list variant prints the full permission matrix.
In production
- SSO via OIDC (Okta, Entra ID, Keycloak) so humans authenticate once with MFA enforced.
- Kubernetes RBAC scopes ServiceAccounts to the namespace and workload they serve.
- CI/CD platforms federate through OIDC so pipelines get short-lived cloud tokens without long-lived static keys.
- Fine-grained authorization (OPA/Kyverno, IAM conditions, ABAC) evaluates policies on every request.
- Session and token revocation is wired to the identity provider so a fired employee loses access instantly.
Best practices
- Enforce MFA for every human account, especially administrators.
- Prefer short-lived tokens and refresh them; never issue tokens that never expire.
- Give service accounts and roles the smallest scope that works (least privilege).
- Store password hashes with a slow, salted algorithm (bcrypt, argon2) — never plaintext.
- Log authentication and authorization decisions to an immutable audit trail.
Common mistakes
- Using the same long-lived API key for every environment.
- Putting tokens in the client where anyone with the bundle can steal them.
- Authorizing by is-the-token-valid without checking scope or audience.
- Granting admin to whole teams because individual roles are too much work.
- Trusting a JWT without verifying its signature and expiry.
Common issues
401 Unauthorized on an API callMissing, expired or malformed bearer token
Re-authenticate, check the token expiry claim, and confirm it is sent in the Authorization header.
403 Forbidden despite a valid tokenToken is valid but the identity lacks the permission
Review the subject's roles/grants and the resource's policy; test with can-i.
Token valid in dev but rejected in prodDifferent signing keys or audience between environments
Align the OIDC issuer, audience and JWKS across environments and rotation.
Debugging tips
- Decode the JWT payload to confirm the expected issuer, subject, expiry and scopes.
- Test authorization with kubectl auth can-i to isolate policy from network issues.
- Check the identity provider logs: a failed login has an explicit reason (bad password, MFA declined, disabled user).
- Verify the audience claim — a token minted for API A must be rejected by API B.
Interview checkpoint
Hands-on lab
- Read account identity and group membership
- Apply file permissions with chmod
- Change ownership with chown
- Audit a directory tree for exposure
Linux Permissions & Access Control
25 min · intermediate
Quick quiz
Which step happens first in the AAA model?
A valid, unexpired JWT from the right issuer still returns 403. What is the most likely cause?
JWT claims like iss and exp must be validated by the receiving service before trusting the token.
Cheat sheet
header.payload.signatureJWT structure (base64url segments)iss / sub / exp / audIssuer, subject, expiry, audience claimsAuthorization: Bearer <token>Standard way to send access tokenskubectl auth can-iTest RBAC authorization instantlyMFASomething you know + something you haveOIDCOAuth 2.0 + identity layer for SSOService accountMachine identity with scoped permissionsRefresh tokenShort-lived access, revocable refresh