Resource Group Support in IBM Cloud Kubernetes Service
5 min read
By: Chris Rosen and Jeff Sloyer
Key benefits of resource groups and IAM integration with Kubernetes Service
You’ve heard of resource groups and access groups, but you wonder why you should use them. If you can answer “Yes” to the following questions, keep reading!
Have you individually assigned users in your account to different resources?
Do you want to meter resource usage at an internal department level and provide a quota and chargeback?
Now, both of those very real and tedious challenges are addressed by IBM Cloud Kubernetes Serviceleveraging fine-grained access controls and separation of resources by using new capabilities from IBM Cloud.
What is IBM Cloud Kubernetes Service?
IBM Cloud Kubernetes Service is a managed Kubernetes offering to deliver powerful management tools, an intuitive user experience, and built-in security and isolation to enable rapid delivery of applications, all while leveraging Cloud Services like cognitive capabilities from Watson. IBM Cloud Kubernetes Service provides native Kubernetes capabilities, such as intelligent scheduling, self-healing, horizontal scaling, service discovery and load balancing, automated rollouts and rollbacks, and secret and configuration management. Additionally, IBM is adding capabilities to the Kubernetes Service, including simplified cluster management, container security and isolation choices, the ability to design your own cluster, the option to leverage other IBM Cloud services (such as Watson) for your cognitive applications, completely native Kubernetes CLI and API, and integrated operational tools or support to bring your own tools to ensure operational consistency with other deployments.
Overview of resource groups
Resource groups allow you to organize your account resources for defining access control and billing separation. A resource is anything in IBM Cloud that can be created, managed, and contained within a resource group. Only these resources can be added to resource groups—not users. To grant access to the services and apps in the resource group, you apply access policies to team members, either individually or in groups. To learn more, read Best Practices for Organizing Resources in a Resource Group.
The benefits of Identity and Access Management
Identity and Access Management (IAM) enables you to securely authenticate users for both platform services and control access to resources consistently across IBM Cloud. IAM enables you to define:
Fine-grained access control
API key creation for authorization
Service IDs can be created for application authentication within IBM Cloud Kubernetes Service against other cloud services. For more information, please read the IBM Cloud IAM Getting Started Tutorial.
Get started with resource groups
First, decide which resource group you want to use. Out of the box, you will have a resource group called
default, where any existing Kubernetes clusters are. To create additional resource groups, go here.
You might want to create additional resource groups for different stages of an application lifecycle in your pipeline, such as
prod, or for your business units, such as
accounting. Resource groups 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.
After you have a resource group created, go to the IBM Cloud IAM service to create policies inside of the resource group. To assign a policy, you either need to invite a user or edit an existing user. For this tutorial, let’s edit an existing user.
First, select a user and click Assign access. Next, click the Assign access within a resource group tile, as shown in the following image:
On the next page in the drop-down box, choose the resource group that you want to use.
The next Assign access to a resource group drop-down is important because it allows you to control what the user can do to the resource group itself. You have four options:
No Access: The user cannot see or edit the resource group itself.
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.
For the purposes of this tutorial, the user I am editing is going to be able to see the resource group called zues, as shown in the following image:
The next step is assigning access rights to the IBM Kubernetes Service (see the following diagram). I am assigning the user the Editor role to all Kubernetes clusters in the resource group zues in all regions. This assigns policy to a parent object—think of it as a sub-account—and then anything that’s created in the resource group inherits the policy of this sub-account.
Additionally, you can set policy for all clusters that are in only a particular region within a resource group, such as shown in the following image:
Common use cases of resource groups
With resource groups, you can now share your IBM Cloud account with your larger organization and team and assign fine-grain access roles.
Pipeline resource groups
Create clusters in different resource groups for each pipeline and assign policies to those resource groups. For example, if you want your development team to have full Administrator access to development and preprod but only Viewer access in prod, you can now do this with resource groups.
First, create resource groups called
prod. Then, use the previous “Get started with resource groups” tutorial steps to give your development team full access to cluster resources in the
preprod resource groups but only “view” access to
Department resource groups
Building on the pipeline use case, you can create resource groups on a business-unit level (e.g.,
accounting). You can assign users to a resource group and give them Administrator access to their clusters. For example, you add Jane to the
accounting resource group with admin rights but assign Bill to the
marketing resource group with admin rights. Bill and Jane aren’t able to see the other department’s clusters, which provides separation of control between the two business unit resources.
Legacy IBM Cloud infrastructure accounts
If you have a legacy IBM Cloud infrastructure account and have manually supplied your API keys to use with the IBM Kubernetes Service, you can now do that on a resource-group level instead of a whole-account level. This allows you to use multiple IBM Cloud infrastructure accounts in a single IBM Cloud account.
For example, if you want to provide admin rights on separate clusters for individual teams but at the account level, this is now possible. Create a resource group for the individual team and assign admin rights to the IBM Kubernetes Service in that resource group to the members of that team. By doing that, you give the team full control of their clusters but not other clusters in the account. You can also assign other roles besides administrator, such as editor, operator, and viewer. These other roles provide a more limited view of the clusters.
To take things to the next level, you can batch assign policy to a group of users. For more info, see here. Go ahead and create an access group. I called mine Nathan’s Department, as you can see in the following image:
After you create the group, click Add users. On the next page, choose the users you want and select Add to group. If you don’t see the people that you want listed, add them to your account and then add them to the group.
Next, go to the Access policies tab and click Assign access, as shown in the following image:
Click Assign access within a resource group. Follow the previous instructions for adding a policy to a user:
By using these steps, you can batch assign policy to hundreds of users to a common set of Kubernetes clusters within a resource group.
If you have questions, engage our team via Slack by registering here and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.