Role-Based Access Control with Cloud Foundry in Kubernetes
In modern software development infrastructure, role-based access control (RBAC) is a hierarchical approach to security. It is basically a security design that restricts access to sensitive resources based on the role that a user holds.
The way RBAC is implemented can be different across various platforms, for example the way RBAC is implemented in Kubernetes is a bit different from the way it is implemented in Cloud Foundry for Kubernetes (cf-for-k8s). At a high level, Kubernetes RBAC is used for access control across the entire Kubernetes control plane. Cloud Foundry RBAC is used for operations strictly within the Cloud Foundry life cycle—it leaves cluster-level operations to Kubernetes RBAC.
To elaborate a little more, this doesn’t mean that you cannot add additional components through Cloud Foundry. It does mean that things that are not handled in the Cloud Foundry life cycle use Kubernetes RBAC since, at that point, you’d be interacting directly with the Kubernetes API.
This article will discuss how RBAC in Cloud Foundry works, but this is not a comparison between how RBAC is implemented in Kubernetes versus how it is done in Cloud Foundry. Why? Because, as I mentioned above, the way RBAC is implemented can be different across various platforms; it depends on the thought process of the team that implemented it. It is not a competition; it is more of a preferred design pattern. This article is meant to deliver insight into how RBAC works in Cloud Foundry with reference to Kubernetes.
RBAC in Kubernetes
RBAC in Kubernetes is pretty straightforward. Kubernetes uses an API group (rbac.authorization.k8s.io) to handle any authorization decisions and allow you to dynamically configure policies. You just need to execute a chain of commands to enable RBAC in Kubernetes. For more information, go here.
There are a few RBAC concepts in Kubernetes that should be highlighted first, as they will help describe the Cloud Foundry equivalent.
Namespace
A namespace in Kubernetes is basically a way to organize clusters into virtual groups of clusters, typically belonging to a single purpose. They are quite useful when a team of people are working on a single Kubernetes cluster. It is the most basic form of RBAC in Kubernetes. The most basic way for creating a namespace is by simply running the following command:
You can also use a YAML file to create a namespace if you have specific configurations you need, for example:
Run the following command to apply the above config to your kubernetes cluster:
Cloud Foundry’s equivalent of Namespaces is called a space.
A role is an RBAC protocol that contains a bunch of permissions specifically for a particular namespace. It basically specifies the set of resources a particular namespace has access to in a Kubernetes cluster. Here is a simple example of a role in a “default” namespace.
The above configuration would grant the user read and write access to all the resources available in the “default” namespace.
In addition to creating roles, Kubernetes provide some default user-facing roles like:
- Cluster-admin
- Admin
- Edit
- View
ClusterRole
A ClusterRole is similar to a role and can be used to grant the same permissions. The only difference is that they are cluster-scoped, which means that they can be used across an entire cluster and are not restricted to a specific namespace. Here is a simple example of a ClusterRole:
The above configuration will give a user read access to all the resources available in the cluster.
RoleBinding and ClusterRoleBinding
RoleBinding and ClusterRoleBinding simply refer to a process to attach the Role or ClusterRole that you have created to a specific user. It simply consists of writing a configuration that binds or attaches the permissions in a role or a clusterrole to a user that is available in the cluster or a namespace.
As you can see, managing RBAC in Kubernetes comes with a certain amount of complexity and manual effort.
RBAC in Cloud Foundry
Cloud Foundry for Kubernetes uses the same RBAC protocol that Cloud Foundry has used since its inception—a tested and trusted RBAC method that builds on years of cloud-native experience. Cloud Foundry makes use of the Cloud Controller API to handle authorization requests for RBAC. It provides access to a set of REST API endpoints to create and manage apps, services, user roles and more.
The Cloud Controller API is the system Cloud Foundry communicates with whenever it is trying to determine the permissions available for a particular user. It can also create users based on a predefined set of roles available for a user.
Cloud Foundry for Kubernetes (cf-for-k8s) currently does not have the same RBAC system as regular Kubernetes. For example, instead of namespaces, roles, cluster roles, etc., Cloud Foundry uses orgs, roles and spaces to create some form of permissions hierarchy in a system.
User Roles
Cloud Foundry allows developers to use predefined roles in their orgs. These roles can be assigned by an admin user to other users within an organization and a user can have more than one role assigned to them. Here are a few roles available in Cloud Foundry:
- Admin: Can perform operational actions on all orgs and spaces
- Admin Read-Only: Has read-only access to all resources in the cluster.
- Global Auditor: Has read-only access to all resources except for secrets such as environment variables. The global auditor role cannot access those values.
For the full list of roles available, please refer to this page.
The best part of RBAC in Cloud Foundry is that there’s no need to manually write configuration files to set roles; this is done through a simple command. For example, if I need to set the role of OrgManager to a user called “admin”, I can do this by running the following command:
This is the output of the command:
Cloud Foundry currently does not support creating custom user roles. There are about 10 different predefined roles available for developers to choose from as well as the ability for a user to have more than one role.
Orgs
An org is a development account for collaborators on a project; each user in an org has roles such as org manager, org auditor, and org billing manager. Collaborators in an org share a resource quota plan, apps, services availability and custom domains. A single account can have more than one org and multiple spaces in it.
For example, if I need to see all the orgs available in my account, I can do this by running the following command:
This is the output of the command
If I need to see all the users available in org “foo”, I can do this by running the following command:
This is the output of the command
Spaces
A space is Cloud Foundry’s equivalent of the Kubernetes namespaces. Since Cloud Foundry for Kubernetes uses the same RBAC system as regular Cloud Foundry, this is also available for use in cf-for-k8s. A space provides users with access to a shared location for app development, deployment and maintenance. There are user roles that can be assigned to users for use only within a particular space by the OrgManager. A space lives within an org and a single org can have multiple spaces.
For example, I can see the spaces available in a particular org “foo” by running the following command:
The output of the command:
Let’s create a new user called “admin-2” and let’s set the role of that user to spaceManager
Create User
The output of the command:
If I need to set user “admin-2” as a space manager for space “shedrack”, I can do this by running the following command:
The output of the command:
Permissions
Each user role available in Cloud Foundry has different permissions that are assigned to them. These permissions are similar to role permissions in Kubernetes, and they are easy to use.
For more information on the different types of permissions available, check this page on the official Cloud Foundry documentation.
Roadmap
Cloud Foundry for Kubernetes has a lot of prospects and also features that are being considered in the long run, a few things in particular would make it even more Kubernetes-native.
Some of the tenancy constructs and access control methods in CF would translate into Kubernetes itself instead of relying on the cloud controller API. More work is being done to make RBAC in cf-for-k8s a great cloud-native experience and also implement it with the Kubernetes API.
RBAC in Cloud Foundry for Kubernetes gives developers the Cloud Foundry experience in Kubernetes. It’s very easy to understand and use RBAC in Cloud Foundry and most actions are automated with commands rather than having to write YAML. In terms of improvements, the community is working to create parity with how it is implemented in Kubernetes for platform operators that are from a plain Kubernetes background.
Many thanks to Shedrack Akintayo for helping prepare the first draft of this article.