This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

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 of roles. Please see table below for complete list.

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

  1. A user may be a member of a role within one or more accounts.
  2. A user may be a member of many roles, or no roles.
  3. There is no default role set on a user when a user is created. Membership must be explicitly set.
  4. Roles are immutable. The set of actions they grant is static.
  5. 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

RoleAllowed ActionsDescription
full-control*Full control over any account granted for. USE WITH EXTREME CAUTION
account-user-adminlistUsers, createUser, updateUser, deleteUser, listRoles, getRole, listRoleMembers, createRoleMember, deleteRoleMember, getAccount, listApiKeys, createApiKey, getApiKey, updateApiKey, deleteApiKeyManage account creation and addition of users to accounts.
account-viewerlistAccountsRole which can list all accounts on the system. This role is only available for use in the system domain. This role can only be conferred by a system administrator.
image-analyzerlistImages, getImage, createImage, getImageEvaluation, listEvents, getEvent, listSubscriptions, importImage, importSource, getSubscription, getAccount, listSources, getSource, importSource, getSourceEvaluation, listSubscriptions, updateSubscription, getSubscription, deleteSubscription, createSubscription, createArtifactRelationships, listArtifactRelationships, viewReports,Submit images for analysis, get results, but not change config. Intended for CI/CD systems and automation.
image-developerlistImages, getImage, listPolicies, getPolicy, listSubscriptions, getSubscription, listRegistries, getRegistry, getImageEvaluation, listFeeds, listServices, getService, listEvents, getEvent, listArchives, listArchiveTransitionRules, getArchiveTransitionRule, listArchivedImageAnalysis, getArchivedImageAnalysis, getArchiveTransitionRuleHistory, getAccount, listNotificationEndpoints, listNotificationEndpointConfigurations, getNotificationEndpointConfiguration, getActions, listAlerts, getAlert, getCorrection, getApplication, listSources, getSource, getSourceEvaluation, listArtifactRelationships,Permissions view images, vulnerabilities and policy evaluations.
image-lifecyclecreateArchivedImageAnalysis, createArchiveTransitionRule, deleteArchivedImageAnalysis, deleteArchiveTransitionRule, deleteArchiveTransitionRuleHistory, getArchivedImageAnalysis, getArchiveTransitionRule, getArchiveTransitionRuleHistory, listArchivedImageAnalysis, listArchives, listArchiveTransitionRules,Permissions to manage archives and archival rules.
inventory-agentsyncInventoryMinimal permissions for use with runtime inventory agents (k8s or ECS).
read-writecreateImage, createPolicy, createRegistry, createRepository, createSubscription, deleteEvents, deleteImage, deletePolicy, deleteRegistry, deleteSubscription, getAccount, getEvent, getImage, getImageEvaluation, getPolicy, getRegistry, getService, getSubscription, importImage, importSource, listEvents, listFeeds, listImages, listPolicies, listRegistries, listServices, listSubscriptions, updateFeeds, updatePolicy, updateRegistry, updateSubscription, listArchives, listArchiveTransitionRules, getArchiveTransitionRule, createArchiveTransitionRule, deleteArchiveTransitionRule, listArchivedImageAnalysis, getArchivedImageAnalysis, createArchivedImageAnalysis, deleteArchivedImageAnalysis, getArchiveTransitionRuleHistory, listNotificationEndpoints, listNotificationEndpointConfigurations, getNotificationEndpointConfiguration, createNotificationEndpointConfiguration, updateNotificationEndpointConfiguration, deleteNotificationEndpointConfiguration, listRuntimeInventories, getRuntimeInventory, createRuntimeInventory, syncInventory, deleteInventory, getActions, addAction, listAlerts, getAlert, createAlert, updateAlert, getCorrection, addCorrection, updateCorrection, deleteCorrection, createApplication, getApplication, deleteApplication, updateApplication, listSources, getSource, importSource, getSourceEvaluation, createArtifactRelationship, listArtifactRelationships, deleteArtifactRelationships, getArtifactRelationshipDiff, createScheduledQuery, updateScheduledQuery, executeScheduledQuery, deleteScheduledQuery, deleteScheduledQueryResult, viewReports, getKubernetesContainers, getKubernetesClusters, getKubernetesNamespaces, getKubernetesNodes, getKubernetesPods, getKubernetesVulnerabilities, listRuntimeInventories, getECSContainers, getECSServices, getECSTasksFull read-write permissions for regular account-level resources, excluding user/role management.
read-onlylistImages, getImage, listPolicies, getPolicy, listSubscriptions, getSubscription, listRegistries, getRegistry, getImageEvaluation, listFeeds, listServices, getService, listEvents, getEvent, listArchives, listArchiveTransitionRules, getArchiveTransitionRule, listArchivedImageAnalysis, getArchivedImageAnalysis, getArchiveTransitionRuleHistory, getAccount, listNotificationEndpoints, listNotificationEndpointConfigurations, getNotificationEndpointConfiguration, listRuntimeInventories, getRuntimeInventory, getActions, listAlerts, getAlert, getCorrection, getApplication, listSources, getSource, getSourceEvaluation, listArtifactRelationships, viewReports, getKubernetesContainers, getKubernetesClusters, getKubernetesNamespaces, getKubernetesNodes, getKubernetesPods, getKubernetesVulnerabilities, listRuntimeInventories, getECSContainers, getECSServices, getECSTasksRead only access to account resources, but includes policy evaluation permission.
policy-editorlistImages, listSubscriptions, listPolicies, getImage, getPolicy, getImageEvaluation, createPolicy, updatePolicy, deletePolicy, getAccount, getCorrection, listSources, getSource, getSourceEvaluation, viewReports,Edit policies, get evaluations of images, intended for users to set policies but not change the scanning configurations.
repo-analyzercreateRepository, updateSubscription (specifically for activation of type repo_update)Permission to allow analysis of repositories.
report-adminlistImages, createScheduledQuery, updateScheduledQuery, executeScheduledQuery, deleteScheduledQuery, deleteScheduledQueryResult, viewReports,Permissions to administer reports and schedules.
registry-editorcreateRegistry, deleteRegistry, getRegistry, listRegistries, updateRegistry,Permissions to manage registry credentials.

