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