Plan Installation

To understand how the process is performed, keep these concepts in mind.

A environment is installed and used by users acting in four roles:

The account owner must create the access group for account managers (see below). The account owner will:

Then, as described in Configure Account, the account managers can set up the resource groups and access groups needed to install and use the environments. For each environment, the account managers will:

This diagram from Resource Access Management shows the relationship of these access groups to a pair of development environments:

The steps below help the account owner start configuring the account in this manner.

Environment Architecture shows the structure of the environment that will be installed. Typically, each development team gets its own environment. However, multiple teams can share a single environment. The environment structure is designed to support best practices for a cloud-native application architecture, including designing applications that are built to manage.

The account owner may want to delegate the responsibilities for configuring the account for all of the development teams that want environments. Those users who are delegated to will need account management permissions. An easy way to manage who has these permissions is to create an access group with those policies and add those users to the group. An account only needs one of these account manager access groups, which will be used to support all environments in the account.

In a new account, the account owner is the only user. Even after inviting other users, the account owner is initially the only user with the account management permissions needed to grant those permissions to other users. Therefore it is the account owner who must create the access group for account managers.

We’ll use some scripts in the steps below to help create access groups. Here, we’ll download the scripts and prepare to run them. (If you want to use the console to manually configure the access groups, you can skip this step.)

Clone the Git repository with the scripts. (This repo also has the scripts for installing the environment.)

The scripts need you to log into IBM Cloud first. In the terminal you’ll use to run the scripts, log in to IBM Cloud.

The account owner must create an access group to grant the necessary permissions for managing the account. Do this by running a script, or by using the console to manually perform the steps in the script. Also, add the account manager(s) to this group.

To create the access group for the account managers:

The script adds policies that allow the user to:

The script also adds the same policies that an environment administrator has. But whereas an environment administrator can only manage the resources in one resource group, an account manager can manage the resources in all resource groups. This gives the account manager the ability in any resource group to:

Account managers need the permissions to create and manage IaaS resources required by a environment. Permissions for classic infrastructure (fka SoftLayer) cannot be added to an access group, only to a user. Rather than add these permissions to each account manager, create a functional ID and grant it the infrastructure permissions. The functional ID will own the API keys that the Kubernetes service needs to create clusters. As account managers are added to and removed from the account, the functional ID will always remain and always have the necessary infrastructure permissions.

Set up the functional ID in the account:

The script adds the classic infrastructure permissions needed to create and manage clusters:

The script also adds the IAM permissions to:

By granting these infrastructure permissions to the functional ID and using it to create API keys, the account managers and environment administrators can create Kubernetes and OpenShift clusters without needing infrastructure permissions.

Next, each account manager will need to use the functional ID to reset the API key that the Kubernetes service will use. By using the functional ID, the API key will be owned by the functional ID instead of by the account manager. The account managers need a way to log in as the functional ID without all of them sharing the ID’s password or a single API key. Thus each account manager needs their own API key for the functional ID’s account.

Create API keys for the functional ID:

Users should not share these API key files with each other. When a user is no longer an account manager, remove them from the access group and delete their API key. To make a user an account manager, add them to the access group and create an API key for them.

The overall process:

Once the environment is set up, the environment users can start using it to develop applications.

First, before installing an environment, an account manager needs to configure the IBM Cloud account for the environment. See Configure Account for detailed instructions, which accomplish this:

Second, once the account manager has configured the account for installing an environment, the account manager and the environment administrator need to jointly decide how the environment administrator is going to install the environment. There are two options:

Install including creating a new cluster: The environment administrator who performs this install needs permissions to create clusters as well as service instances. The script will run as this user to create the cluster, create the service instances, and install the CI/CD tools in the cluster.

Install into an existing cluster: The account manager creates the cluster and then grants the environment administrator access to it. The environment administrator who performs this install needs permissions to create service instances but not to create clusters. The script will run as the environment administrator to create the service instances and install the CI/CD tools in the existing cluster.

Third, after installing the environment, before giving the users access to the environment, the environment administrator needs to finish configuring it. See Configure Environment for detailed instructions, which accomplish this:

Having configured the account, installed the environment, and configured the environment, the administrators have now completed an end-to-end installation of a environment. It is ready for a development team to begin using for application development.