IBM Cloud Docs
What are context-based restrictions?

What are context-based restrictions?

Context-based restrictions give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on a rule's criteria. The criteria include the network location of access requests, the endpoint type from where the request is sent, the multifactor authentication level of an identity, and sometimes the API that the request tries to access. These restrictions work with traditional IAM policies, which are based on identity, to provide another layer of protection. Since both IAM policies and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials.

A diagram that shows how context-based restrictions work.
Figure 1. A diagram that shows how context-based restrictions work.

For an example scenario on creating context-based restrictions, follow the tutorial for Leveraging context-based restrictions to secure your resources.

For more information about implementing context-based restrictions in your security strategy, see the solution tutorial Enhance cloud security by applying context-based restrictions.

Rules

A rule associates an IBM Cloud resource with a set of contexts:

  • The cloud resource is specified by resource attributes similar to IAM access policies.
  • A context is a combination of network zones and endpoint types.

The contexts that you configure define the boundary for the associated resources.

The necessary resource attributes in context-based restrictions rules are accountId and serviceName. Rules must be scoped to an account and a specific service.

Context-based restriction rules are applied by the following logic:

  • Access is granted by a rule only when at least one of the rule's contexts allows access.
  • If multiple rules are applicable to a particular resource, access is granted only when all applicable rules allow access.
  • If no rules are applicable to a particular resource, access is determined exclusively by IAM policies.

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.

The interface that you use to access a resource, such as the console, CLI, or API, doesn't affect how a rule applies to that resource. The rule applies the same way across all interfaces and is based on the client IP address.

Rule enforcement

You can decide how you want to enforce a rule upon creation and update the rule enforcement at any time.

Enabled
Enforce the rule. Depending on the service that you select, monitoring denied access attempts through Activity Tracker might be available. Review each service's documentation to learn about how they integrate with context-based restrictions.
Disabled
No restrictions apply to your account resources. Select this option if you're not ready to enable the rule.
Report-only
Depending on the service that you select, you can monitor how a rule affects access without enforcing it. With report-only mode, all attempts to access resources in the account are logged in Activity Tracker. If available, monitoring is recommended for 30 days before you enforce a rule.

Report-only mode is not available for all services, so review each service's documentation to learn about how they integrate with context-based restrictions.

You can monitor the impact of your enabled and report-only rules. For more information, see Monitoring context-based restrictions.

Defining the scope of a rule

Define the APIs that you want to protect to narrow the scope of a rule's restrictions. This way, you can specify granular protections for different APIs that have distinct access requirements.

For example, you might create a rule that targets a data plane API so that it is only accessible from a Kubernetes cluster, or wherever your compute infrastructure exists. Then, you can create a rule that targets your control plane API and all platform APIs to protect interactions with the cloud console so that it is only accessible from behind your organization's VPN.

Only some services support the ability to scope a rule by API.

With some services, you can restrict the actions of all service APIs on your resources by default, which includes all current and future APIs that the service might support. Or, select specific APIs. For example, Kubernetes has custom service APIs that you can restrict access to based on the context of the request. Review each service's documentation to learn more about how they integrate with context-based restrictions.

Select services support the ability to scope a rule to protect all platform APIs, which include all current and future platform APIs that a service might support. The addition of platform APIs to the scope of a rule ensures that platform operations like resource provisioning, service credential management, and attaching tags are only accessible from locations that you define.

Context-based restrictions default to protect all of the service and platform APIs the target service supports.

Contexts

Contexts define where your resource can be accessed. A context is made up of the allowed endpoint types and network zones that you configure.

  • If a context includes network zones, then access is granted only when the request is created from within one of those zones.
  • If a context includes service endpoint types, then access is granted only when the request is received over a connection that matches one of those types.
  • If a context includes multifactor authentication (MFA), then access is granted only when the requesting identity has an MFA level equal to or exceeding the required MFA level.
  • If a context includes multiple restrictions, for example, both zones and endpoint types, then all restrictions must be satisfied for access to be granted.

Network zone

A network zone represents an allowlist of IP addresses where an access request is created. It defines a set of one or more network locations that are specified by the following attributes:

  • IP addresses, which include individual addresses, ranges, or subnets.
  • VPCs
  • Service references, which allow access from other IBM Cloud® services.

IP addresses

Customers can specify the IP addresses they know that they want to be able to send traffic from. Anything outside of the specified IP addresses is denied.

VPCs

