Managing IAM access for Container Registry
Access to IBM Cloud® Container Registry for users in your account is controlled by IBM Cloud® Identity and Access Management (IAM).
Every user that accesses the IBM Cloud Container Registry service in your account must be assigned an IAM access policyA method for granting users, service IDs, and access groups access to account resources. An access policy includes a subject, target, and role. with an IAM role. A user can also be a member of an access group with assigned IAM access policies that grant an IAM role. Review the following roles, actions, and more to help determine the best way to assign access to Container Registry.
For more information about IAM, see How IBM Cloud Identity and Access Management works.
Try out the tutorial Granting access to Container Registry resources tutorial.
Access policies
The IAM access policy that you assign to users in your account determines the actions that a user can perform within the context of the service or specific instance that you select. The allowable actions are customized and defined by Container Registry as operations that are allowed to be performed on the service. Each action is mapped to an IAM platform or service role that you can assign to a user.
Policies enable access to be granted at different levels. Some options include the following access levels:
- Access to the service in your account
- Access to a specific resource within the service
- Access to all IAM-enabled services in your account
- Access to resources within a resource group
If you want to restrict user access to one or more namespacesA collection of repositories that store images in a registry. A namespace is associated with an IBM Cloud account, which can include multiple namespaces. for an ID that you're using for automation, use an IAM service ID. For more information about service IDs, see Creating and working with service IDs.
You can set permissions so that you can configure access to resources within a namespace at the resource groupThe environment, and constraints, in which contained resource instances adhere to. A user can be associated with a resource group to enable collaboration. level. For more information, see User permissions for working with namespaces.
For more information about enabling policies for Container Registry, see Defining IAM access policies.
Assign roles
After you define the scope of the IAM access policy, you assign a role.
If a specific role and its actions don't fit the use case that you're looking to address, you can create a custom role and pick the actions to include.
Review the following tables that outline the actions that each role allows within the Container Registry service.
-
Platform management roles enable users to perform tasks on service resources at the platform level, for example, assign user access to the service, create or delete instances, and bind instances to applications.
-
Service access roles enable users access to Container Registry and the ability to call the Container Registry API.
For more information about the exact actions that are mapped to each role, see IAM roles and actions for Container Registry.
For more information about assigning user roles in the UI, see Managing access to resources.
Context-based restrictions
Container Registry also supports context-based restrictions. You can use context-based restrictions to define and enforce access restrictions for IBM Cloud resources based on the network location of access requests. These restrictions work with traditional IAM policies, which are based on identity, to provide another layer of protection.
For more information, see Protecting Container Registry resources with context-based restrictions.
Platform management roles
The following table details actions that are mapped to platform management roles. Platform management roles enable users to perform tasks on service resources at the platform level, for example assign user access for the service, and create or delete service IDs.
Platform management roles | Description of actions | Example actions |
---|---|---|
Viewer | Not supported | Not applicable |
Editor | Not supported | Not applicable |
Operator | Not supported | Not applicable |
Administrator | Configure access for other users.
Apply pull secrets to clusters. |
For more information about assigning user roles in the UI, see Managing access to resources.
To create clusters in IBM Cloud Kubernetes Service that have pull secrets to access images in Container Registry, you must have the Administrator role. To use the |
Service access roles
The following table details actions that are mapped to service access roles. Service access roles give users access to Container Registry as well as the ability to call the Container Registry API.
Service access role | Description of actions | Example actions |
---|---|---|
Reader | The Reader role can view information. | View, inspect, and pull images.
View and analyze namespaces. View quotas. View vulnerability reports. View image signatures. View retention policies. View the contents of the trash. View the contents of the manifest for an image. List Vulnerability Advisor security exemption policies and types of security exemptions. |
Writer | The Writer role can edit information. | Push, delete, and restore images.
View quotas. Sign images. Set and run retention policies. Delete all untagged images in your Container Registry account. |
Manager | The Manager role can perform all actions. | View, inspect, pull, push, delete, and restore images.
View, add, analyze, and remove namespaces. Assign namespaces to resource groups. View and set quotas. View vulnerability reports. View and create image signatures. Review and change pricing plans. Enable IAM access policy enforcement. List, add, and remove Vulnerability Advisor security issue exemption policies. List types of security exemptions. Set and run retention policies. View the contents of the trash. Restore images. View the contents of the manifest for an image. Prevent or allow image pulls or pushes over public network connections for your account. Check whether the use of public connections is prevented for image pushes or pulls in your account. Delete all untagged images in your Container Registry account. |
For the following Container Registry commands, you must have at least one of the specified roles as shown in the following tables. To create a policy that allows access to Container Registry, you must create a policy where the following criteria apply.
- The service name is
container-registry
. - The service instance is empty.
- The region is the region that you want to grant access to, or is empty to give access to all regions.
Access roles for configuring Container Registry
To grant a user permission to configure Container Registry in your account, you must create a policy that grants one or more of the roles in the following table. When you create your policy, you must not specify a resource type
or resource
. Policies for configuring Container Registry must not be set at a resource group level.
For example, run the following ibmcloud iam user-policy-create
command. Where <user_email>
is the user's email address, <region>
is the region, and <roles>
is the role,
or roles, that you want the user to have.
ibmcloud iam user-policy-create <user_email> --service-name container-registry --region <region> --roles <roles>
The following table details actions that are mapped to operations on the service and to the service access roles for configuring Container Registry.
Action | Operation on service | Role |
---|---|---|
container-registry.auth.get |
ibmcloud cr private-only Check whether the use of public connections is prevented for image pushes or pulls in your account. |
Manager |
container-registry.auth.set |
ibmcloud cr iam-policies-enable Enable IAM access policy enforcement.
|
Manager |
container-registry.exemption.list |
ibmcloud cr exemption-list List your Vulnerability Advisor exemption policies for security issues.
|
Reader, Manager |
container-registry.exemption.manager |
ibmcloud cr exemption-add Create a Vulnerability Advisor exemption policy for a security issue.
|
Manager |
container-registry.namespace.create |
ibmcloud cr namespace-add Create a namespace.
|
Manager |
container-registry.namespace.delete |
ibmcloud cr namespace-rm Remove a namespace. |
Manager |
container-registry.plan.get |
ibmcloud cr plan Display your pricing plan. |
Manager |
container-registry.plan.set |
ibmcloud cr plan-upgrade Upgrade to the standard plan. |
Manager |
container-registry.quota.get |
ibmcloud cr quota Display your current quotas for traffic and storage, and usage information against those quotas. |
Reader, Writer, Manager |
container-registry.quota.set |
ibmcloud cr quota-set Modify the specified quota. |
Manager |
container-registry.settings.get |
ibmcloud cr platform-metrics Get registry service settings for the targeted account, such as whether platform metrics are enabled. |
Reader, Writer, Manager |
container-registry.settings.set |
ibmcloud cr platform-metrics Update registry service settings for the targeted account, such as enabling platform metrics. |
Manager |
Access roles for using Container Registry
To grant a user permission to access Container Registry content in your account, you must create a policy that grants one or more of the roles in the following table. When you create your policy, you can restrict access to a specific namespace
by specifying the resource type namespace
and the namespace name as the resource. If you don't specify a resource-type
and a resource
, the policy grants access to all resources in the account. Alternatively,
if your namespace is within a resource group, permission can be granted by using an IAM access policy on that resource group.
For example, use the following command to create a user policy. Where <user_email>
is the user's email address, <region>
is the region, <roles>
is the role, or roles, that you want the
user to have, and <namespace_name>
is the name of the namespace.
ibmcloud iam user-policy-create <user_email> --service-name container-registry --region <region> --roles <roles> [--resource-type namespace --resource <namespace_name>]
The following table details actions that are mapped to operations on the service and to the service access roles for using Container Registry.
Action | Operation on service | Role |
---|---|---|
container-registry.image.delete |
docker trust revoke Delete the signature for a container image.
|
Writer, Manager
To run |
container-registry.image.inspect |
ibmcloud cr image-inspect Display details about a specific container image.
|
Reader, Manager |
container-registry.image.list |
ibmcloud cr image-digests List all your container images, including untagged images.
|
Reader, Manager |
container-registry.image.pull |
docker pull Pull a container image.
|
Reader, Writer, Manager |
container-registry.image.push |
docker push Push a container image.
|
Writer, Manager |
container-registry.namespace.list |
ibmcloud cr namespace-list List your namespaces. |
Reader, Manager |
container-registry.retention.analyze |
ibmcloud cr retention-policy-set Set a policy to clean up your namespaces by retaining only container images that meet your criteria.
|
Reader, Manager
To run |
container-registry.retention.get |
View the image retention policy for a namespace by using the API, see IBM Cloud Container Registry API. | Reader, Manager |
container-registry.retention.set |
ibmcloud cr retention-policy-set Set a policy to clean up your namespaces by retaining only container images that meet your criteria. |
Writer, Manager |
container-registry.retention.list |
ibmcloud cr retention-policy-list List the image retention policies for your account. |
Reader, Manager |
Assigning access to Container Registry in the console
You can use one of the following options to assign access in the console:
- Access policies per user. You can manage access policies per user from the Manage > Access (IAM) > Users page in the console. For more information about the steps to assign IAM access, see Managing access to resources.
- Access groups. Access groups are used to streamline access management by assigning access to a group once, then you can add or remove users as required from the group to control their access. You manage access groups and their access from the Manage > Access (IAM) > Access groups page in the console. For more information, see Assigning access to a group in the console.
Assigning access to Container Registry in the CLI
For step-by-step instructions for assigning, removing, and reviewing access, see Assigning access to resources by using the CLI. The following
example shows a command for assigning the Manager
role for Container Registry:
Use container-registry
for the service name.
ibmcloud iam user-policy-create <user@example.com> --service-name container-registry --roles Manager
Assigning access to Container Registry by using the API
For step-by-step instructions for assigning, removing, and reviewing access, see Assigning access to resources by using the API or Create a policy in the API docs. Role cloud resource names (CRN) in the following table are used to assign access with the API.
Role name | Role CRN |
---|---|
Administrator | crn:v1:bluemix:public:container-registry::::serviceRole:Administrator |
Reader | crn:v1:bluemix:public:container-registry::::serviceRole:Reader |
Writer | crn:v1:bluemix:public:container-registry::::serviceRole:Writer |
Manager | crn:v1:bluemix:public:container-registry::::serviceRole:Manager |
The following example is for assigning the Manager
role for Container Registry:
Use container-registry
for the service name, and refer to the Role ID values table to ensure that you're using the correct value for the CRN.
curl -X POST 'https://iam.cloud.ibm.com/v1/policies' -H 'Authorization: Bearer $TOKEN' -H 'Content-Type: application/json' -d '{
"type": "access",
"description": "Manager role for Container Registry",
"subjects": [
{
"attributes": [
{
"name": "iam_id",
"value": "IBMid-123453user"
}
]
}'
],
"roles":[
{
"role_id": "crn:v1:bluemix:public:container-registry::::serviceRole:Manager"
}
],
"resources":[
{
"attributes": [
{
"name": "accountId",
"value": "$ACCOUNT_ID"
},
{
"name": "serviceName",
"value": "container-registry"
}
]
}
]
}
SubjectAttribute subjectAttribute = new SubjectAttribute.Builder()
.name("iam_id")
.value("IBMid-123453user")
.build();
PolicySubject policySubjects = new PolicySubject.Builder()
.addAttributes(subjectAttribute)
.build();
PolicyRole policyRoles = new PolicyRole.Builder()
.roleId("crn:v1:bluemix:public:container-registry::::serviceRole:Manager")
.build();
ResourceAttribute accountIdResourceAttribute = new ResourceAttribute.Builder()
.name("accountId")
.value("ACCOUNT_ID")
.operator("stringEquals")
.build();
ResourceAttribute serviceNameResourceAttribute = new ResourceAttribute.Builder()
.name("serviceName")
.value("container-registry")
.operator("stringEquals")
.build();
PolicyResource policyResources = new PolicyResource.Builder()
.addAttributes(accountIdResourceAttribute)
.addAttributes(serviceNameResourceAttribute)
.build();
CreatePolicyOptions options = new CreatePolicyOptions.Builder()
.type("access")
.subjects(Arrays.asList(policySubjects))
.roles(Arrays.asList(policyRoles))
.resources(Arrays.asList(policyResources))
.build();
Response<Policy> response = service.createPolicy(options).execute();
Policy policy = response.getResult();
System.out.println(policy);
const policySubjects = [
{
attributes: [
{
name: 'iam_id',
value: 'IBMid-123453user',
},
],
},
];
const policyRoles = [
{
role_id: 'crn:v1:bluemix:public:container-registry::::serviceRole:Manager',
},
];
const accountIdResourceAttribute = {
name: 'accountId',
value: 'ACCOUNT_ID',
operator: 'stringEquals',
};
const serviceNameResourceAttribute = {
name: 'serviceName',
value: 'container-registry',
operator: 'stringEquals',
};
const policyResources = [
{
attributes: [accountIdResourceAttribute, serviceNameResourceAttribute]
},
];
const params = {
type: 'access',
subjects: policySubjects,
roles: policyRoles,
resources: policyResources,
};
iamPolicyManagementService.createPolicy(params)
.then(res => {
examplePolicyId = res.result.id;
console.log(JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});
policy_subjects = PolicySubject(
attributes=[SubjectAttribute(name='iam_id', value='IBMid-123453user')])
policy_roles = PolicyRole(
role_id='crn:v1:bluemix:public:container-registry::::serviceRole:Manager')
account_id_resource_attribute = ResourceAttribute(
name='accountId', value='ACCOUNT_ID')
service_name_resource_attribute = ResourceAttribute(
name='serviceName', value='container-registry')
policy_resources = PolicyResource(
attributes=[account_id_resource_attribute,
service_name_resource_attribute])
policy = iam_policy_management_service.create_policy(
type='access',
subjects=[policy_subjects],
roles=[policy_roles],
resources=[policy_resources]
).get_result()
print(json.dumps(policy, indent=2))
subjectAttribute := &iampolicymanagementv1.SubjectAttribute{
Name: core.StringPtr("iam_id"),
Value: core.StringPtr("IBMid-123453user"),
}
policySubjects := &iampolicymanagementv1.PolicySubject{
Attributes: []iampolicymanagementv1.SubjectAttribute{*subjectAttribute},
}
policyRoles := &iampolicymanagementv1.PolicyRole{
RoleID: core.StringPtr("crn:v1:bluemix:public:container-registry::::serviceRole:Manager"),
}
accountIDResourceAttribute := &iampolicymanagementv1.ResourceAttribute{
Name: core.StringPtr("accountId"),
Value: core.StringPtr("ACCOUNT_ID"),
Operator: core.StringPtr("stringEquals"),
}
serviceNameResourceAttribute := &iampolicymanagementv1.ResourceAttribute{
Name: core.StringPtr("serviceName"),
Value: core.StringPtr("container-registry"),
Operator: core.StringPtr("stringEquals"),
}
policyResources := &iampolicymanagementv1.PolicyResource{
Attributes: []iampolicymanagementv1.ResourceAttribute{
*accountIDResourceAttribute, *serviceNameResourceAttribute}
}
options := iamPolicyManagementService.NewCreatePolicyOptions(
"access",
[]iampolicymanagementv1.PolicySubject{*policySubjects},
[]iampolicymanagementv1.PolicyRole{*policyRoles},
[]iampolicymanagementv1.PolicyResource{*policyResources},
)
policy, response, err := iamPolicyManagementService.CreatePolicy(options)
if err != nil {
panic(err)
}
b, _ := json.MarshalIndent(policy, "", " ")
fmt.Println(string(b))
Assigning access to Container Registry by using Terraform
The following example is for assigning the Manager
role for Container Registry:
Use container-registry
for the service name.
resource "ibm_iam_user_policy" "policy" {
ibm_id = "test@example.com"
roles = ["Manager"]
resources {
service = "container-registry"
}
}
For more information, see ibm_iam_user_policy in the Terraform documentation.