IBM Cloud Docs
Defining IAM access policies for Container Registry

Defining IAM access policies for Container Registry

As an administrator, you can define IBM Cloud® Identity and Access Management (IAM) access policies to create different levels of access for different users in IBM Cloud® Container Registry. For example, you can authorize some users to view quotas and other users to set quotas.

You must define IAM access policiesA method for granting users, service IDs, and access groups access to account resources. An access policy includes a subject, target, and role. for every user that works with IBM Cloud Container Registry. The scope of an IAM access policy is based on the user's role or roles that determine the actions that they are allowed to do. Some roles are predefined, but custom roles can be defined.

To find out more about IAM access policies, see IBM Cloud IAM roles.

You can assign Container Registry namespaces to a resource group and scope access policies to that group, see Planning namespaces. However, you can still define access policies that are scoped to individual Container Registry namespaces or to all namespaces that are owned by the account.

Creating policies

Before you begin, complete the following tasks:

  • Decide on the roles that each user needs and on which resources in IBM Cloud Container Registry, see IAM roles. You can create multiple policies, for example, you can grant write access on a resource but grant read access only on another resource. Policies are additive, which means that a global read policy and a resource-scoped write policy grants both read and write access on that resource.

  • Invite users to an account.

    If you want users to create clusters in IBM Cloud Kubernetes Service, ensure that you assign the IBM Cloud Container Registry Administrator role to those users, and don't assign a resource group. For more information, see Preparing your account to create clusters.

To create policies for IBM Cloud Container Registry, the service name field must be container-registry.

If you want to access resources, you must assign roles to users or service IDs. If you want to grant access to everything, don't specify a resource type or a resource. If you want to grant access to a specific namespace, specify the resource type as namespace and use the namespace name as the resource.

For an example of useful access policies for IBM Cloud Container Registry, see Granting access to Container Registry resources tutorial.

Setting up region-based policies for IAM

For all regions other than global you can use the region field when you create a rule. So for example, in the CLI for us-south you use the --region us-south option. However, because global is a geography and not a region you must omit the --regionoption and add geography=global into the --attributes field.

Region-based user policies

The following example shows the command for creating a user policy to assign a role to a user in us-south, where <name@example.com> is the user ID and <roles> is the role or roles that you want to allocate:

ibmcloud iam user-policy-create <name@example.com> --roles <roles> --service-name container-registry --region us-south

The following example shows the command for creating a user policy to assign a role to a user in global, where <name@example.com> is the user ID and <roles> is the role or roles that you want to allocate:

ibmcloud iam user-policy-create <name@example.com> --roles <roles> --service-name container-registry --attributes "geography=global"

Region-based service ID policies

The following example shows the command for creating a service ID policy in us-south, where <serviceId> is the service ID and <roles> is the role or roles that you want to allocate:

ibmcloud iam service-policy-create <serviceId> --roles <roles> --service-name container-registry --region us-south

The following example shows the command for creating a service ID policy in global, where <serviceId> is the service ID and <roles> is the role or roles that you want to allocate:

ibmcloud iam service-policy-create <serviceId> --roles <roles> --service-name container-registry --attributes "geography=global"