Kubernetes Authorization and RBAC

Authorization Modes

appfleet team
appfleet
3 min readApr 2, 2020

--

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:

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

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:

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:

Using can-i Argument to Test Role Binding

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

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.

--

--

appfleet team
appfleet

appfleet is a cloud platform offering edge compute for containers and web applications.