Governance Service Authentication and RBAC
Governance Service relies on Auth Service to validate identity and role permissions. A request can represent a signed-in user, a user API key, or a platform service account depending on the workflow.
Access Model
Section titled “Access Model”Access is based on project and organization roles. Governance Service checks those roles before allowing users to view projects, apply policies, manage controls, create declarations, record reviews, manage indicators, or work with credentials.
Users should be assigned the least role that supports their work. Project-specific work should normally be granted through project membership rather than broad organization ownership.
Common Role Expectations
Section titled “Common Role Expectations”- Organization Owner can administer organization-wide settings, users, projects, policies, and governance workflows.
- Project Owner can manage project settings, members, applied policies, indicators, declarations, reviews, and credentials.
- Implementation Owner and Implementation Contributor can create implementation evidence for controls.
- Audit Owner and Audit Contributor can participate in review workflows, with Audit Owner able to record outcomes and manage credentials.
- Project Viewer can inspect project data without changing it.
Integrator Guidance
Section titled “Integrator Guidance”Integrations should use API keys or service accounts only when machine access is required. Store credentials in a secrets manager, rotate them regularly, and scope them to the smallest practical set of workflows.
If an integration can authenticate but cannot perform an action, check the project context and assigned role before treating the issue as a service outage.