Securing access with role-based access control (RBAC)
Securing access with role-based access control (RBAC)
Section titled “Securing access with role-based access control (RBAC)”Effective access control is the first line of defense in securing a container registry. STACKIT Container Registry employs a robust Role-Based Access Control (RBAC) model to ensure that users and automated systems only have the permissions necessary to perform their intended functions, adhering to the principle of least privilege.
The RBAC model
Section titled “The RBAC model”RBAC is a security methodology that simplifies permission management by abstracting permissions into a set of defined roles. Instead of assigning granular permissions to individual users, administrators assign users to one or more roles. Each role is a collection of permissions that dictates what actions a user can perform on specific resources.
Project-level roles
Section titled “Project-level roles”STACKIT Container Registry defines five distinct project-level roles, each with a progressively larger set of permissions:
- Project Admin: This role has complete administrative control over a specific project. A Project Admin can manage project members (add, remove, change roles), configure project settings (e.g., immutability rules, webhooks), and perform all actions available to lower-level roles. The user who creates a project is automatically assigned the Project Admin role.
- Maintainer: This role is designed for team leads or senior developers. A Maintainer has all the permissions of a Developer but can also perform additional actions like deleting images and Helm charts, viewing replication jobs, and manually triggering vulnerability scans.
- Developer: This is the standard role for software engineers who contribute to a project. A Developer has fundamental read and write privileges, meaning they can push new images to the project’s repositories and pull existing images from them.
- Guest: This role provides read-only access to a project. A Guest can pull images and retag them locally but cannot push new images or modify the content of the registry.
- Limited Guest: This is the most restrictive role, offering a constrained form of read-only access. A Limited Guest can pull images but cannot see the project’s activity logs or the list of other project members.
RBAC permission matrix
Section titled “RBAC permission matrix”The following table summarizes the key permissions associated with each project-level role.
| Action | Project Admin | Maintainer | Developer | Guest | Limited Guest |
|---|---|---|---|---|---|
| Artifact Management | |||||
| Pull Image/Artifact | ✓ | ✓ | ✓ | ✓ | ✓ |
| Push Image/Artifact | ✓ | ✓ | ✓ | ||
| Delete Image/Artifact | ✓ | ✓ | |||
| Retag Image | ✓ | ✓ | ✓ | ✓ | |
| Add/Remove Artifact Labels | ✓ | ✓ | ✓ | ||
| Repository Management | |||||
| Create Repository | ✓ | ✓ | ✓ | ||
| Delete Repository | ✓ | ✓ | |||
| Security & Scanning | |||||
| Trigger Vulnerability Scan | ✓ | ✓ | |||
| View Vulnerability Report | ✓ | ✓ | ✓ | ✓ | ✓ |
| Project Configuration | |||||
| View Project Configuration | ✓ | ✓ | ✓ | ✓ | ✓ |
| Edit Project Configuration | ✓ | ||||
| View Project Members | ✓ | ✓ | ✓ | ✓ | |
| Add/Remove Project Members | ✓ | ||||
| View Project Logs | ✓ | ✓ | ✓ | ✓ | |
| Configure Webhooks | ✓ | ✓ | ✓ | ||
| Configure Immutability Rules | ✓ | ✓ | |||
| Configure Retention Policies | ✓ | ✓ | ✓ |