Note: All account scoped roles have these roles implicitly granted as well: selfListApiKeys, selfCreateApiKey, selfUpdateApiKey, selfDeleteApiKey, selfGetApiKey, selfGetCredentials, selfAddCredential, selfDeleteCredential

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.

1 - User Groups

Overview

User groups are abstractions that allow an administrator to manage permissions for users across the system without having to manage each individual user’s permissions.

Administrators simply have to create a user group, define roles per accounts within the user group and then associate users with it. Users can be associated with multiple user-groups. Each user inherits roles from their user group as well as any explicitly defined roles.

Users can be explicitly added to a User Group (as described above) or SAML users can have an indirect membership of a user group based on their IDP associations.

Note: User Group management is strictly limited to admin users only.

Terminology

  • User Group: A basic resource that grants roles and permissions to users on various accounts
        "name": "user-group-engineers",
        "description": "The group permissions for all engineers",
  • User Group Roles: A collection of roles associated with a user group, this can span multiple accounts and have multiple roles per account. E.g.
    [  
        {Account: "devs_account",    Roles: [“policy-editor”,”image-analyzer”]},
        {Account: "devops_account",  Roles: [“read-write”]},
        {Account: "preview_account", Roles: [“read-only”]}
    ]
  • IDP User Group Mappings: A set of User Groups that are mapped to a single Identity provider. E.g.
    {
        IDP Name: "keycloak", 
        User Groups: [“user-group-engineers”, ”user-group-devsec”, ”user-group-auditors”]}
  • User Group Native User Member: A native user who has been explicitly associated with a User Group. This user inherits all roles from the User Group in addition to any roles assigned directly to this user.
  • User Group IDP Member: An SAML user who is an indirect member of a User Group. As the SAML user authenticates, the IDP’s User Group Mappings are used to determine if this user should be associated with a User Group.

Native users

Native users are users that are defined in Anchore Enterprise and do not authenticate using an external SSO endpoint. These users can be added to User Groups directly and inherit roles from the User Groups they are members of.

SAML(SSO) users

SAML users are users that authenticate using an external SAML IDP. These users can be associated with User Groups based on their group memberships in the SAML IDP.

SAML users are automatically added to a User Group based on their group memberships in the SAML IDP and the IDP’s User Group associations.

User Group management

User Groups can be managed from the Anchore Enterprise UI or using the Anchore Enterprise API.

AnchoreCTL

User Groups can be managed using the anchorectl CLI tool. The following commands are available for User Group management:

  • To create a new User Group, use the following command:
