Shulou(Shulou.com)06/01 Report--

This article will explain in detail how Kubernetes v1.6 supports RBAC. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

RBAC vs ABAC

At present, Kubernetes already supports a variety of authentication modes. The authenticator is a mechanism that determines whether users are allowed to make some changes to the cluster through Kubernetes API. This affects kubectl, system components, and some applications that run in the cluster and manipulate the cluster state, such as the Kubernetes plug-in for Jenkins, or Helm running in the cluster, which uses Kubernetes API to deploy applications in the cluster. Among the available authorization mechanisms, ABAC and RBAC are both local mechanisms of the Kubernetes cluster and can be configured for access policies.

ABAC, attribute-based access control (Attribute Based Access Control), is a powerful concept. However, in the implementation of Kubernetes, ABAC is difficult to manage and understand. To change the authorization policy, access to the ssh and root file system of the cluster master node is required. Moreover, the permission change will not take effect until the API server of the cluster is restarted.

The RBAC permission policy is configured through kubectl or directly using Kubernetes API. Users can be authorized through RBAC, so that resource management can be carried out without giving ssh access to the user cluster master. RBAC policies make it easy to map resources and operations used in Kubernetes API.

Based on the development efforts of the Kubernetes community, RBAC should replace ABAC in the future.

Basic concept

To understand RBAC, here are some basic ideas. At the core, RBAC is a way of authorizing users to access Kubernetes API resources at different granularities.

The connection between the user and the resource is defined using the following two objects of RBAC.

Role (Roles)

A role is a collection of permissions. For example, roles can be defined to include pod read permissions and list (list) permissions. ClusterRole (cluster role) is very similar to a role, but it can be used anywhere in the cluster.

Role binding (Role Bindings)

Role binding maps a role to a user or group of users, authorizing the role's permissions on resources in the namespace to those users. ClusterRoleBinding (Cluster role binding) allows authorized access of the authorized user ClusterRole throughout the cluster.

In addition, cluster roles and cluster role bindings need to be considered. The binding function of cluster role and cluster role is just like the binding of role and role, but has a wider range of use. For more information on the exact difference between cluster users, cluster user bindings and user-user bindings, please see Kubernetes doc.

RBAC in Kubernetes

RBAC is now deeply integrated into Kubernetes and used to license system components. System roles are prefixed with system, so they can be easily identified.

$kubectl get clusterroles-namespace=kube-systemNAME KINDadmin ClusterRole.v1beta1.rbac.authorization.k8s.iocluster-admin ClusterRole.v1beta1.rbac.authorization.k8s.ioedit ClusterRole.v1beta1.rbac.authorization.k8s.iokubelet-api-admin ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:auth-delegator ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:basic-user ClusterRole. V1beta1.rbac.authorization.k8s.iosystem:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io...

The system role of RBAC has been expanded to manage the permissions needed to run the Kubernetes cluster using only RBAC.

During the migration of permissions from ABAC to RBAC, some permissions that are enabled by default in ABAC-authorized deployment are identified as unnecessary in RBAC, and permissions are degraded in RBAC. The load that may affect the permissions of the service account. Under the ABAC configuration, using the pod mapping token to authorize API server's pod requests has high privileges. As a concrete example, the following curl command returns a correct result in JSON format when ABAC is enabled, and an error when only RBAC is enabled.

$kubectl run nginx-- image=nginx:latest$ kubectl exec-it $(kubectl get pods-o jsonpath=' {.items [0] .metadata.name}') bash$ apt-get update & & apt-get install-y curl$ curl-ik\-H "Authorization: Bearer $(cat / var/run/secrets/kubernetes.io/serviceaccount/token)"\ https://kubernetes/api/v1/namespaces/default/pods

During the migration from ABAC to RBAC, any application running in the Kubernetes cluster, as long as it interacts with Kubernetes API, may be affected by permission migration.

To make the ABAC-to-RBAC migration as smooth as possible, you can enable both ABAC and RBAC authorization when creating a Kubernetes v1.6 cluster. When both ABAC and RBAC are enabled, resource permissions are granted if either authorization policy grants access. However, in this configuration, it is given too lenient permissions and may not work in a full RBAC environment. For now, RBAC is fully adequate, and ABAC support should be considered deprecated in the future. It should still be stored in Kubernetes for the foreseeable future, but development is mainly focused on RBAC.

This is the end of this article on "how Kubernetes v1.6 supports RBAC". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.