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 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 permissions on a fine grained basis to everything within a Kubernetes Cluster. It offers additional security in Kubernetes and allows configuration of flexible authorization policies that can be updated without cluster restarts. Before we look at the features of RBAC in depth, let's have a 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
The following Request Attributes can be used during authorization:
• 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 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.|
|User has to restart the cluster API server to change permissions.||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.|
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 comes in two flavours:
- 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 example of how to define roles and their bindings:
The following example shows Role that allows read on all pods in the default namespace.
- apiGroups: [""] # "" indicates the core API group
verbs: ["get", "watch", "list"]
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: User
The following example shows that Cluster Role grants access to all secrets.
# "namespace" omitted since ClusterRoles are not namespaced
- apiGroups: [""]
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.
namespace: development # This only grants permissions within the "development"
- kind: User
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: Group
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.