# anchorectl usergroup add development --description "The development team"
 ✔ Added usergroup                                                                                                                                                                                                       
Name: development
Description: The development team
Group Uuid: 4a5d8357-1fc3-44cf-8a1c-9882406df656
Created At: 2024-03-20T15:57:20.086665Z
Last Updated: 2024-03-20T15:57:20.086669Z
Account Roles:
  Items: 
  • To list all User Group, use the following command:
# anchorectl usergroup list
┌─────────────┬──────────────────────┬──────────────────────────────────────┐
│ NAME        │ DESCRIPTION          │ GROUP UUID                           │
├─────────────┼──────────────────────┼──────────────────────────────────────┤
│ development │ The development team │ 4a5d8357-1fc3-44cf-8a1c-9882406df656 │
└─────────────┴──────────────────────┴──────────────────────────────────────┘
  • To edit the description of a User Group, use the following command:
# anchorectl usergroup update development --description "New development team description"
 ✔ Update usergroup                                                                                                                                                                                                      
Name: development
Description: New development team description
Group Uuid: 4a5d8357-1fc3-44cf-8a1c-9882406df656
Created At: 2024-03-20T15:57:20.086665Z
Last Updated: 2024-03-20T16:00:17.989822Z
Account Roles:
  Items: 
  • To delete a User Group, use the following command:
# anchorectl usergroup delete development
 ✔ Deleted usergroup                                                                                                                                                                                                     
No results                                                                                                                                                                                                    
  • To add an account role to a User Group, use the following command:
# anchorectl usergroup role add development dev_account --role image-analyzer,image-developer,read-only,repo-analyzer
 ✔ Added account and role(s)                                                                                                                                                                                             
┌────────────────┬───────────────────────────────────────────────────────────┐
│ ACCOUNT/DOMAIN │ ROLES                                                     │
├────────────────┼───────────────────────────────────────────────────────────┤
│ dev_account    │ image-analyzer, image-developer, read-only, repo-analyzer │
└────────────────┴───────────────────────────────────────────────────────────┘

# anchorectl usergroup role add development devops_account --role read-only                                                
 ✔ Added account and role(s)                                                                                                                                                                                             
┌────────────────┬───────────────────────────────────────────────────────────┐
│ ACCOUNT/DOMAIN │ ROLES                                                     │
├────────────────┼───────────────────────────────────────────────────────────┤
│ dev_account    │ image-analyzer, image-developer, read-only, repo-analyzer │
│ devops_account │ read-only                                                 │
└────────────────┴───────────────────────────────────────────────────────────┘
  • To list all account roles for a User Group, use the following command:
# anchorectl usergroup role list development                                                                               
 ✔ Fetched usergroups accounts and roles                                                                                                                                                                                 
┌────────────────┬───────────────────────────────────────────────────────────┐
│ ACCOUNT/DOMAIN │ ROLES                                                     │
├────────────────┼───────────────────────────────────────────────────────────┤
│ dev_account    │ image-analyzer, image-developer, read-only, repo-analyzer │
│ devops_account │ read-only                                                 │
└────────────────┴───────────────────────────────────────────────────────────┘
  • To remove account role(s) from a User Group, use the following command:
# anchorectl usergroup role delete development dev_account --role image-analyzer,image-developer 
 ✔ Deleted role                                                                                                                                                                                                          
No results
  • To add a native user to a User Group, use the following command:
# anchorectl usergroup user add development -u dev_user
 ✔ Added user(s)                                                                                                                                                                                                         
┌──────────┬─────────────────────────────┐
│ USERNAME │ ADDED TO USER GROUP ON      │
├──────────┼─────────────────────────────┤
│ dev_user │ 2024-03-20T16:30:20.092909Z │
└──────────┴─────────────────────────────┘
  • To list all members of a User Group, use the following command:
# anchorectl usergroup user list development
 ✔ Fetched users within usergroup                                                                                                                                                                                        
┌──────────┬─────────────────────────────┐
│ USERNAME │ ADDED TO USER GROUP ON      │
├──────────┼─────────────────────────────┤
│ dev_user │ 2024-03-20T16:30:20.092909Z │
└──────────┴─────────────────────────────┘
  • To remove a native user from a User Group, use the following command:
# anchorectl usergroup user delete development -u dev_user
 ✔ Deleted user(s)                                                                                                                                                                                                       
No results