Kubernetes Authorization and RBAC

In this article

Kubernetes Authorization and RBAC

Authorization Modes

Kubernetes supports the following authorization modes:

  • Attribute-Based Access Control: An authorizer through which access rights are granted to users through policies combining attributes (resources attributes, user attributes, objects, etc.)
  • Node Authorization: A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run on.
  • Webhook: A webhook is a HTTP callback – a HTTP POST that occurs when something happens. This mode allows for integration with Kubernetes external authorizers.
  • Role-Based Access Control: A method of regulating access to computer or network resources based on the roles of individual users within an enterprise.

RBAC (Role-Based Access Control)

RBAC Concepts:

  • Entity: A user, group, or service account
  • Role: Used to define rules for actions on resources
  • Resource: A secret, pod or service that the entity may want to access
  • Role Binding: This attaches a role to an entity, thus determining a set of actions that are permitted for specified resources
  • Actions: That an entity may take on a resource are defined in the role. They are based on verbs supported by Kubernetes. Examples of verbs that may be specified in role definition are:

    a. get, list (read-only)

    b. create, update, patch, delete, deletecollection (read-write)

Types of Roles:

  • Cluster-wide: Cluster roles and their respective cluster role bindings
  • Namespace-wide: Roles and role binding within the context of a namespace

Default Roles:

  • User-Facing Roles: cluster-admin, admin (for namespaces), edit, and view, are defined out-of-the-box and available for use without defining any additional roles
  • Core Components: Kubernetes control-plane components and nodes have predefined roles, such as system:kube-controller-manager or system:node

You may use the following command to list the cluster roles on the cluster:

kubectl get clusterroles
kubectl get clusterroles <name-of-role> -o yaml
  • Other Components: Roles are also defined for other system components as needed by the installer. Flannel is one such example when the flannel network overlay is installed.

Using Describe to Interrogate a Role

Many roles are predefined on a cluster by the installers. It is helpful to use the describe command to view particulars:

kubectl describe clusterroles view

Creating a Service Account within a Namespace

To illustrate the use of Role-Binding, we will create a namespace, role, and bind it for a namespace-wide example:

kubectl create namespace dev-test
kubectl --namespace=dev-test create serviceaccount dev-test-account
kubectl --namespace=dev-test create role dev-tester-view --verb=get --verb=list --resource=pods
kubectl --namespace=dev-test describe role/dev-tester-view

kubectl --namespace=dev-test create rolebinding dev-viewer --role=dev-tester-view --serviceaccount=dev-test:dev-test-account
kubectl --namespace=dev-test describe rolebinding/dev-viewer

Creating a Role Binding within a Namespace

To illustrate the used of Role-Binding we will create a namespace, role, and bind it for a namespace-wide example:

kubectl --namespace=dev-test create rolebinding dev-viewer --role=dev-tester-view --serviceaccount=dev-test:dev-test-account
kubectl --namespace=dev-test describe rolebinding/dev-viewer

Using can-i Argument to Test Role Binding

To test the role binding example, we can use the can-i argument to verify permissions:

kubectl --namespace=dev-test auth can-i --as=system:serviceaccount:dev-test:dev-test-account list pods

kubectl --namespace=dev-test auth can-i --as=system:serviceaccount:dev-test:dev-test-account list services

Tooling to Help Ensure Best Practices

As the Kubernetes Eco-System expands, it is important to consider tooling to help maintain enterprise installations. The following is a list of tools to consider for Role Based Access Control (RBAC) use:

audit2rbac: A tool to automatically determine what permissions are necessary for certain applications, and can generate RBAC role binding for you

kube2iam: A tool that provides AWS IAM credentials to containers based on annotations

rbac-manager: A Kubernetes operator that simplifies the management of role bindings and service accounts

Closing Thoughts on Best Practices

RBAC has become the standard for Enterprise Kubernetes Authorization. Ensure that the kube-apiserver is started with the option --authorization-mode=RBAC.

Disable the default service token as most applications do not require access to the API. This can be done by setting automountServiceAccountToken:false in the pods spec for your applications. Use dedicated service account for any applications that require access to the API.

Subscribe and discover the newest
updates, news, and features

We value your inbox and are committed to preventing spam