Role-Based Access Control
Overview
Anchore Enterprise includes support for using Role-Based Access Control (RBAC) to control the permissions that a specific user has to a specific set of resources in the system. This allows administrators to configure specific, limited permissions on user enabling limited access usage for things like CI/CD automation accounts, read-only users for browsing analysis output, or security team users that can modify policy but not change image analysis configuration.
Anchore Enterprise provides a predefined and immutable set of roles:
- Full Control - All permissions on resources in the account
- Read Write- Standard user permissions
- Read Only - Read but no updates on all resources
- Policy Editor - Create/Update/Delete policies and view policy evaluations on images
- Account Users Admin - Add/delete/update users in the account
- Image Analyzer - Analyze, view, and evaluate policy on images
The Enterprise UI contains an enumeration of the specific permissions granted to users that are members of each of the roles.
Roles, Users, and Accounts
Roles are applied within the existing account and user frameworks defined in Anchore Enterprise. Resources are still scoped to the account namespace and accounts provide full resource isolation (e.g. an image must be analyzed within an account to be referenced in that account). Roles allow users to be granted permissions in both the account to which they belong as well as external accounts to facilitate resource-sharing.
Terminology
User: An authenticated identity (a principal in rbac-speak).
Account: A resource namespace and user grouping that also defines an authorization domain to which permissions are applied.
Role: A named set of permissions.
Permission: An action to grant an operation on a set of resources.
Action: The operation to be executed, such as listImages, createRegistry, and updateUser.
Target: The resource to be operated on, such as an image digest.
Role Membership: Mapping a username to a role within a specific account. This confers the permissions defined by the role to resources in the specified account to the specified user. The user is not required to be a member of the account itself.
Constraints
- A user may be a member of a role within one or more accounts.
- A user may be a member of many roles, or no roles.
- There is no default role set on a user when a user is created. Membership must be explicitly set.
- Roles are immutable. The set of actions they grant is static.
- Creating and deleting accounts is only available to users in the admin account. The scope of accounts and roles is different than other resources because they are global. The authorization domain for those resources is not the account name but rather the global domain: system.
Role Summary and Permissions
| Role | Allowed Actions | Description |
|---|---|---|
| Full Control | * | Full control over any account granted for. USE WITH EXTREME CAUTION |
| Account User Admin | listUsers, createUser, updateUser, deleteUser, listRoles, getRole, listRoleMembers, createRoleMember, deleteRoleMember | Manage account creation and addition of users to accounts |
| Read Write | createImage, createPolicy, createRegistry, createRepository, createSubscription, deleteEvents, deleteImage, deletePolicy, deleteRegistry, deleteSubscription, getAccount, getEvent, getImage, getImageEvaluation, getPolicy, getRegistry, getService, getSubscription, importImage, listEvents, listFeeds, listImages, listPolicies, listRegistries, listServices, listSubscriptions, updateFeeds, updatePolicy, updateRegistry, updateSubscription | Full read-write permissions for regular account-level resources, excluding user/role management |
| Read Only | listImages, getImage, listPolicies, getPolicy, listSubscriptions, getSubscription, listRegistries, getRegistry, getImageEvaluation, listFeeds, listServices, getService, listEvents, getEvent | Read only access to account resources, but includes policy evaluation permission |
| Policy Editor | listImages, listSubscriptions, listPolicies, getImage, getPolicy, getImageEvaluation, createPolicy, updatePolicy, deletePolicy | Edit policies, get evaluations of images, intended for users to set policies but not change the scanning configurations |
| Image Analyzer | listImages, getImage, createImage, getImageEvaluation, listEvents, getEvent, listSubscriptions, getSubscription | Submit images for analysis, get results, but not change config. Intended for CI/CD systems and automation |
| inventory-agent | syncInventory | Minimal permissions for use with runtime inventory agents (k8s or ECS) |
| repo-analyzer | createRepository | Permission to add to other roles (e.g. read-only) to allow analysis of repositories only |
| report-admin | listImages, createScheduledQuery, updateScheduledQuery, executeScheduledQuery, deleteScheduledQuery, deleteScheduledQueryResult | Permissions to administer reports and schedules |
Enabling RBAC using the Helm Chart
The chart provides a set of flags to enable to use Enterprise, and RBAC is configured by default when those are set.
The flags are:
- anchoreEnterpriseGlobal.enabled=true
- anchoreEnterpriseRbac.enabled=true
This will have the effect of adding some containers to the anchoreAPI deployment pods that run the RBAC Manager and RBAC Authorizer services as well as configuring the api endpoints to use the authorizer correctly.
NOTE: if you have already installed Anchore and have created accounts and users, enabling RBAC will cause all non-admin users to have no permissions or API access to authorization-gated routes (most API calls) until you explicitly assign each user one or more roles. The configuration and install process for RBAC does not automatically assign roles to existing users.
Granting Cross-Account Access
The Anchore API supports a specific mechanism for allowing a user to make requests in another account’s namespace, the x-anchore-account header. By including x-anchore-account: "desiredaccount" on a request, a user can attempt that request in the namespace of the other account. This is subject to full authorization and RBAC.
To grant a username the ability to execute operations in another account, simply make the username a member of a role in the desired account. This can be accomplished in the UI or via API against the RBAC Manager service endpoint. For example, using curl:
curl -u admin:foobar -X POST -H "Content-Type: application/json" -d '{"username": "someuser", "for_account": "some_other_account"}' http://localhost:8229/roles/policy-editor/members
This should be done with caution as there is currently no support for resource-specific access controls. A user will have the permitted actions on all resources in the other account (based on the permissions of the role). For example, making a user a member of policy-editor role for another account will enable full ability to create, delete, and update that account’s policy bundles.
WARNING: Because roles do not currently provide custom target/resource definitions, assigning users to the Account User Admin role for an account other than their own is dangerous because there are no guards against that user then removing permissions of the granting user (unless that user is an ‘admin’ account user), so use with extreme caution.
NOTE: admin account users are not subject to RBAC constraints and therefore always have full access to add/remove users to roles in any account. So, while it is possible to grant them role membership, the result is a no-op and does not change the permissions of the user in any way.
Last modified August 27, 2023