Access Control
Learn how role-based access control (RBAC) governs permissions across organizations, projects, and resources
Access Control
KtrlPlane uses a robust Role-Based Access Control (RBAC) system to ensure that users have exactly the permissions they need—no more, no less. Permissions are managed hierarchically across three scopes: Organization, Project, and Resource.
Permission Scopes
Access can be granted at three different levels. Permissions granted at a higher level automatically inherit down to lower levels.
| Scope | Description | Example |
|---|---|---|
| Organization | The top-level boundary. Roles assigned here apply to the entire organization and all projects within it. | granting Owner on the Organization gives full control over all projects. |
| Project | A workspace for related resources. Roles assigned here apply to all resources within the project. | Granting Viewer on a Project allows a user to see all resources in that project. |
| Resource | The individual deployable unit (e.g., a specific Graph or Secret). Roles assigned here apply ONLY to that specific resource. | Granting Editor on a specific Secret allows modifying that secret but nothing else. |
System Roles
KtrlPlane provides a set of pre-defined roles designed to cover common access patterns. These roles are categorized into Platform Access, Data Access, and Resource-Specific Access.
Platform Access Roles
These roles control access to the KtrlPlane control plane (configuration, deployment, settings).
| Role | Permissions | Best For |
|---|---|---|
| Owner | Full administrative access. Can manage billing, users, roles, and delete the scope (Project/Org). | Organization Admins, Project Leads |
| Editor | Can create, update, and delete resources. Cannot manage user access or billing. | Developers, DevOps Engineers |
| Viewer | Read-only access to configuration and status. Cannot make any changes. | Auditors, Support Staff, Stakeholders |
Data Access Roles
These roles control access to the data plane—the actual data stored within your resources.
| Role | Description |
|---|---|
| Konnektr.Data.Owner | Grants full access to the data within resources. For example, allows querying all nodes in a Graph or reading values in a Secret. |
Control Plane vs. Data Plane: An Editor can change the configuration of a database (Control Plane) but might not have permission to read the customer data inside it (Data Plane). Assign Konnektr.Data.Owner to grant data access.
Resource-Specific Roles
These roles are tailored for specific resource types and offer more granular control.
- Konnektr.Graph.Owner, Konnektr.Graph.Editor, Konnektr.Graph.Viewer
- Konnektr.Flow.Owner, Konnektr.Flow.Editor, Konnektr.Flow.Viewer
- Konnektr.Secret.Owner, Konnektr.Secret.Editor, Konnektr.Secret.Viewer
Use these when you need to grant access to a specific type of resource without granting blanket access to the entire project.
Inheritance Model
Permissions are additive and hierarchical.
- Organization Owner implies Project Owner for all projects.
- Project Viewer implies Resource Viewer for all resources in that project.
Best Practice: Assign roles at the Project level for teams to reduce management overhead. Use Resource level assignments only for exceptions (e.g., a specific secret that only one person should see).
Managing Access
To manage access:
- Navigate to the scope you want to manage (Organization Settings, Project Settings, or Resource Details).
- Click on the "Access" or "Permissions" tab.
- Click "Add Assignment".
- Select the User (by email) and the Role.
- Save the assignment.
Effective permissions are calculated instantly, allowing users immediate access.