Resource groups, lets you organize your resources for access control and billing purposes. If you are familiar with using Cloud Foundry spaces, you can think of organizing resources into resource groups similarly to the way you organized resources into spaces. A resource is anything that can be created, managed, and contained within a resource group. Users aren’t added to resource groups — only resources can be added. Refer to this blog [https://www.ibm.com/blogs/bluemix/2018/10/resource-group-support-in-ibm-cloud-kubernetes-service/] for more details.

The benefits of Identity and Access Management (IAM)

IAM enables you to securely authenticate users for both platform services and control access to resources consistently across IBM Cloud. It provides the capability to perform the following:

• User management
• Fine-grained access control
• API-key creation for authorization

Resource groups in IBM Kubernetes Service

When you provision a cluster on IBM Kubernetes Service, out-of-box, you will see a default resource group. In order to organize the resources used by your application in dev, stage & production environment; you could create additional resource groups each stages in the application lifecycle dev, stage, and prod. These resource groups, will give you the ability to set fine-grained access control for a set of Kubernetes clusters, so that you can share your account with your whole organization.

resource "ibm_resource_group" "resourceGroup" {

name     = "prod"

}

After creating the prod Resource Group, you can assign Access Policy for a user test@in.ibm.com, by inviting the user to “myorganization” and “myspace”.

resource "ibm_org" "org" {
  name             = "myorganization"
  users            = ["test@in.ibm.com"]
}

resource "ibm_space" "space" {
  org        = "${ibm_org.org.name}"
  name       = "myspace"
  developers = ["test@in.ibm.com"]
}

The next Assign access to a resource group because it allows you to control what the user can do to the resource group itself. You have three options:

• Viewer: The user can see the resource group but cannot edit.
• Editor: The user can perform all platform actions except for managing the account and assigning access policies.
• Administrator: The user can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users.

Lets add Viewer role to user test@in.ibm.com for resource group.

resource "ibm_iam_user_policy" "policy1" {
  depends_on = ["ibm_org.org", "ibm_space.space"]

  ibm_id = "test@in.ibm.com"
  roles  = ["Viewer"]

  resources = [{
    resource_group_id = "${ibm_resource_group.resourceGroup.id}"
  }]
}

Lets assign Editor role to user test@in.ibm.com for accessing the IBM Kubernetes Service.

resource "ibm_iam_user_policy" "policy2" {
 depends_on = ["ibm_org.org", "ibm_space.space"]

ibm_id = "test@in.ibm.com"
 roles  = ["Editor"]
 resources = [{
  service = "containers-kubernetes"
 }]
}

You can also set policy for all clusters in a specified region, within a resource group,

resource "ibm_iam_user_policy" "policy" {
 depends_on = ["ibm_org.org", "ibm_space.space"]

ibm_id = "test@in.ibm.com"
 roles  = ["Editor"]
 region = "us-south"

 resources = [{
  service = "containers-kubernetes"
 }]
}

Access groups and access policies

Access Groups, lets you to organize the group of users (or teams) and assign access policies. Access policies can be used to assign access to services and applications.

To take things to the next level, you can batch assign policy to a group of users. Go ahead and create an access group.

resource "ibm_iam_access_group" "accgrp" {
  name        = "prod users"
  description = "New access group"
}

After you create the group, Add users who are part of account.

resource "ibm_iam_access_group_members" "accgroupmem" {
  access_group_id = "${ibm_iam_access_group.accgroup.id}"
  ibm_ids         = ["test@in.ibm.com", "test1@in.ibm.com", "test2@in.ibm.com"]
}

Next, Assign access to access-group

resource "ibm_iam_access_group_policy" "policy1" {
  access_group_id = "${ibm_iam_access_group.accgrp.id}"
  roles        = ["Viewer"]

  resources = [{
    resource_group_id = "${ibm_resource_group.resourceGroup.id}"
  }]
}

resource "ibm_iam_access_group_policy" "policy2" {
  access_group_id = "${ibm_iam_access_group.accgrp.id}"
  roles        = ["Editor"]

  resources = [{
    service           = "containers-kubernetes"
  }]
}

Now, you can batch assign policy to hundreds of users, to a common set of Kubernetes clusters within a resource group.

You can find more information about IBM Cloud Terraform provider resources here. Please give it a try and let us know your comments!!!

I was able to use the IBM Cloud Terraform provider and provision the IBM Cloud Services / Resources, using the service-instance resources as illustrated here:

resource "ibm_service_instance" "service-instance" { 
  name       = "test"
  space_guid = "${data.ibm_space.spacedata.id}"
  service    = "compose-for-etcd"
  plan       = "Standard"
  parameters = {
    "db_version" = "3.2.18"
  }
}

However, when I tried to do the same for internet-svcs, it failed.

After some investigation, I discovered that the difference lies in how Cloud Identity & Access Management treats your Cloud Services or Resources.

• A set of IBM Cloud services are enabled to use Cloud IAM for access control and are organized into resource groups within your account to enable giving users quick and easy access to more than one resource at a time. Cloud IAM access policies are used to assign users and service IDs access to the resources within your account. You can group a set of users and service IDs into an access group to easily give all entities within the group the same level access.
• The access to the remaining set of IBM Cloud services & resources are governed using the Cloud Foundry roles; wherein Users are added to the org and space to which the instance belongs with a Cloud Foundry role assigned.

Now, “how do I find whether my Cloud Services / Resource can be accessed using Cloud IAM roles or Cloud Foundry roles ?”

This cute Service Info application can be used to find the answers. It lists all the IBM Cloud services and its corresponding details like Description, Plans, Region, Terraform Type — resource-instance (Cloud IAM roles) or service-instance (Cloud Foundry roles).

resource "ibm_resource_instance" "resource_instance" {
  name     = "test"
  service  = "internet-svcs"
  plan     = "free"
  location = "global"
}

Another, challenge that you will face, while using the resource-instance or service-instance resource in the IBM Cloud Terraform provider is — “how do I know the list of parameters required to provision the resource?” For example, I wanted to provision a compose-for-mongodb database using the service_instance, but I could not find the relevant documentation that tells me, “what parameters does it accept ? And, how to specify the required mongodb ‘version’ as the parameter?”

Here again, the same Service Info application enlists the params (and potential values) that can be passed to the Terraform configuration tf file, as shown below.

resource "ibm_service_instance" "service-instance" { 
  name       = "test"
  space_guid = "${data.ibm_space.spacedata.id}"
  service    = "compose-for-mongodb"
  plan       = "Standard"
  parameters = {
    "db_version" = "3.4.10"
  }
}

You can find more information about IBM Cloud Terraform provider resources here. Please give it a try and let us know your comments!!!

To demonstrate the technique we will use a simple python application.
The repo has two tags v0.1.0 and v0.2.0. The former will be used for the Blue deployment and the latter for the Green deployment.

Preparation for the deployment

1. Download the Terraform binary zip. Unzip it and keep the binary in path ex- /usr/local/bin.
2. Download the IBM Cloud provider binary zip. Unzip it and keep the binary in path in the same directory where you placed Terraform binary in previous step. You can also build the binary yourself. Please look into documentation.
3. Issue below commands to download and configure terraform configuration files.

$ git clone https://github.com/ashishth09/blue-green-deployment
$ cd blue-green-deployment
$ export BM_API_KEY=bx_api_key

Incremental deployment

Blue deployment

This is for the deployment of the first version of the app. App will be accessible at https://my-welcome-app.mybluemix.net

$ git checkout blue
$ terraform apply -var org=org -var space=space

After this step

• Blue is now running on IBM Cloud .
• The CF Router sends all traffic for my-welcome-app.mybluemix.net to Blue.

Green deployment

This is for the deployment of the second version of the app. App will be accessible at https://my-welcome-app-temp.mybluemix.net

$ git checkout blue-green
$ git diff blue blue-green  #To see how the configuration has changed.
$ terraform apply -var org=org -var space=space

After this steps:

• Two instances of our application are now running on IBM Cloud: the original Blue and the updated Green.
• The CF Router continues sending all traffic for my-welcome-app.mybluemix.net to Blue. The router now also sends any traffic for my-welcome-app-temp.mybluemix.net to Green.

Load balancing between Blue and Green

This is when Blue and Green are load balanced. Green is accessible at my-welcome-app.mybluemix.net and my-welcome-app-temp.mybluemix.net

$ git checkout blue-green-lb
$ git diff blue-green blue-green-lb  #To see how the configuration has changed.
$ terraform apply -var org=org -var space=space

After this steps:

• The CF Router continues sending traffic for my-welcome-app.mybluemix.net to Green.
• Within a few seconds, the CF Router begins load balancing traffic for my-welcome-app.mybluemix.net between Blue and Green.

Making blue in-accessible

Blue is no more accessible. Green continues to be accessible at two routes

$ git checkout green-only-with-2-routes
$git diff blue-green-lb green-only-with-2-routes #To see how the configuration has changed.
$ terraform apply -var org=org -var space=space

After this steps:

• The CF Router stops sending traffic to Blue. Now all traffic for my-welcome-app.mybluemix.net is sent to Green.

Remove Temporary Route to Green

Green is accessible only at original route my-welcome-app.mybluemix.net

$ git checkout green-original-route-only
$ git diff green-only-with-2-routes  green-original-route-only #To see how the configuration has changed.
$ terraform apply -var org=org -var space=space