Secure your Kubernetes clusters with RBAC

May 25, 2017 0 47
Share
Secure your Kubernetes clusters with RBAC

Introduction:

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

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.
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.

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 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

Secure-Your-Kubernetes-Clusters-With-RBAC

Let’s have a look at a few example of how to define roles and their bindings:

Role:

The following example shows Role that allows read 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.

Tags
Leave Comment

Your email address will not be published.

Stay up to date with the latest and the best from the world of automation!