If you have apps that are deployed in a VPC that need access to a context-based restricted resource, you can include the VPC IP addresses in your network zone. To do so, select the target VPC in your network zone and add that network zone to your rule. This way, you don’t have to find the IP addresses that the VPC uses. Resources that are contacted see that the request is coming from a set of allowed IP addresses.

Service references

A service reference represents the network locations of a service or service instance. Including a service reference in a network zone adds the IP addresses associated with the service to your allowlist without requiring you to know the service's underlying IP addresses. Service references are helpful since the network locations of cloud services are unknown to the context-based restriction administrator and can change over time.

The following is a list of services that you can add to a network zone as a service reference:

Table 1. Services that are compatible with service references.
Service Service type service_name
All Account Management services Account Management iam-access-management
IAM Access Groups Service Account Management iam-groups
IAM User Management Account Management user-management
Activity Tracker IAM-enabled logdnaat
App Configuration IAM-enabled apprapp
Catalog Management Service IAM-enabled globalcatalog-collection
Cloud Block Storage for VPC IAM-enabled
Cloud Object Storage IAM-enabled cloud-object-storage
Code Engine IAM-enabled codeengine
Databases for DataStax IAM-enabled databases-for-cassandra
Databases for EnterpriseDB IAM-enabled databases-for-enterprisedb
Databases for Elasticsearch IAM-enabled databases-for-elasticsearch
Databases for etcd IAM-enabled databases-for-etcd
Databases for MongoDB IAM-enabled databases-for-mongodb
Databases for MySQL IAM-enabled databases-for-mysql
Databases for PostgreSQL IAM-enabled databases-for-postgresql
Databases for Redis IAM-enabled databases-for-redis
Direct Link IAM-enabled directlink
Log Analysis IAM-enabled logdna
Event Notifications IAM-enabled event-notifications
Event Streams IAM-enabled messagehub
Kubernetes Service / Red Hat OpenShift IAM-enabled containers-kubernetes
Messages for RabbitMQ IAM-enabled messages-for-rabbitmq
Secrets Manager IAM-enabled secrets-manager
VPC Infrastructure Services IAM-enabled
Schematics IAM-enabled schematics
Toolchain IAM-enabled toolchain

In table 1, All Account Management services refers to the grouping of Account Management type services that are listed in the table. For example, if there are two Account Management services listed in table 1, All Account Management services includes those two services. As more Account Management services become available as service references, network zones that specify All Account Management services as a service reference automatically include the newly added account management services.

Refer to each service offering's documentation for more information about which services to add as a service reference for the service offering that you target in a rule.

Endpoint types

An endpoint type represents the connection over which an access request is received. It corresponds to the endpoint that receives the connection. You can allow access from all endpoint types that are supported by the service or specific service endpoint types.

The three common endpoint types are as follows:

  • Public endpoints can accept requests from anywhere.
  • Private endpoints are available for most requests, that originate from within IBM Cloud®.
  • Direct endpoints are used in Bring-Your-Own-IP scenarios, generally for requests, that originate from resources within VPCs.

Some endpoint types might not be supported by the selected service.

Multifactor authentication

Multifactor authentication (MFA) requires identities to authenticate by using another authentication factor beyond an ID and password. By setting a lower MFA level requirement, you’re allowing users who meet or exceed that requirement to authenticate. For example, if your rule requires users to authenticate with MFA Level 1, users that have MFA Level 2 are still compliant since Level 2 exceeds the security criteria for Level 1. The MFA levels below name the minimum MFA factor for each level. For more information, see IBM Cloud multifactor authentication.

  • Level 1: Email-based MFA
  • Level 2: TOTP MFA
  • Level 3: U2F MFA

Only some services support the ability to specify MFA in a rule.

Access requirements

To complete rule actions, you must be assigned an IAM policy on the target service. To complete network zone actions, you must be assigned an IAM policy on the context-based restrictions service.

To create a context-based restriction for a service, you must be assigned an IAM policy with the Administrator role the service you are creating a rule against. For example, if you want to create a rule to protect a Key Protect instance, you must be assigned the Administrator role on the Key Protect service and the Viewer role or higher on the Context-based restrictions** service.

The Viewer role on the Context-based restrictions service authorizes you to add network zones to your rule.

Context-based restrictions roles and actions

To manage network zones, you must be assigned an IAM policy with a specific role for the Context-based restrictions account management service. The following table shows the possible access roles and actions for account management.

Table 2. Roles and actions for the Context-based restrictions service
Roles Actions
Viewer View network zones
Editor View network zones

