RBAC of Kubernetes
1, Introduction to RBAC
In Kubernetes, there are six authorization modes: ABAC (attribute based access control), RBAC (role-based access control), Webhook, Node, AlwaysDeny (always denied) and AlwaysAllow (always allowed). From version 1.6, Kubernetes enables RBAC access control policy by default. Since 1.8, RBAC has been used as a stable function. Enable RABC by setting – authorization mode = RBAC. In RABC API, authorization is carried out through the following steps: 1) define role: when defining a role, the rules for resource access control of this role will be specified; 2) Bind role: bind the principal to the role to authorize the user's access.
1.1 roles and cluster roles
In the RBAC API, roles contain rules that represent permission sets. Here, permissions are only granted, not denied. In Kubernetes, there are two types of roles, ordinary roles and cluster roles. Roles in a namespace can be defined by Role, or cluster wide roles can be defined by ClusterRole. A Role can only be used to grant access to resources in a single command space.
The cluster role can be granted permissions to the following resources:
Cluster wide resources (similar to nodes)
Non resource endpoint (similar to "/ healthz")
Resources of all namespaces in the cluster (like Pod)
1.2 role binding and cluster role binding
Role binding is used to bind roles to one or a group of users, so as to achieve the purpose of authorizing users. Principals are divided into users, groups, and service accounts. Role binding can also be divided into role binding, ordinary role binding and cluster role binding. Role binding can only refer to roles under the same namespace.
Role binding can also grant access permissions by referring to cluster roles. When the principal's access to resources is limited to this namespace, it allows the administrator to define the public role collection of the whole cluster and reuse it in multiple namespaces.
Cluster roles can be used to authorize at the cluster level and throughout the namespace
1.3 resources
In Kubernets, the main resources include Pods, Nodes, Services, Deployment, replicates, Statefulsets, namespaces, Persistents, Secrets and ConfigMaps. In addition, there are sub resources under some resources. For example, log sub resources exist under Pod
1.4 main body
The principal in RBAC authorization can be a group, user or service account. The user is represented by a string, such as "alice"“ bob@example.com ”The specific form depends on the user name configured by the administrator in the authentication module. System: is reserved for use as a Kubernetes system, so it cannot be used as a prefix for users. The group is also provided by the authentication module, and the format is similar to that of the user.
2, RBAC actual combat
2.1 creating users
(umask 077; openssl genrsa -out baison.key 2048) //Create user certificate key openssl req -new -key baison.key -out baison.csr -subj "/O=group/CN=chenteng" //Create a user certificate request, -subj specify the group and user, where O is the group name and CN is the user name openssl x509 -req -in baison.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out baison.crt -days 3650 //Issuing user certificates using k8s's ca kubectl config set-credentials chenteng --client-certificate=baison.crt --client-key=baison.key --embed-certs=true //User configuration kubectl config set-context baison@kubernetes --cluster=kubernetes --user=chenteng //context settings You can switch to a new user, but the user does not have any permissions at this time kubectl config use-context chenteng@kubernetes
2.2 view all users and context
[root@master ~]# kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
chenteng@kubernetes kubernetes chenteng
* kubernetes-admin@kubernetes kubernetes kubernetes-admin default
[root@master ~]# kubectl config get-users
NAME
chenteng
kubernetes-admin
2.3 creating rule s
First, take a look at the yaml file format of rule
kubectl create role pod-rule --verb=get,list,watch --resource=pods --dry-run -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: pods-reader rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch
Rules are not ns restricted after using files or commands
[root@master rule]# kubectl get role NAME CREATED AT leader-locking-nfs-provisioner 2021-08-29T11:15:24Z pod-rule 2021-10-02T10:03:51Z
2.4 creating RoleBinding
Create with command
[root@master rule]# kubectl create rolebinding pod-rule-binding --role=pod-rule --user=chenteng -n default rolebinding.rbac.authorization.k8s.io/pod-rule-binding created [root@master rule]# kubectl get rolebinding NAME ROLE AGE leader-locking-nfs-provisioner Role/leader-locking-nfs-provisioner 33d pod-rule-binding Role/pod-rule 8s role ClusterRole/admin 56m
3, Verification operation
Switch to chenteng user
[root@master rule]# kubectl config use-context chenteng@kubernetes Switched to context "chenteng@kubernetes". [root@master rule]# kubectl get pod NAME READY STATUS RESTARTS AGE nfs-provisioner-7d557769cd-dkb28 1/1 Running 4 33d nginx-v3-79dd7b64d8-l6kkc 1/1 Running 0 74m redis-6468bf6c84-qd66k 1/2 ImagePullBackOff 0 132m [root@master rule]# kubectl get pod -nkube-system Error from server (Forbidden): pods is forbidden: User "chenteng" cannot list resource "pods" in API group "" in the namespace "kube-system"
Conclusion: we can see that when our users bind the rolebindings under the default namespace, they have a series of permissions defined by the previous role.
Attention
- Role is not restricted by namespace. RoleBinding is restricted by namespace!
- When using create to create RoleBinding, - n specify the namespace to control which ns permissions are available