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, 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.
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 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:
| 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.
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.
| 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.
| 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:
| 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 | Account Management | 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.