Create network zones

Update network zones

Remove network zones

Administrator View network zones

Create network zones

Update network zones

Remove network zones

For more information, see Actions and roles for account management services.

You can also use network zones to restrict access at the account level. To set account-level restrictions by using network zones, go to Manage > IAM > Settings in the IBM Cloud console and enter the name of your network zone.

Target service roles and actions

To manage rules, you must be assigned an IAM policy with the Administrator role for the service that you are creating the rule against. The following table shows the possible access roles and actions for services.

Table 3. Roles and example actions for target service
Roles Actions
Viewer View rules
Editor View rules
Administrator View rules

Create rules

Update rules

Remove rules

Services integrated with context-based restrictions

Specific IBM Cloud services are integrated with context-based restrictions, and only these services can apply rules to their resources. The way that rules apply to individual services is determined by the service, so be sure to review the documentation for each service to understand how context-based restrictions apply.

You can create context-based restrictions for the following services if you are granted the correct access on the service:

Table 4. Services that are compatible with context-based restrictions.
Service Service type Scope to APIs service_name
Catalog Management Service IAM-enabled Yes globalcatalog-collection
Context-based restrictions Service Account Management No context-based-restrictions
IAM Access Groups Service Account Management No iam-groups
IAM Access Management Service Account Management No iam-access-management
IAM Identity Service Account Management No iam-identity
IAM User Management Account Management No user-management
Activity Tracker IAM-enabled Yes logdnaat
App Configuration IAM-enabled No apprapp
Cloud Object Storage IAM-enabled No cloud-object-storage
Code Engine IAM-enabled No codeengine
Container Registry IAM-enabled No container-registry
Databases for DataStax IAM-enabled Yes databases-for-cassandra
Databases for EnterpriseDB IAM-enabled Yes databases-for-enterprisedb
Databases for Elasticsearch IAM-enabled Yes databases-for-elasticsearch
Databases for etcd IAM-enabled Yes databases-for-etcd
Databases for MongoDB IAM-enabled Yes databases-for-mongodb
Databases for MySQL IAM-enabled Yes databases-for-mysql
Databases for PostgreSQL IAM-enabled Yes databases-for-postgresql
Databases for Redis IAM-enabled Yes databases-for-redis
Direct Link IAM-enabled No directlink
DNS Services IAM-enabled No dns-svcs
Event Notifications IAM-enabled No event-notifications
Log Analysis IAM-enabled Yes logdna
Event Streams IAM-enabled No messagehub
Key Protect IAM-enabled No kms
Kubernetes Service / Red Hat OpenShift IAM-enabled Yes containers-kubernetes
Messages for RabbitMQ IAM-enabled Yes messages-for-rabbitmq
Secrets Manager IAM-enabled No secrets-manager
Security and Compliance Center IAM-enabled No compliance
Transit Gateway IAM-enabled No transit
IBM Cloud® Virtual Private Cloud IAM-enabled No is
Schematics IAM-enabled No schematics

Context-based restrictions that are defined for IAM-enabled services do not apply to platform actions like create or delete. For more information, see IAM roles and actions.

Check back regularly to see what services are added as more services integrate with context-based restrictions.

Context-based restrictions limits

The following table lists the maximum limits for context-based restrictions. These limits apply to any user who can create context-based restrictions rules or network zones. For more information, see What are context-based restrictions?.

If you have a specific use case that requires an extended limit, you can request an increase. For more information, see Increasing account limits.

Table 5. Context-based restrictions limits
Resource Max
Context-based restriction rules per account [1] 4020
Network zones per account 500
IP addresses per network zone 1000
IP addresses per rule 1000

A context-based restriction rule that includes multiple network zones can have a maximum of 1000 IP addresses indirectly associated with it. For example, in a rule that includes two network zones, one of the zones might have 800 IP addresses and the other might have a maximum of 200 IP addresses.

If you want to check the number of rules in your account, see Viewing the total number of rules per account. To request an increase in the account limit, see Requesting a policy and rule shared limit increase.

Eventual consistency

Context-based restrictions follow an eventually consistent pattern that is common to many cloud-native services. As a result, Context-based restrictions remain highly available and performant across multiple global regions. Changes that are made to Context-based restrictions rules and network zones are recorded and propagated worldwide. Access changes might not take effect until the propagation process is complete, usually within a few minutes.


  1. IAM policies and context-based restrictions rules share a combined limit of 4020. ↩︎