| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2024-10-25 |
IBM Cloud Container Registry, context-based restrictions, CBR, access |
Registry |
{{site.data.keyword.attribute-definition-list}}
{: #registry-cbr}
Context-based restrictions give account owners and administrators the ability to define and enforce access restrictions for {{site.data.keyword.cloud}} resources based on the context of access requests. Access to {{site.data.keyword.registrylong}} resources can be controlled with context-based restrictions and identity and access management (IAM) policies. {: shortdesc}
These restrictions work with traditional IAM policies, which are based on identity, to provide another layer of protection. Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure. Because both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials. See What are context-based restrictions? for more information.
A user must have the Administrator role on the {{site.data.keyword.registryshort}} service to create, update, or delete rules. A user must also have either the Editor or Administrator role for context-based restrictions to create, update, or delete network zones. A user with the Viewer role for the context-based restrictions can add network zones to a rule. {: note}
Any {{site.data.keyword.at_full_notm}}, {{site.data.keyword.logs_full_notm}}, or audit log events generated come from the context-based restrictions, not {{site.data.keyword.registryshort}}. For more information, see Monitoring context-based restrictions.
As of 28 March 2024, the {{site.data.keyword.at_full_notm}} service is deprecated and will no longer be supported as of 30 March 2025. Customers will need to migrate to {{site.data.keyword.logs_full_notm}} before 30 March 2025. During the migration period, customers can use {{site.data.keyword.at_full_notm}} along with {{site.data.keyword.logs_full_notm}}. Activity tracking events are the same for both services. For more information about migrating from {{site.data.keyword.at_full_notm}} to {{site.data.keyword.logs_full_notm}} and running the services in parallel, see migration planning. {: deprecated}
{{site.data.keyword.registryshort}} is a service that is integrated with context-based restrictions. For more information, see Services that are integrated with context-based restrictions.
To find out how to protect your {{site.data.keyword.registryshort}} resources with context-based restrictions, see the Leveraging context-based restrictions to secure your resources tutorial.
{: #registry-cbr_overview}
You can create context-based restrictions for {{site.data.keyword.registrylong_notm}} resources or for specific APIs. With context-based restrictions, you can protect resources, see Protecting specific resources.
{: #registry-cbr_protect}
When you set up context-based restrictions, the restrictions apply to everything for the selected service in the account unless you select a subset of resources. {{site.data.keyword.registryshort}} supports the following subset of resources: resource type = namespace and resource id = YOUR_IMAGE_NAMESPACE, where YOUR_IMAGE_NAMESPACE is the namespace of your image. For more information about rules, see Creating rules.
For example, if your image is in the format uk.icr.io/<my_project>/<my_image>:latest, where <my_project> is the name of your project and <my_image> is the name of the image, the attribute types are as shown in the following table.
| Attribute type | Operator | Value |
|---|---|---|
Region |
string equals |
London |
Resource Type |
string equals |
namespace |
Resource Name |
string equals |
<my_project> |
| {: caption="Example attribute types" caption-side="bottom"} | ||
| {: #table_registry_cbr_attributes} |
The Resource Name value is a namespace, as shown by the ibmcloud cr namespace-list command.
{: #registry-cbr_limitations}
Context-based restrictions protect only the actions that are associated with the {{site.data.keyword.registrylong_notm}} API and the Vulnerability Advisor 4 for {{site.data.keyword.registrylong_notm}} API. Actions that are associated with the following platform APIs are not protected by context-based restrictions. Reference the API docs for the specific action IDs.
- Resource Instance APIs
- Resource Keys APIs
- Resource Bindings APIs
- Resource Aliases APIs
- IAM Policy APIs
- Global Search APIs
- Global Tagging Attach and Detach APIs
- Context-based Restriction Rule APIs
- Secrets Manager APIs
{: #registry-cbr_create_rules}
Define restrictions to {{site.data.keyword.registryshort}} resources by creating rules.
{: #registry-cbr_rules_ui} {: ui}
To create rules in the {{site.data.keyword.cloud_notm}} console, see Creating rules. When you are asked to select a service, select Container Registry. You can protect all resources, or specific resources, see Protecting specific resources.
The following attribute types for specific resources are available in the {{site.data.keyword.cloud_notm}} console:
RegionResource TypeResource Name
{: #registry-cbr_rules_cli} {: cli}
- To create rules from the CLI, install the context-based restrictions CLI plug-in.
- You can use the
ibmcloud cbr rule-createcommand to create rules for context-based restrictions. For more information, see Creating rules by using the CLI.
The following example creates a rule that targets the Container Registry service and allows access to your namespace my_namespace only over the private network in us-south.
ibmcloud cbr rule-create --description 'Only allow access to my_namespace over the private network' --service-name container-registry --context-attributes endpointType=private --resource-attributes resourceType=namespace,resource=my_namespace --region=us-south{: pre}
{: #registry-cbr_rules_api} {: api}
To create rules in the API, see the API docs and Creating rules by using the API.
After you create a rule, it might take up to 10 minutes to before you can update that rule due to IAM TTL response caching. {: note}
{: #registry-cbr_region_policy}
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 --region option and add geography=global into the --resource-attributes field.
The following example shows the command in us-south, where <description> is the description, <accountId> is your {{site.data.keyword.cloud_notm}} account ID, <namespace> is the namespace, and <networkZoneId> is the network zone ID:
ibmcloud cbr rule-create --description "<description>" --resource-attributes "accountId=<accountId>,serviceName=container-registry,resourceType=namespace,resource=<namespace>" --context-attributes networkZoneId=<networkZoneId> --output json --region us-south{: pre}
The following example shows the command in global, where <description> is the description, <accountId> is your {{site.data.keyword.cloud_notm}} account ID, <namespace> is the namespace, and <networkZoneId> is the network zone ID:
ibmcloud cbr rule-create --description "<description>" --resource-attributes "accountId=<accountId>,serviceName=container-registry,resourceType=namespace,resource=<namespace>,geography=global" --context-attributes networkZoneId=<networkZoneId>{: pre}