kubernetes' RBAC October 2 study notes

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

  1. Role is not restricted by namespace. RoleBinding is restricted by namespace!
  2. When using create to create RoleBinding, - n specify the namespace to control which ns permissions are available

Tags: Kubernetes

Posted on Sat, 02 Oct 2021 17:50:12 -0400 by peeps