Role-Based Access Control (RBAC)

🔑 Key Takeaway: Assign permissions to roles tied to job functions, not named individuals, and review those roles so privileges do not accumulate silently.

Role-Based Access Control (RBAC) regulates access based on roles assigned to people (and sometimes services) in a project. Well-designed RBAC keeps each principal at the minimum access needed for their function and reduces accidental or malicious privilege use.

Key principles

• Role definition: Define roles from job responsibilities. Each role must carry a specific permission set. Example: a community manager may not need admin rights on the project's GitHub organization.
• Role assignment: Assign roles from responsibilities. Principals must only reach the resources they need.
• Permission management: Review and update role permissions as functions and tooling change.
• Separation of duties: Split critical powers so no single persona can complete a high-impact action alone when the risk model requires dual control.

Practices

1. Start from deny-by-default; add capabilities only when a role proves need.
2. Prefer fewer, well-named roles over snowflake personal grants, except short-lived exceptions under access management.
3. Document privileged roles (billing admin, root cloud, multisig admin-adjacent SaaS) with owners and review cadence.

Further Reading

• IAM overview
• Access management
• Secure authentication
• Guides — Account Management