Designing access control and resource ownership for your cloud project.

This post is a quick follow-up on my recent blog on best practices for the cloud onboarding of enterprise projects. There, I discussed how to use Terraform scripts as a blueprint in the onboarding process. Starting with a corporate standard for setting up roles and other security objects, project-specific layers are added later on. The IBM Cloud solution tutorial on applying end-to-end security to a cloud application served as an example. In this blog post, I am going to share details on how I mapped project resources to roles.

Access control

IBM Cloud IAM (Identity and Access Management) implements attribute-based access control (ABAC). Attributes from identities and resources form the input for the decision engine to determine whether to grant access or not. By only using the IAM concept of access groups, it is possible to simulate role-based access control (RBAC). RBAC is simpler to map to project structures with its team roles. 

Therefore, I avoided directly assigning access policies to individual users and service IDs; instead, I only worked with access groups. Moreover, this follows the best practices for IBM Cloud IAM:

A best practice in IBM Cloud IAM is to use access groups to manage access for identities. After the access group access policies are defined, granting and revoking access is simply a matter of adding and removing identities to or from access groups. A user or service ID can belong to as many access groups as the administrator wants, and the members of the group inherit all access that is assigned to the access group. This approach provides the fine-grained access benefits of ABAC with the simplicity of RBAC.

Following that role-based approach, the diagram below shows the setup of access groups. See the blog-related GitHub repository for details. Assigned access policies for each group follow the principle of least privilege. Typically, this is a Viewer and/or Reader privilege on common platform or account services and Editor, Operator, or Administrator on role-specific resources.

It should be noted that, in addition to the general role-based approach, direct service-to-service authorizations are still possible and useful. A common scenario is a service authorization to retrieve keys from Key Protect or the ability to read from or write to Cloud Object Storage.

Resource ownership

With the right roles (access groups) in place, the next question is on how to assign resource ownership. Multiple variations exist, even for the sample scenario. Here are some considerations:

  • Services like the Activity Tracker with LogDNA or the Certificate Manager are shared across projects in the same account and should be owned by the security (service) ID. It is important to note that all “global events” are logged in the IBM Cloud Frankfurt instance.
  • Depending on corporate standard or project structures, VPC resources could be owned by the network group or by groups like DevOps. In my setup, I opted for a dedicated group of network admins.
  • There might be a distinction between App Services and DevOps. One is centered around the data management for a solution, the other on maintaining the application itself.


Different projects require different setups, but they should always follow a common standard on how to organize access control (security) and resource ownership (organization). For more, see the following posts:

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


More from Cloud

IBM Tech Now: October 2, 2023

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 86 On this episode, we're covering the following topics: AI on IBM Z IBM Maximo Application Suite 8.11 IBM NS1 Connect Stay plugged in You can check out the IBM Blog Announcements for a…

IBM Cloud inactive identities: Ideas for automated processing

4 min read - Regular cleanup is part of all account administration and security best practices, not just for cloud environments. In our blog post on identifying inactive identities, we looked at the APIs offered by IBM Cloud Identity and Access Management (IAM) and how to utilize them to obtain details on IAM identities and API keys. Some readers provided feedback and asked on how to proceed and act on identified inactive identities. In response, we are going lay out possible steps to take.…

IBM Cloud VMware as a Service introduces multitenant as a new, cost-efficient consumption model

4 min read - Businesses often struggle with ongoing operational needs like monitoring, patching and maintenance of their VMware infrastructure or the added concerns over capacity management. At the same time, cost efficiency and control are very important. Not all workloads have identical needs and different business applications have variable requirements. For example, production applications and regulated workloads may require strong isolation, but development/testing, training environments, disaster recovery sites or other applications may have lower availability requirements or they can be ephemeral in nature,…

IBM accelerates enterprise AI for clients with new capabilities on IBM Z

5 min read - Today, we are excited to unveil a new suite of AI offerings for IBM Z that are designed to help clients improve business outcomes by speeding the implementation of enterprise AI on IBM Z across a wide variety of use cases and industries. We are bringing artificial intelligence (AI) to emerging use cases that our clients (like Swiss insurance provider La Mobilière) have begun exploring, such as enhancing the accuracy of insurance policy recommendations, increasing the accuracy and timeliness of…