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.

Conclusions

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:

• Blueprinting the Onboarding of Cloud Projects using Terraform
• Insights into IBM Cloud Access Privileges
• Updated Tutorial on End-to-End Cloud Security

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