2 min lesson
Machine clients, scopes and audit
Name the key items in "Machine clients, scopes and audit", then explain why each one matters.
Step 1 of 2
Machine clients, scopes and auditthe parts juniors forget
- Service accounts get their own role model. A CI bot is not a person with a person's role; give it a machine principal with least-privilege scopes and no interactive session.
- Token scopes enforce least privilege per-credential. Even an admin's token, when minted for a read-only task, should carry read-only scope. Scope narrows the breach when a single token leaks.
- The authz path must be fast and centralized. A check on every product surface that disagrees with the others is a contract bug; a shared decision service (or shared library + cache) is the fix and it's a service-contract problem, not a feature.
- Audit every authz decision. "Who accessed what, when and was it allowed" is both an incident-response tool and a hard requirement in enterprise security reviews. Logging only denials is not enough; sales will ask for the allows too.
When the design veers into per-repo sharing, say the word "Zanzibar" and explain the shape: "RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition. handles org roles, but repo-level sharing is relationship data - user relates to repo as viewer - which is what ReBAC systems like SpiceDB model." Naming the pattern and its limits reads as senior; pretending RBAC alone covers per-resource sharing reads as someone who hasn't run a multi-tenant product.
Don't centralize authz into a synchronous service on the request hot path without a caching and fallback story. If the authz service is a hard dependency for every API call and it goes down, you've coupled all of product reliability to one box. Cache decisions, set sane TTLs and decide deliberately whether to fail open or closed per surface.