Secure your Kubernetes clusters with RBAC
Kubernetes is an open-source container orchestration tool to manage applications in a clustered environment. In its latest release (version 1.6), Kubernetes introduces new features such as DaemonSet, ETCD v3, scalability updates, advanced scheduling, and improvements to Kubeadm. In addition, the new RBAC authorizer is another interesting feature of Kubernetes 1.6. Within Kubernetes, authorization happens as a separate step from authentication. The authorization check compares the attributes of the request to the access policies. An API call must be allowed by at least one policy to succeed.
RBAC, which stands for Role-based access control, allows Kubernetes admins to apply for permissions on a fine-grained basis to everything within a Kubernetes Cluster. It offers additional security in Kubernetes and allows the configuration of flexible authorization policies that can be updated without cluster restarts. Before we look at the features of RBAC in-depth, let's look at how authorization is handled in Kubernetes.
Selecting an Authorization mode:
Kubernetes has the following implementations that can be selected via the flag --authorization mode when starting the API server.
• AlwaysDeny - Blocks all requests (used mainly during tests)
• AlwaysAllow - Allows all requests (used when you don’t need authorization)
• ABAC - Attribute-based access control, here access rules are user configured and made available to Kubernetes via a file
• Webhook - Allows you to use a custom or an external service for authorization that interacts via REST
• RBAC - Role-based access control, here access rules are stored in the Kubernetes API and can be predefined or user configured too
Request attributes:
The following Request Attributes can be used during authorization:
• user - The user-string the user was authenticated as
• group - List of group names the user is a member of
• extra - a map of arbitrary string keys provided by the authentication layer
• request path - URI of the request, useful to provide access to non-resource endpoints like /healthz or /api
• whether the request is for an API resource
- Resource Requests
- Get, list, create, update, patch, watch, proxy, redirect, delete, deletecollection
- RNon Resource Requests
- Get, post, put, delete
- Resource being accessed
- Sub resource being accessed
- Namespace of the object being accessed
- API Group being accessed
- Name of the resource being accessed
ABAC vs RBAC:
| ABAC | RBAC |
|---|---|
| ABAC is attribute-based access control. | RBAC is role-based access control. |
| Requires ssh and root file system on master VM to make authorization policy changes. | Does not require ssh access to make authorization policy changes. |
| The user has to restart the cluster API server to change permissions. | The user does not have to restart the cluster API server to change permissions. |
| It allows for a simple local-file-based user-configured authorization policy. | It allows for authorization to be driven by the Kubernetes API. |
RBAC:
Essentially, RBAC grants users granular access to Kubernetes API resources. RBAC uses two objects i.e., Roles and RoleBindings, that describe the permissions and connect users and appropriate resources.
- Roles - Roles are a collection of permissions. They are defined within a Namespace.
Roles come in two flavors:- Role - Grants access to resources within a selected namespace
- ClusterRole - Grants access to resources at a cluster level
- RoleBindings - The users or set of users are mapped to a role, granting permission to the users under the namespace of the Role.
Like Roles, these also come in 2 flavours:- RoleBinding - Used to bind a Role to users for access to resources within a namespace
- ClusterRoleBinding - Used to bind a Role to users for access to resources across the cluster
Let's have a look at a few examples of how to define roles and their bindings:
Role:
The following example shows a Role that allows reading on all pods in the default namespace.
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
Role binding:
In the following example, the RoleBinding grants the “pod-reader” role to the user ”jane” within the “default” namespace. This allows “jane” to read pods in the “default” namespace.
# This role binding allows "jane" to read pods in the "default" namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Cluster Role:
The following example shows that Cluster Role grants access to all secrets.
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]
In the following example, the RoleBinding refers to a ClusterRole “dave” (the subject); it can only read secrets in the “development ” namespace(i.e., The namespace of RoleBinding)
# This role binding allows "dave" to read secrets in the "development" namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets namespace: development # This only grants permissions within the "development" namespace. subjects: - kind: User name: dave apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding:
In the following examples, the ClusterRoleBinding allows any user in the group, in this case “manager,” to read secrets in any namespace.
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets-global subjects: - kind: Group name: manager apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Conclusion:
Kubernetes makes it very easy to get everything up and running, RBAC enables users to access these Kubernetes API resources. It also allows users to dynamically configure permissions for your cluster's users and define the kinds of resources with which they can interact.