copyright | lastupdated | keywords | subcollection | content-type | account-plan | completion-time | ||
---|---|---|---|---|---|---|---|---|
|
2025-02-05 |
access, tutorial, service ID, registry, namespace, account, resources, iam |
Registry |
tutorial |
lite |
45m |
{{site.data.keyword.attribute-definition-list}}
{: #iam_access} {: toc-content-type="tutorial"} {: toc-completion-time="45m"}
Use this tutorial to find out how to grant access to your resources by configuring {{site.data.keyword.iamlong}} (IAM) for {{site.data.keyword.registrylong}}. {: shortdesc}
All accounts require IAM access policies. To set up and manage IAM access policies, see Defining IAM access policies.
For more information about how to use IAM to manage access to your resources, see Managing access to resources.
{: #iam_access_prereq}
Before you begin, you must complete the following tasks:
- Complete the instructions in Getting started with {{site.data.keyword.registrylong_notm}}.
- Ensure that you have the most recent version of the
container-registry
CLI plug-in for the {{site.data.keyword.cloud_notm}} CLI, see Updating thecontainer-registry
CLI plug-in. - Ensure that you have access to two {{site.data.keyword.cloud_notm}} accounts{: external} that you can use for this tutorial, one for User A and one for User B, each must use a unique email address. You work in your own account, User A, and invite another user, User B, to use your account. You can choose to create a second {{site.data.keyword.cloud_notm}} account, or you can work with a colleague that has an {{site.data.keyword.cloud_notm}} account.
- Ensure that you have the correct access permissions for adding and removing namespaces{: term}, see Access roles for configuring {{site.data.keyword.registrylong_notm}}.
{: #configure_registry} {: step}
Add a second user to your account and grant them the ability to configure {{site.data.keyword.registrylong_notm}}.
-
Add User B to User A's account.
-
Log in to User A's account by running the following command.
ibmcloud login
{: pre}
-
Invite User B to access User A's account by running the following command, where
<[email protected]>
is User B's email address.ibmcloud account user-invite <[email protected]>
{: pre}
-
Get User A's Account ID by running the following command.
ibmcloud target
{: pre}
Make a note of the Account ID that is in the parentheses ( ) in the Account row.
-
-
Prove that User B can target User A's account but cannot do anything with {{site.data.keyword.registrylong_notm}} yet.
-
Log in as User B and target User A's account by running the following command, where
<YourAccountID>
is User A's Account ID.ibmcloud login -c <YourAccountID>
{: pre}
-
Try to edit your registry quota to 4 GB of traffic by running the following command.
ibmcloud cr quota-set --traffic=4000
{: pre}
The command fails because User B doesn't have the correct access.
-
-
Grant User B the Manager role so that User B can configure {{site.data.keyword.registrylong_notm}}.
-
Log back in to your account as yourself, User A, by running the following command.
ibmcloud login
{: pre}
-
Create a policy that grants the Manager role to User B by running the following command.
ibmcloud iam user-policy-create <[email protected]> --service-name container-registry --roles Manager
{: pre}
-
-
Prove that User B can now change quotas in User A's account.
-
Log in as User B, targeting User A's account by running the following command.
ibmcloud login -c <YourAccountID>
{: pre}
-
Try to edit your registry quota to 4 GB of traffic by running the following command.
ibmcloud cr quota-set --traffic=4000
{: pre}
It works because User B has the correct type of access.
-
Now change the quota back by running the following command.
ibmcloud cr quota-set --traffic=5120
{: pre}
-
-
Clean up.
-
Log back in to your account as yourself, User A, by running the following command.
ibmcloud login
{: pre}
-
List the policies for User B, find the policy that you created by running the following command, and note the ID.
ibmcloud iam user-policies <[email protected]>
{: pre}
-
Delete the policy by running the following command, where
<Policy_ID>
is your Policy ID.ibmcloud iam user-policy-delete <[email protected]> <Policy_ID>
{: pre}
-
{: #access_resources} {: step}
Create some namespaces with sample images, and grant access to them. You create policies to grant different roles to each namespace, and show what effect that has.
-
Create three new namespaces in User A's account. These namespaces must be unique across the region, so choose your own namespace names, but this tutorial uses
namespace_a
,namespace_b
andnamespace_c
as examples.-
Log in as User A, by running the following command.
ibmcloud login
{: pre}
-
Create
namespace_a
by running the following command.ibmcloud cr namespace-add namespace_a
{: pre}
The namespace must be unique across all {{site.data.keyword.cloud_notm}} accounts in the same region. Namespaces must have 4 - 30 characters, and contain lowercase letters, numbers, hyphens (-), and underscores (_) only. Namespaces must start and end with a letter or number. {: requirement}
If you have a problem when you try to add a namespace, see Why can't I add a namespace? for assistance. {: tip}
-
Create
namespace_b
by running the following command.ibmcloud cr namespace-add namespace_b
{: pre}
-
Create
namespace_c
by running the following command.ibmcloud cr namespace-add namespace_c
{: pre}
-
-
Prove that User B cannot see anything.
-
Log in as User B, targeting User A's account by running the following command.
ibmcloud login -c <YourAccountID>
{: pre}
-
Try to list the namespaces as User B by running the following command.
ibmcloud cr namespaces
{: pre}
It returns an empty list because User B doesn't have access to any namespaces.
-
-
Create policies to grant User B the ability to interact with the namespaces by running the following command.
-
Log in as User A's account by running the following command.
ibmcloud login
{: pre}
-
Check that at least three namespaces are listed by running the following command.
ibmcloud cr namespaces
{: pre}
The three namespaces that you created in this tutorial (
namespace_a
,namespace_b
, andnamespace_c
) are shown. If you do not see these namespaces, repeat the instructions to create them again. -
Create a policy that grants the Reader role on
namespace_b
to User B by running the following command, where<cloud_region>
is the name of your {{site.data.keyword.cloud_notm}} region, for exampleus-south
.ibmcloud iam user-policy-create <[email protected]> --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_b --roles Reader
{: pre}
To see the names of the {{site.data.keyword.cloud_notm}} regions, run the
ibmcloud regions
command. {: tip} -
Create a second policy that grants the Reader and Writer roles on
namespace_c
to User B by running the following command.ibmcloud iam user-policy-create <[email protected]> --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_c --roles Reader,Writer
{: pre}
This command adds two roles to the same resource in the same policy. {: note}
-
-
Push images into
namespace_a
andnamespace_b
.-
Pull the
hello-world
image by running the following command.docker pull hello-world
{: pre}
-
Tag the image to
namespace_a
by running the following command, where<registry_region>
is the name of your {{site.data.keyword.registrylong_notm}} region, for exampleus-south
.docker tag hello-world <registry_region>.icr.io/namespace_a/hello-world
{: pre}
-
Tag the image to
namespace_b
by running the following command.docker tag hello-world <registry_region>.icr.io/namespace_b/hello-world
{: pre}
-
Log in to {{site.data.keyword.registrylong_notm}} by running the
ibmcloud cr login
command.ibmcloud cr login
{: pre}
{{site.data.keyword.registrylong_notm}} supports Docker and other clients. To log in by using other clients, see Accessing your namespaces interactively. {: tip}
If you have a problem when you try to log in, see Why can't I log in to {{site.data.keyword.registryshort_notm}}? for assistance. {: tip}
-
Push the image to
namespace_a
by running the following command.docker push <registry_region>.icr.io/namespace_a/hello-world
{: pre}
-
Push the image to
namespace_b
by running the following command.docker push <registry_region>.icr.io/namespace_b/hello-world
{: pre}
-
-
Prove that User B can interact with
namespace_b
andnamespace_c
, but notnamespace_a
.-
Log in as User B by running the following command.
ibmcloud login -c <YourAccountID>
{: pre}
-
Show that User B can see
namespace_b
andnamespace_c
, but notnamespace_a
because User B doesn't have access tonamespace_a
, by running the following command.ibmcloud cr namespaces
{: pre}
-
List your images by running the following command.
ibmcloud cr images
{: pre}
The image in
namespace_b
is shown in the list, but the image innamespace_a
doesn't, because User B doesn't have access tonamespace_a
. -
Log in to {{site.data.keyword.registrylong_notm}} by running the following command.
ibmcloud cr login
{: pre}
{{site.data.keyword.registrylong_notm}} supports Docker and other clients. To log in by using other clients, see Accessing your namespaces interactively. {: tip}
-
Pull the image by running the following command.
docker pull <registry_region>.icr.io/namespace_b/hello-world
{: pre}
-
Push the image to
namespace_b
by running the following command.docker push <registry_region>.icr.io/namespace_b/hello-world
{: pre}
This command fails because User B doesn't have the Writer role in
namespace_b
. -
Tag the image with
namespace_c
by running the following command.docker tag hello-world <registry_region>.icr.io/namespace_c/hello-world
{: pre}
-
Push the image to
namespace_c
by running the following command.docker push <registry_region>.icr.io/namespace_c/hello-world
{: pre}
The command works because User B has the Writer role in
namespace_c
. -
Pull from
namespace_c
by running the following command.docker pull <registry_region>.icr.io/namespace_c/hello-world
{: pre}
The command works because User B has the Reader role in
namespace_c
.
-
-
Clean up:
-
Log back in to User A's account by running the following command.
ibmcloud login
{: pre}
-
List the policies for User B by running the following command.
ibmcloud iam user-policies <[email protected]>
{: pre}
Find the policies that you created and note the Policy IDs.
-
Delete the policies that you created by running the following command, where
<Policy_ID>
is the Policy ID.ibmcloud iam user-policy-delete <[email protected]> <Policy_ID>
{: pre}
-
{: #service_id} {: step}
Configure a service ID and grant it access to your {{site.data.keyword.registrylong_notm}} namespace.
-
Set up a service ID with access to {{site.data.keyword.registrylong_notm}} and create an API key{: term} for it.
-
Log in to User A's account by running the following command.
ibmcloud login
{: pre}
-
Create a service ID named
cr-roles-tutorial
with the description"Created during the access control tutorial for Container Registry"
by running the following command.ibmcloud iam service-id-create cr-roles-tutorial --description "Created during the access control tutorial for Container Registry"
{: pre}
-
Create a service policy for the service ID that grants the Reader role on
namespace_a
by running the following command.ibmcloud iam service-policy-create cr-roles-tutorial --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_a --roles Reader
{: pre}
-
Create a second service policy that grants the Writer role on
namespace_b
by running the following command.ibmcloud iam service-policy-create cr-roles-tutorial --service-name container-registry --region <cloud_region> --resource-type namespace --resource namespace_b --roles Writer
{: pre}
-
Create an API key for the service ID by running the following command.
ibmcloud iam service-api-key-create cr-roles-tutorial-apikey cr-roles-tutorial
{: pre}
-
-
Use Docker to log in with the service ID API key, where
<API_Key>
is your API key, and interact with the registry.-
Log in to {{site.data.keyword.registrylong_notm}} by running the following command.
docker login -u iamapikey -p <API_Key> <registry_region>.icr.io
{: pre}
{{site.data.keyword.registrylong_notm}} supports Docker and other clients. To log in by using other clients, see Accessing your namespaces in automation. {: tip}
-
Pull your image by running the following command.
docker pull <registry_region>.icr.io/namespace_a/hello-world
{: pre}
-
Push your image to
namespace_a
by running the following command.docker push <registry_region>.icr.io/namespace_a/hello-world
{: pre}
This command doesn't work because the user doesn't have the Writer role in
namespace_a
. -
Push your image to
namespace_b
by running the following command.docker push <registry_region>.icr.io/namespace_b/hello-world
{: pre}
This command works because the user has the Writer role in
namespace_b
.
-
-
Clean up:
-
Log back in to {{site.data.keyword.registrylong_notm}} as User A.
ibmcloud cr login
{: pre}
{{site.data.keyword.registrylong_notm}} supports Docker and other clients. To log in by using other clients, see Accessing your namespaces interactively. {: tip}
-
List your service policies by running the following command.
ibmcloud iam service-policies cr-roles-tutorial
{: pre}
Note your Policy IDs.
-
Delete your service policies by running the following command for each policy.
ibmcloud iam service-policy-delete cr-roles-tutorial <Policy_ID>
{: pre}
-
Delete your service ID by running the following command.
ibmcloud iam service-id-delete cr-roles-tutorial
{: pre}
-
{: #clean_up} {: step}
Remove the resources that you created in previous sections to leave your account as it was at the start of this tutorial.
-
Log in to User A's account by running the following command.
ibmcloud login
{: pre}
-
Delete
namespace_a
,namespace_b
, andnamespace_c
by running the following commands.ibmcloud cr namespace-rm namespace_a
{: pre}
ibmcloud cr namespace-rm namespace_b
{: pre}
ibmcloud cr namespace-rm namespace_c
{: pre}
-
Remove User B from your account by running the following command.
ibmcloud account user-remove <[email protected]>
{: pre}