Role-based access control (RBAC) grants permissions through assigned roles, such as team membership, rather than managing access independently for every user. Authentication establishes who someone is; RBAC determines which platform resources that identity may use. section 7.3.1
A practical platform pattern keeps team membership in GitHub while using that membership across connected tools and infrastructure. CircleCI can map GitHub teams directly to context permissions; other SaaS tools may require an API that synchronizes membership. The same authorization system can govern Kubernetes resources and custom platform APIs. section 7.3.1
An implementation-oriented access flow is:
- Authenticate users through the corporate identity and GitHub integration. section 7.3.1
- Retrieve the user’s GitHub team memberships as authorization attributes. section 7.3.1
- Return secure access to permitted platform infrastructure or custom API resources. section 7.3.1
- Reuse the same credentials and permissions in observability tools so access remains frictionless without isolating teams from system-wide telemetry. section 5.2.1
Figure 7.8 For Epetech, we would like our IDP service to have built-in or easily configurable means of integrating with GitHub, requiring authentication through whatever means we have set up in GitHub. As a result of (1) successful authentication, we want the IDP to (2) get the list of all teams the user is a member of in our GitHub organization. Finally, we want to (3) return to the user a secure means of accessing the platform infrastructure or custom API resources.
Trace the identity-provider flow from GitHub authentication through team lookup to secure platform or custom API access. section 7.3.1
