Select the Gcore Platform

Gcore Edge Solutions
Go to Gcore Platform →
  • Edge Delivery (CDN)
  • DNS with failover
  • Virtual Machines
  • Bare Metal
  • Cloud Load Balancers
  • Managed Kubernetes
  • AI Infrastructure
  • Edge Security (DDOS+WAF)
  • FaaS
  • Streaming
  • Object Storage
  • ImageStack (Optimize and Resize)
  • Edge Compute (Coming soon)
Gcore Hosting
Go to Gcore Hosting →
  • VPS Hosting
  • Dedicated Servers
  • SSL Certificates


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 to a useful newsletter

Favorable offers and important news once a month. No spam.