Best practices for the cloud onboarding of enterprise projects.
Recently, I blogged about getting insights into IBM Cloud access privileges. Today, we are going to put them into practice. When onboarding a new project — either on-prem or to a cloud environment — there should be no questions on how to get started. Onboarding should follow an enterprise-defined process based on (internal) standards. It needs to detail access roles and privileges and provide means to implement them.
In this blog, I am going to discuss such a project onboarding. Terraform scripts implement the rules as code — they help to automate roll-out and tear down access roles and privileges. The scenario from the solution tutorial "Apply end-to-end security to a cloud application" serves as specific example to proof-point the ideas.
In an enterprise, onboarding a new project to a cloud environment should be a daily routine and follow a corporate standard. Quite often, unfortunately, this is not the case. Things to consider range from account ownership and billing over resource and access management to enforcing regulatory compliance via controls and audit. In this blog, we will briefly touch on all of those aspects, but focus on account setup for resource and access management.
Account or enterprise
As a typical user, you are working in an IBM Cloud account. However, corporations can use so-called enterprises to centrally manage billing and resource usage across many accounts. Enterprises can be organized into account groups and accounts on multiple levels. Thereby, they can mimic corporate organizational structures. Large customers could map a new cloud project to an account within an enterprise. In the extreme, each environment for a project (e.g., development, test, production) could be mapped to its own account inside the enterprise.
Within an account, resources can be organized in resource groups. They provide a means to separate resources for different tasks, environments, and project groups. If working with a single IBM Cloud account only, resource groups are the way to organize projects and their assets.
Users, service IDs, and access groups
As mentioned, as a typical user, you are working in an IBM Cloud account. If you are not the owner, you have been invited to it. Another type of identity is a service ID. It is created in an account, usually to represent an application or service. Both users and service IDs can be added to access groups. Access groups are used to bundle a set of privileges (access policies) for easier administration. In that sense, access groups are similar to security roles (i.e., each access group could define a role in the cloud development project).
Depending on their assigned privileges, users and service IDs are capable of provisioning resources. To define the set of available services, administrators can set up private catalogs. A private catalog holds a subset of what is available in the IBM Cloud (public) catalog. It can be defined for an individual account or on the enterprise level. Moreover, it is possible to add products to a private catalog.
Common account setup
In order to get started with a new project, a common set of structural objects should be rolled out:
- Access groups to mimic roles in the development project (e.g., security admins, network admins, developer, DevOps, billing, audit, etc).
- Resource groups to organize resources for deployment stages like development, test, or production environments.
The base setup is easily deployed using Terraform scripts. The sources are managed in a corporate, version-controlled repository. To adapt the common skeleton to the specific project, parameters are used. Thus, all projects follow a corporate standard which is managed as infrastructure as code/deployment as code (e.g., as Terraform scripts).
The following Terraform snippet shows how the access group for organization admins is created and how access policies are assigned. See this GitHub repository for the full code sample.
With the common access groups and resource groups in place, the account setup can be adapted to the project requirements. Typically, even for fresh development projects, some resources need to be deployed. These could be database or security services, cloud object storage, or toolchains.
For this blog, I picked the solution tutorial on applying end-to-end security to a cloud app as sample project. Its architecture is depicted below:
On top of the general account setup, the following is deployed as either account owner or (super) administrator:
- Set up a service ID for each access group to be used for creating resources.
- Set up an API key per service ID so that the resources can be deployed (in Terraform).
- Set up an additional access group to manage privileges for all application-related resources.
- Optionally, remove unused access groups.
- Adapt existing access groups to project requirements. This is mainly to add more privileges (access policies) so that roles (access groups) can manage or view project-specific resources.
- Optionally, adapt some configuration to the deployment region. This could be for additional compliance requirements, naming conventions, or other reasons.
- Invite project members as users to the account, directly assigning them access groups based on their project role(s).
Once the above project-specific extra layer is in place, additional resources can be created. In contrast to above, the new service IDs and their API keys are utilized to roll out the resources access group by access group. In the case of my example, it includes deploying common security services like the Cloud Activity Tracker or Certificate Manager using the security admin service ID. Moreover, application services like Key Protect for IBM Cloud (including root keys), IBM Cloud App ID, IBM Cloudant, and IBM Cloud Object Storage are created by the new service ID for application resources.
The following Terraform code sample from the GitHub repository shows how to deploy the Key Protect and Cloud Object Storage (COS) services, create a new root key, and use it for a new storage bucket. It also requires you to define the service authorizations.
As mentioned at the beginning of this post, there should be no questions on how to get started when onboarding a new (cloud) project – it should follow an enterprise-defined process. In this blog, I introduced such a process. It starts with a new account and the corporate base layer. Thereafter, a project-specific layer is deployed which follows a defined pattern. Last, using new role-based service IDs, resources for the application or project are deployed.
Here are my lessons learned from such a project:
- Automated, cascaded deployments are possible. Using Terraform, deployments are handled as code and managed as such.
- Design a common blueprint for all projects, then customize it for specific projects. It simplifies the overall project management and enhances security.
- Identity and Access Management (IAM) differs between cloud providers. Invest time to understand the IAM concepts.
- Keep a Zero Trust Architecture in mind and design the blueprints for a least privilege model.