Introducing Service Roles and Namespaces in IAM for More Granular Control of Cluster Access
By: Chris Rosen
Updating Kubernetes Service clusters to support IAM service roles
IBM Cloud Kubernetes Service is giving you more control over granting users granular access to cluster resources like namespaces in IBM Cloud Identity and Access Management (IAM). As part of this enhanced access management capability, we are updating your Kubernetes Service clusters to support IAM service roles in addition to platform roles as of January 30, 2019. By having both service and platform roles, you have more flexibility in restricting your users to only access resources that they need to access.
When you combine platform and service roles with IAM access groups, you can make it easier to manage access for large groups of users. For example, you can create an access group for a Finance team of developers and give the group a Writer service access role to all finance-test Kubernetes namespaces in all your clusters. Then, each user that belongs to the Finance access group automatically can connect to a cluster and be able to deploy apps in only the finance-test namespaces.
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.
Using service roles for Kubernetes Service in IAM
Previously, IBM Cloud Kubernetes Service supported only platform access roles. These platform roles were mapped to Kubernetes RBAC roles to authorize actions in the default Kubernetes namespace to resources within the cluster, such as pods or deployments. Now, you can separately grant access to users with platform and service access roles. Additionally, service roles can be scoped to any Kubernetes namespace within the cluster.
What’s the difference between platform and service roles?
What is authorized by the rolesPlatform rolesService roles
ServiceIBM Cloud Kubernetes ServiceKubernetes as accessed from within a cluster
InterfaceGUI: IBM Cloud Kubernetes Service console
CLI: ibmcloud ks
CLI: kubectl CLI, ibmcloud ks cluster-config –cluster <cluster_name_or_ID> command so that users can access the cluster
API: Kubernetes API
Example resourcesIBM Cloud infrastructure resources such as clusters, worker nodes, and Ingress application load balancersKubernetes resources within a cluster, such as namespaces
Possible rolesAdministrator, Editor, Operator, ViewerManager, Writer, Reader
If I have existing clusters, what can I expect?
IBM Cloud IAM platform roles no longer assign access to Kubernetes RBAC. Instead, service roles are mapped Kubernetes RBAC. Existing users are automatically given service roles based on their existing platform roles as described in the following table, and they will also retain their platform roles. After January 30, 2019, account admins must follow the new way of assigning service roles and access to namespaces. If you assign user roles while the existing roles are updated, the new roles follow the new way and are not updated.
Keep in mind that IBM Cloud IAM service roles just correspond to a Kubernetes RBAC policy. IAM does not have visibility into your cluster’s RBAC, such as if you make changes to these policies. Instead of managing RBAC yourself, consider using IAM access groups, service roles, and Activity Tracker to audit changes in user and group access.
How does this affect accessing my cluster?
If you assign only service roles to users, they cannot view or interact with any IBM Cloud Kubernetes Service infrastructure resources (which are now assigned with platform roles). For the users to access the cluster and use the cluster’s Kubernetes resources, you must give users the cluster name and ID so that they can perform the ibmcloud ks cluster-config command, and then launch the Kubernetes dashboard from the CLI. If you want these users to still be able to access the Kubernetes Service clusters console and list clusters and other infrastructure resources from the CLI, also give the users the platform Viewer role.
If you assign only platform roles to users, they cannot interact with Kubernetes resources within the cluster. They can, however, still perform the ibmcloud ks cluster-config command. Then, you can authorize the users to perform select Kubernetes actions by using custom RBAC policies. You might do this if your organization currently uses custom RBAC policies to control Kubernetes access and plans to continue using custom RBAC instead of service roles.
Is there a list of what actions the platform and service roles authorize?
Yes, see our expanded permissions reference docs:
How can I assign platform and service roles going forward?
You can follow the same steps in “Granting users access to your cluster through IBM Cloud IAM.” Now, when you get to the Select roles section, you can choose from both platform and service roles. Consider setting up IAM access groups and assigning those groups certain platform or service roles to make it easier to manage access for large groups for users.
Assigning access to namespaces in IAM
In IBM Cloud IAM, you can now assign users with service roles to namespaces within your clusters. When you assign access to a namespace, the policy applies to all current and future instances of the namespace in all the clusters that you authorize.
For example, let’s say that you have a deve access group of users that you want to be able to deploy Kubernetes resources in a test namespace in all your clusters in the US South region (Dallas location). If you assign the Dev access group a service access role of Writer for all clusters in the US South region and the default resource group for namespace test, the Dev group can access test in any US South cluster in the default resource group that currently has or eventually has a test namespace.
Before you begin, make sure you have the Administrator platform role for the IBM Cloud Kubernetes Service account and have users or access groups that you want to manage.
Log in to the IBM Cloud console and navigate to Manage > Account > Users.
Select users individually or as an access group. For access groups, go to the Access policies tab.
Click Assign access > Assign access to resources. Note that you cannot assign users to namespaces from resource group access.
Assign the user a policy to a namespace.
From the Services list, type Kubernetes Service.
From the Region list, select one or all regions.
From the Cluster list, select an individual cluster or all instances.
In the Namespace field, enter the name of the Kubernetes namespace that you want to scope the access policy to. Remember that the policy grants access to namespaces in all clusters that you previously selected, such as all clusters within a region. If you want to grant access to all namespaces, you can leave the namespace field blank.
Select a Service access role. Note that you must NOT assign a platform role when you assign a service role for a namespace. If you do, the platform role is not applied to the users. Assign platform roles separately.
Great! Your users now have a service role that grants them a corresponding Kubernetes RBAC role or cluster role as follows. To find a list of supported Kubernetes actions per RBAC role, see “User-facing roles in the Kubernetes docs.”
Manager grants the Kubernetes RBAC admin role for this namespace. If you leave the namespace blank, the user gets the cluster-admin role for all namespaces and clusters that you scope the policy to.
Writer grants the Kubernetes RBAC edit role for this namespace.
Reader grants the Kubernetes RBAC view role for this namespace.