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:

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.