Understanding Kubernetes RBAC

Update: This topic was addressed again and updated by Craig Jellick in “Understanding Authentication & Authorization in Rancher 2.0”.

The general availability (GA) release of Rancher 2.0 draws closer by the day. In this post, we’ll explore the fine control you will have over your Rancher 2.0 deployments when you leverage the role-based access control (RBAC) that Kubernetes brings to the platform. Kubernetes introduced RBAC in 1.6 and has improved it in both 1.7 and 1.8. The Internet has many articles about how to activate and configure it, but I believe that we should know why we are doing things before we start doing them. For this post, I’ll take you back to a core concept of access control known as AAA (spoken as “triple A”). AAA defines the procedure for granting access to an application, network, building, or any other system as the combination of three components: authentication, authorization, and accounting. It is from these components that it derives its name, and each component satisfies a different requirement for ensuring that the requestor is permitted to carry out an action.

Authentication

It’s important to know who is requesting access. We ask requestors to provide something that proves they are who they say that they are, such as a username and password, a one-time password from an MFA/2FA token, a fingerprint or retina scan, or something else that only that person would know or be able to access. Interestingly, the best type of multi-factor authentication (MFA) is a combination of something you know with something you have or something you are. The objective of MFA is to make it difficult for an attacker to possess both things at the same time. This means that password managers which combine an MFA token with the password record are defeating the purpose of MFA – someone need only compromise the master password to gain access to both pieces. None of this is designed to withstand rubber-hose cryptanalysis, but we try.

Authorization

Once we believe that people are who they say they are, we move on to defining what they can do. This happens with a policy that matches individuals to roles. Within a role are permissions that grant or deny access to other resources. A role can apply to multiple people, and a single person can exist in multiple roles. Generally, though not a Universal constant, a role corresponds to a group with access, such as “Admins,” “Users,” or “Developers.” When constructing policies for authorization, collecting them into roles makes it easier to maintain the policies over time. Even if a user is the sole member of a role, you don’t know that the role won’t have more members in the future. Simplify your world by always creating roles that apply to groups and then controlling role membership via group membership. In the case of Kubernetes RBAC, a role can apply to an individual, a group of individuals, or service accounts. Groups are defined by the authentication component, and group membership is set when authentication completes. Group membership is only a string value, so the authentication component must set this string correctly. Kubernetes will only check for the presence of the string; it trusts the authentication provider.

Accounting

Accounting is the process of recording who did what on the system. You can use this component for auditing, forensics, or for chargeback billing. Kubernetes provides accounting in two forms: Legacy (introduced in 1.6) and Advanced (the default in 1.8). Even if you’re already using Legacy auditing, migrating to Advanced will give you better output and more detail in what you do and don’t record. Auditing is a critical component of AAA, but it exists independently from RBAC. I encourage you to review the documentation to activate it within your cluster.

Kubernetes Resources

Kubernetes defines two resources for roles: Role and ClusterRole. It also defines two resources for connecting members (called subjects) to those roles: RoleBinding and ClusterRoleBinding. The difference between a resource that starts with Cluster and a resource that does not is the scope of the object. Cluster-prefixed objects apply globally to all namespaces in the cluster. Those that do not start with Cluster require a namespace key and only apply to that namespace. It is possible to define a ClusterRole as a policy and then apply it to a RoleBinding. Doing this restricts the scope of that role to the namespace in the RoleBinding. Both Role and ClusterRole define verbs that act on resources. For example, you might define that an account for a monitoring system has read-only access to pods in one namespace. For that you would use a Role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: monitor-pods
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods", “pods/log”]
  verbs: ["get", "list"]

You would assign this role to the monitoring account using a RoleBinding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitor-pods
  namespace: default
subjects:
  kind: Group
  name: monitoring
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: monitor-pods
  apiGroup: rbac.authorization.k8s.io

If you wished to define this role across all namespaces, you would use a ClusterRole and a ClusterRoleBinding, removing the references to the namespace:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitor-pods
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods", “pods/log”]
  verbs: ["get", "list"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitor-pods
subjects:
  kind: Group
  name: monitoring
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: monitor-pods
  apiGroup: rbac.authorization.k8s.io

The apiGroups key defines the location in the API where the resources are found. If you provide an empty value in this list, it means the core API group. Other resources live outside of the core API group. If you use CustomResourceDefinitions in your environment, you can reference those here as well. Please read the API Reference for more information.

Default Cluster Roles

If you’re concerned about the complexity of roles but still want to implement RBAC in your cluster, you can start by using default cluster roles provided automatically by Kubernetes. These are visible in the output of kubectl get clusterrole, and four that you can use right away are:

• cluster-admin
• admin
• edit
• view

With these roles, you can start to define who can interact with your cluster and in what way, and if you follow the principle of least privilege, you will grant additional privileges as necessary for work to proceed. Running kubectl describe clusterrole {name} will show you information about the ClusterRole, and if you get the information with -o yaml, you can copy it, edit it, and create new Roles and ClusterRoles for your users and resources.

Next Steps

RBAC changes how you approach security in the cluster. You now have the tools to activate granular security, but as you move into using them, move slowly, test, and experiment in a safe environment before you modify the rules that control your production environment. Kubernetes has reference documentation available about RBAC and its implementation, but like all things Kubernetes, you might find the information overwhelming. Two other articles that give real-world examples are from Bitnami and Antoine Cotten. Both explore use cases in greater depth than the Kubernetes documentation, and the latter includes a section on auditing. For information on how Rancher integrates with Kubernetes RBAC, our own Hussein Galal wrote an article in September that explains how Rancher environment roles translate to Kubernetes ClusterRoles. It also covers how to define groups in Kubernetes that correspond to Rancher external authentication providers, such as GitHub or AD. You can also join us on November 30, 2017, when Darren Shepherd and Shannon Williams will be demonstrating how to manage Kubernetes clusters with Rancher 2.0. Our Meetups are always exciting, with live demos and great feedback, so register and come learn!

About the Author

Adrian Goins is a field engineer for Rancher Labs who resides in Chile and likes to put out fires in his free time. He loves Rancher so much that he can’t contain himself.