Use context-based restrictions in IBM Cloud to define and enforce access restrictions based on properties from where the access request originated.

Last year, IBM Cloud introduced context-based restrictions (CBRs). Context-based restrictions provide the ability to define and enforce access restrictions based on the network location (“context”) of access requests. Contexts are defined by the type of endpoint or a network zone (or a combination of those). A rule links a context to a resource. When the rule is enabled, only requests that match the context are allowed to proceed to other authorization checks. Because CBRs complement Identity and Access Management (IAM) policies, they are an important building block towards a zero trust architecture. Even if your credentials are leaked or IAM policies misconfigured, CBRs still enforce access and may scope allowed requests to your compute resources or corporate networks.

In this blog post, I am going to discuss such a scenario. I wanted only my code deployed to IBM Cloud Code Engine to access the files in my IBM Cloud Object Storage (COS) bucket and to block traffic from on-prem and other environments. I deployed the CBR network zone (context) and the rule using Terraform. In the following, I am providing more details on the test scenario and showing how I deployed the CBR access control. You can find the details and related code on GitHub in my repository context-based-restrictions:

Access to your cloud storage buckets

For my test of enforcing access control with context-based restrictions, I set up a new storage bucket cbrbucket in my S3-compatible instance of Cloud Object Storage (COS). After uploading a few files, I locally ran the Python script from the mentioned GitHub repository to first list all available buckets on that COS instance, then the items in the bucket cbrbucket. It succeeded and showed 10 buckets and 2 files. 

Then, I containerized the Python script and turned it into a Code Engine job. Once ready and configured, I submitted a Code Engine jobrun. The following screenshot shows the entries from Log Analysis. The output is similar to that from running it locally:

Network zones and rules for access restrictions

With the test scripting in place, the next step is to define the context-based restriction (CBR) network zone and rule for my scenario. Because I love automation, I created a Terraform script. It reads in the metadata for my COS instance and some account information, then sets up the CBR network zone followed by the rule. The network zone specifies all traffic originating from the Code Engine service, regardless of the endpoint type. The rule is defined as enabled and ties the previously created network zone to my COS instance and the bucket cbrbucket. Thus, only traffic coming from Code Engine is allowed to access the bucket.

When creating CBR network zones and rules, it is important to know that the changes are eventually consistent. So if you run tests immediately after deploying CBR changes, they might not be in place worldwide.

After I created the network zone and rule for Code Engine and the COS bucket and they became active, I submitted a new Code Engine jobrun. The result was similar to the screenshot above — access was still possible. However, running the Python script locally resulted in an access error like the one shown below:

Later, I added my own IP address to the network zone and re-ran my local test. This time, it succeeded as expected. Similarly, you could add your corporate network (gateway) or other trusted networks to network zones.

Conclusion

Context-based restrictions help to create an extra layer of security checks for your cloud-based solution. By defining the right network zones and implementing access rules for your deployed services, context-based restrictions enable you on your journey towards a zero trust architecture. To get started, I recommend the following resources:

• IBM Cloud documentation: What are context-based restrictions?
• My repository for this blog post on GitHub with scripts and more links.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.