October 23, 2020 By Henrik Loeser 3 min read

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.

Was this article helpful?

More from Cloud

A clear path to value: Overcome challenges on your FinOps journey 

3 min read - In recent years, cloud adoption services have accelerated, with companies increasingly moving from traditional on-premises hosting to public cloud solutions. However, the rise of hybrid and multi-cloud patterns has led to challenges in optimizing value and controlling cloud expenditure, resulting in a shift from capital to operational expenses.   According to a Gartner report, cloud operational expenses are expected to surpass traditional IT spending, reflecting the ongoing transformation in expenditure patterns by 2025. FinOps is an evolving cloud financial management discipline…

IBM Power8 end of service: What are my options?

3 min read - IBM Power8® generation of IBM Power Systems was introduced ten years ago and it is now time to retire that generation. The end-of-service (EoS) support for the entire IBM Power8 server line is scheduled for this year, commencing in March 2024 and concluding in October 2024. EoS dates vary by model: 31 March 2024: maintenance expires for Power Systems S812LC, S822, S822L, 822LC, 824 and 824L. 31 May 2024: maintenance expires for Power Systems S812L, S814 and 822LC. 31 October…

24 IBM offerings winning TrustRadius 2024 Top Rated Awards

2 min read - TrustRadius is a buyer intelligence platform for business technology. Comprehensive product information, in-depth customer insights and peer conversations enable buyers to make confident decisions. “Earning a Top Rated Award means the vendor has excellent customer satisfaction and proven credibility. It’s based entirely on reviews and customer sentiment,” said Becky Susko, TrustRadius, Marketing Program Manager of Awards. Top Rated Awards have to be earned: Gain 10+ new reviews in the past 12 months Earn a trScore of 7.5 or higher from…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters