What are context-based restrictions?

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.

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.

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.

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.

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.

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.