文章
文章用户文档快讯圈子网址导航

Kubernetes之（十五）身份认证，授权，准入控制

释放双眼，带上耳机，听听看~！

目录

  • Kubernetes之（十五）身份认证，授权，准入控制

  • ServiceAccount

  • 创建serviceaccount
    * 自定义serviceaccount
    * 自建证书和账号进行访问apiserver

    • RBAC简介

  • Kubernetes RBAC演示
    * RBAC的三种授权访问

Kubernetes之（十五）身份认证，授权，准入控制

API Server作为Kubernetes网关，是访问和管理资源对象的唯一入口，其各种集群组件访问资源都需要经过网关才能进行正常访问和管理。每一次的访问请求都需要进行合法性的检验，其中包括身份验证、操作权限验证以及操作规范验证等，需要通过一系列验证通过之后才能访问或者存储数据到etcd当中。如下图：

ServiceAccount

Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的。它与User account不同:

  • User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API而设计

  • User account是跨namespace的，而service account则是仅局限它所在的namespace

  • 每个namespace都会自动创建一个default service account

  • Token controller检测service account的创建，并为它们创建secret

  • 开启ServiceAccount Admission Controller后

  • 每个Pod在创建后都会自动设置spec.serviceAccount为default（除非指定了其他ServiceAccout）

    • 验证Pod引用的service account已经存在，否则拒绝创建
    • 如果Pod没有指定ImagePullSecrets，则把service account的ImagePullSecrets加到Pod中
    • 每个container启动后都会挂载该service account的token和ca.crt到/var/run/secrets/kubernetes.io/serviceaccount/

当创建 pod 的时候，如果没有指定一个 service account，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。而pod和apiserver之间进行通信的账号，称为serviceAccountName。如下:



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
1[root@master manifests]# kubectl get pods

2NAME      READY   STATUS    RESTARTS   AGE

3myapp-0   1/1     Running   0          16h

4myapp-1   1/1     Running   0          16h

5myapp-2   1/1     Running   0          16h

6myapp-3   1/1     Running   0          16h

7[root@master manifests]# kubectl get pods myapp-0 -o yaml|grep serviceAccountName

8  serviceAccountName: default

9

10[root@master manifests]# kubectl describe pods myapp-0

11......

12  default-token-dqd2f:

13    Type:        Secret (a volume populated by a Secret)

14    SecretName:  default-token-dqd2f

15......

16

每个Pod无论定义与否都会有个存储卷，这个存储卷为default-token-*** token令牌，这就是pod和serviceaccount认证信息。通过secret进行定义，由于认证信息属于敏感信息，所以需要保存在secret资源当中，并以存储卷的方式挂载到Pod当中。从而让Pod内运行的应用通过对应的secret中的信息来连接apiserver，并完成认证。每个 namespace 中都有一个默认的叫做 default 的 service account 资源。进行查看名称空间内的secret，也可以看到对应的default-token。让当前名称空间中所有的pod在连接apiserver时可以使用的预制认证信息，从而保证pod之间的通信。



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1[root@master manifests]# kubectl get sa

2NAME      SECRETS   AGE

3default   1         7d21h

4[root@master manifests]# kubectl get sa -n ingress-nginx  #所有的名称空间都存在name是default的serviceAccount

5NAME                           SECRETS   AGE

6default                        1         2d20h

7nginx-ingress-serviceaccount   1         2d5h

8

9[root@master manifests]# kubectl get secret

10NAME                    TYPE                                  DATA   AGE

11default-token-dqd2f     kubernetes.io/service-account-token   3      7d21h

12mysql-root-password     Opaque                                1      23h

13tomcat-ingress-secret   kubernetes.io/tls                     2      2d3h

14[root@master manifests]# kubectl get secret -n ingress-nginx

15NAME                                       TYPE                                  DATA   AGE

16default-token-fkw6s                        kubernetes.io/service-account-token   3      2d20h

17nginx-ingress-serviceaccount-token-jvlq9   kubernetes.io/service-account-token   3      2d5h

18

默认的service account 仅仅只能获取当前Pod自身的相关属性，无法观察到其他名称空间Pod的相关属性信息。如果想要扩展Pod，假设有一个Pod需要用于管理其他Pod或者是其他资源对象，是无法通过自身的名称空间的serviceaccount进行获取其他Pod的相关属性信息的，此时就需要进行手动创建一个serviceaccount，并在创建Pod时进行定义。那么serviceaccount该如何进行定义呢？？？实际上，service accout也属于一个kubernetes资源，如下查看service account的定义方式：



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1[root@master ~]# kubectl explain sa.

2KIND:     ServiceAccount

3VERSION:  v1

4

5FIELDS:

6   apiVersion   <string>

7

8   imagePullSecrets     <[]Object>

9

10   kind <string>

11

12   metadata     <Object>

13   

14   secrets      <[]Object>

15

创建serviceaccount



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1[root@master manifests]# kubectl create serviceaccount mysa -o yaml --dry-run #干跑模式，类似ansible的-C检查语法

2apiVersion: v1

3kind: ServiceAccount

4metadata:

5  creationTimestamp: null

6  name: mysa

7

8[root@master manifests]# kubectl create serviceaccount mysa -o yaml --dry-run > serviceaccount.yaml #保存为yaml文件，

9[root@master manifests]# cat serviceaccount.yaml

10apiVersion: v1

11kind: ServiceAccount

12metadata:

13  creationTimestamp: null

14  name: mysa

15  

16[root@master manifests]# kubectl get sa mysa -o yaml

17apiVersion: v1

18kind: ServiceAccount

19metadata:

20  annotations:

21    kubectl.kubernetes.io/last-applied-configuration: |

22      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"creationTimestamp":null,"name":"mysa","namespace":"default"}}

23  creationTimestamp: "2019-04-04T06:23:58Z"

24  name: mysa

25  namespace: default

26  resourceVersion: "273220"

27  selfLink: /api/v1/namespaces/default/serviceaccounts/mysa

28  uid: 3ab9e525-56a2-11e9-80a7-000c295ec349

29secrets:

30- name: mysa-token-cxlvc

31

看到有一个 token 已经被自动创建，并被 service account 引用。设置非默认的 service account，只需要在 pod 的spec.serviceAccountName 字段中将name设置为您想要用的 service account 名字即可。在 pod 创建之初 service account 就必须已经存在，否则创建将被拒绝。需要注意的是不能更新已创建的 pod 的 service account。

自定义serviceaccount

在default名称空间创建了一个sa为admin



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1[root@master manifests]# kubectl create sa admin

2serviceaccount/admin created

3[root@master manifests]# kubectl get sa

4NAME      SECRETS   AGE

5admin     1         40s

6default   1         7d22h

7[root@master manifests]# kubectl describe sa admin

8Name:                admin

9Namespace:           default

10Labels:              <none>

11Annotations:         <none>

12Image pull secrets:  <none>

13Mountable secrets:   admin-token-sswgb

14Tokens:              admin-token-sswgb

15Events:              <none>

16

17[root@master manifests]# kubectl get secret

18NAME                    TYPE                                  DATA   AGE

19admin-token-sswgb       kubernetes.io/service-account-token   3      99s

20default-token-dqd2f     kubernetes.io/service-account-token   3      7d22h

21mysql-root-password     Opaque                                1      23h

22tomcat-ingress-secret   kubernetes.io/tls                     2      2d4h

23

可以看到已经自动生成了一个 Tokens: admin-token-sswgb



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1[root@master manifests]#  vim pod-sa-demo.yaml #新建pod引用 Tokens: admin-token-sswgb

2apiVersion: v1

3kind: Pod

4metadata:

5  name: pod-sa-demo

6  namespace: default

7  labels:

8    app: myapp

9    tier: frontend

10  annotations:

11    white.com/created-by: "cluster admin"

12spec:

13  containers:

14  - name: myapp

15    image: ikubernetes/myapp:v1

16    ports:

17    - name: http

18      containerPort: 80

19  serviceAccountName: admin  #引用刚才创建的sa账户

20

创建并查看



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1[root@master manifests]# kubectl apply -f pod-sa-demo.yaml 

2pod/pod-sa-demo created

3[root@master manifests]# kubectl get pods

4NAME          READY   STATUS    RESTARTS   AGE

5myapp-0       1/1     Running   0          21h

6myapp-1       1/1     Running   0          21h

7myapp-2       1/1     Running   0          21h

8myapp-3       1/1     Running   0          21h

9pod-sa-demo   1/1     Running   0          2s

10

11

12[root@master manifests]# kubectl describe pods pod-sa-demo 

13......

14Volumes:

15  admin-token-sswgb:  #已经使用藏才创建的admin账户的token

16    Type:        Secret (a volume populated by a Secret)

17    SecretName:  admin-token-sswgb

18    Optional:    false

19QoS Class:       BestEffort

20......

21

在K8S集群当中，每一个用户对资源的访问都是需要通过apiserver进行通信认证才能进行访问的，那么在此机制当中，对资源的访问可以是token，也可以是通过配置文件的方式进行保存和使用认证信息，可以通过kubectl config进行查看配置，如下：



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1[root@master manifests]# kubectl config view

2apiVersion: v1

3clusters:    #集群状态

4- cluster:

5    certificate-authority-data: DATA+OMITTED

6    server: https://10.0.0.10:6443

7  name: kubernetes

8contexts:  #上下文列表

9- context:    #集群和访问用户的映射

10    cluster: kubernetes

11    user: kubernetes-admin

12  name: kubernetes-admin@kubernetes

13current-context: kubernetes-admin@kubernetes   #当前上下文

14kind: Config

15preferences: {}

16users:   #用户列表

17- name: kubernetes-admin

18  user:

19    client-certificate-data: REDACTED

20    client-key-data: REDACTED

21

在上面的配置文件当中，定义了集群、上下文以及用户。其中Config也是K8S的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。如图：定义了用户kubernetes-admin可以对kubernetes该集群的访问，用户kubernetes-user1对Clluster1集群的访问。
（图片来源：https://www.cnblogs.com/linuxk/）

自建证书和账号进行访问apiserver

生成证书



1
2
3
4
5
6
7
8
9
1[root@master manifests]# cd /etc/kubernetes/pki/

2[root@master pki]# (umask 077;openssl genrsa -out white.key 2048)

3Generating RSA private key, 2048 bit long modulus

4..........................................................+++

5................................+++

6e is 65537 (0x10001)

7[root@master pki]# ls -l white.key 

8-rw------- 1 root root 1679 4月   4 14:49 white.key

9

使用ca.crt 签署证书



1
2
3
4
5
6
7
8
9
10
11
1[root@master pki]# openssl req -new -key white.key -out white.csr -subj "/CN=white" # 证书签署请求

2

3[root@master pki]# openssl x509 -req -in white.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out white.crt  -days 365 #证书签署

4Signature ok

5subject=/CN=white

6Getting CA Private Key

7

8[root@master pki]#  openssl x509 -in white.crt -text -noout

9[root@master pki]# kubectl config set-credentials  white --client-certificate=./white.crt --client-key=./white.key --embed-certs=true

10User "white" set.

11

添加到用户认证



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
1[root@master pki]# kubectl config set-context white@kubernetes --cluster=kubernetes --user=white

2Context "white@kubernetes" created.

3

4[root@master pki]# kubectl config view

5apiVersion: v1

6clusters:

7- cluster:

8    certificate-authority-data: DATA+OMITTED

9    server: https://10.0.0.10:6443

10  name: kubernetes

11contexts:

12- context:

13    cluster: kubernetes

14    user: kubernetes-admin

15  name: kubernetes-admin@kubernetes

16- context:

17    cluster: kubernetes

18    user: white

19  name: white@kubernetes

20current-context: kubernetes-admin@kubernetes

21kind: Config

22preferences: {}

23users:

24- name: kubernetes-admin

25  user:

26    client-certificate-data: REDACTED

27    client-key-data: REDACTED

28

切换账号



1
2
3
4
5
1[root@master pki]# kubectl config use-context white@kubernetes

2Switched to context "white@kubernetes".

3[root@master pki]# kubectl get pods

4Error from server (Forbidden): pods is forbidden: User "system:anonymous" cannot list resource "pods" in API group "" in the namespace "default"

5

当切换成magedu用户进行访问集群时，由于magedu该账户没有管理集群的权限，所以在获取pods资源信息时，会提示Forrbidden。那么下面就再来了解一下怎么对账户进行授权.

RBAC简介

Kubernetes的授权是基于插件形式的，其常用的授权插件有以下几种：

  • Node（节点认证）
  • ABAC(基于属性的访问控制)
  • RBAC（基于角色的访问控制）
  • Webhook（基于http回调机制的访问控制）

让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。如图：
基于角色的访问控制（Role-Based Access Control, 即RBAC）使用”rbac.authorization.k8s.io” API Group实现授权决策，允许管理员通过Kubernetes API动态配置策略。

在k8s的授权机制当中，采用RBAC的方式进行授权，其工作逻辑是　　把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。此种方式仅作用于名称空间当中，这是什么意思呢？当User1绑定到Role角色当中，User1就获取了对该NamespaceA的操作权限，但是对NamespaceB是没有权限进行操作的，如get，list等操作。
另外，k8s为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将User2，User3通过ClusterRoleBinding到ClusterRole，从而使User2、User3拥有集群的操作权限。Role、RoleBinding、ClusterRole和ClusterRoleBinding的关系如下图:

这里有2种绑定ClusterRoleBinding、RoleBinding。也可以使用RoleBinding去绑定ClusterRole。
当使用这种方式进行绑定时，用户仅能获取当前名称空间的所有权限。为什么这么绕呢？？举例有10个名称空间，每个名称空间都需要一个管理员，而该管理员的权限都是一致的。那么此时需要去定义这样的管理员，使用RoleBinding就需要创建10个Role，这样显得更加繁重。为此当使用RoleBinding去绑定一个ClusterRole时，该User仅仅拥有对当前名称空间的集群操作权限，换句话说，此时只需要创建一个ClusterRole就解决了以上的需求。

注意：RoleBinding仅仅对当前名称空间有对应的权限。

在RBAC API中，一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 角色可以由命名空间（namespace）内的Role对象定义，而整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。

Kubernetes RBAC演示

1、User –> Rolebinding –> Role
创建角色 一个Role对象只能用于授予对某一单一命名空间中资源的访问权限
语法：



1
2
3
4
1Usage:

2  kubectl create role NAME --verb=verb --resource=resource.group/subresource

3[--resource-name=resourcename] [--dry-run] [options]

4

–verb指定权限，–resource指定资源或者资源组，–dry-run单跑模式并不会创建



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
1[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml #干跑查看定义格式

2apiVersion: rbac.authorization.k8s.io/v1

3kind: Role    #资源类型

4metadata:

5  creationTimestamp: null

6  name: pods-reader

7rules:

8- apiGroups:    #目标api群组

9  - ""

10  resources:   #目标资源

11  - pods

12  verbs:     #操作权限

13  - get

14  - list

15  - watch

16  

17[root@master manifests]# kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yaml > role-demo.yaml

18

19[root@master manifests]# vim role-demo.yaml

20apiVersion: rbac.authorization.k8s.io/v1

21kind: Role

22metadata:

23  name: pods-reader

24  namespace: default

25rules:

26- apiGroups:

27  - ""

28  resources:

29  - pods

30  verbs:

31  - get

32  - list

33  - watch

34

35#创建用户并查看

36[root@master manifests]# kubectl apply -f role-demo.yaml 

37role.rbac.authorization.k8s.io/pods-reader created

38[root@master manifests]# kubectl get role

39NAME          AGE

40pods-reader   5s

41[root@master manifests]# kubectl describe role pods-reader

42Name:         pods-reader

43Labels:       <none>

44Annotations:  kubectl.kubernetes.io/last-applied-configuration:

45                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pods-reader","namespace":"default"},"rules...

46PolicyRule:

47  Resources  Non-Resource URLs  Resource Names  Verbs

48  ---------  -----------------  --------------  -----

49  pods       []                 []              [get list watch]    #此处已经定义了pods-reader这个角色对pods资源拥有get、list、watch的权限

50

51

角色绑定 RoleBinding可以引用在同一命名空间内定义的Role对象。

语法



1
2
3
4
1Usage:

2  kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username]

3[--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run] [options]

4

–role|–clusterrole指定绑定哪个角色，–user指定哪个用户



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
1[root@master manifests]# kubectl create rolebinding white-read-pod --role=pods-reader --user=white --dry-run -o yaml>rolebinding-demo.yaml

2

3[root@master manifests]# vim rolebinding-demo.yaml

4apiVersion: rbac.authorization.k8s.io/v1

5kind: RoleBinding

6metadata:

7  name: white-read-pod

8roleRef:

9  apiGroup: rbac.authorization.k8s.io

10  kind: Role

11  name: pods-reader

12subjects:

13- apiGroup: rbac.authorization.k8s.io

14  kind: User

15  name: white

16

17

18[root@master manifests]# kubectl apply -f rolebinding-demo.yaml    #创建角色绑定

19rolebinding.rbac.authorization.k8s.io/white-read-pod created

20[root@master manifests]# kubectl describe rolebinding white-read-pod

21Name:         white-read-pod

22Labels:       <none>

23Annotations:  kubectl.kubernetes.io/last-applied-configuration:

24                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"creationTimestamp":null,"name":"white-read...

25Role:

26  Kind:  Role

27  Name:  pods-reader

28Subjects:

29  Kind  Name   Namespace

30  ----  ----   ---------

31  User  white      #查看角色绑定的信息，这里可以看到user：white绑定到了pods-reader这个角色上

32

33[root@master manifests]# kubectl config use-context white@kubernetes #切换white这个用户，并使用get获取pods资源信息

34Switched to context "white@kubernetes".

35[root@master manifests]# kubectl get pods

36NAME          READY   STATUS    RESTARTS   AGE

37myapp-0       1/1     Running   0          4d18h

38myapp-1       1/1     Running   0          4d18h

39myapp-2       1/1     Running   0          4d18h

40myapp-3       1/1     Running   0          4d18h

41pod-sa-demo   1/1     Running   0          3d21h

42

从上面的操作，可以总结出，role的定义和绑定，仅作用于当前名称空间，在获取ingress-nginx名称空间时，一样会出现Forbidden！！！



1
2
3
4
5
1[root@master manifests]# kubectl get pods -n ingress-nginx

2Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"

3[root@master manifests]# kubectl get pods -n kube-system

4Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"

5

2、User –> Clusterrolebinding –> Clusterrole
clusterrole定义
ClusterRole对象可以授予与Role对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限：

  • 集群范围资源（例如节点，即node）

  • 非资源类型endpoint（例如”/healthz”）

  • 跨所有命名空间的命名空间范围资源（例如pod，需要运行命令kubectl get pods –all-namespaces来查询集群中所有的pod）



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1[root@master manifests]# kubectl config use-context kubernetes-admin@kubernetes

2Switched to context "kubernetes-admin@kubernetes".

3

4[root@master manifests]# kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods -o yaml --dry-run >clusterrole-demo.yaml

5apiVersion: rbac.authorization.k8s.io/v1

6kind: ClusterRole

7metadata:

8  name: cluster-reader

9rules:

10- apiGroups:

11  - ""

12  resources:

13  - pods

14  verbs:

15  - get

16  - list

17  - watch

18

19[root@master manifests]# kubectl apply -f clusterrole-demo.yaml 

20clusterrole.rbac.authorization.k8s.io/cluster-reader created

21

这里我们需要切换回kubernetes-admin账户，是由于white账户不具备创建的权限，这也说明普通用户是无法进行创建K8S资源的，除非进行授权。如下，我们另开一个终端，将配置到一个普通用户ik8s上，使其使用white账户进行通信



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
1[root@master manifests]# useradd ik8s

2[root@master manifests]# cp -rp ~/.kube/ /home/ik8s/

3[root@master manifests]# chown -R ik8s.ik8s /home/ik8s/

4[root@master manifests]# su - ik8s

5[ik8s@master ~]$ kubectl config view 

6apiVersion: v1

7clusters:

8- cluster:

9    certificate-authority-data: DATA+OMITTED

10    server: https://10.0.0.10:6443

11  name: kubernetes

12contexts:

13- context:

14    cluster: kubernetes

15    user: kubernetes-admin

16  name: kubernetes-admin@kubernetes

17- context:

18    cluster: kubernetes

19    user: white

20  name: white@kubernetes

21- context:

22    cluster: ""

23    user: ""

24  name: xiaomi

25current-context: white@kubernetes

26kind: Config

27preferences: {}

28users:

29- name: kubernetes-admin

30  user:

31    client-certificate-data: REDACTED

32    client-key-data: REDACTED

33- name: white

34  user:

35    client-certificate-data: REDACTED

36    client-key-data: REDACTED

37

clusterrolebinding定义



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
1#清理原有的rolebinding

2[root@master manifests]# kubectl get rolebinding

3NAME              AGE

4white-read-pods   22m

5[root@master manifests]# kubectl delete rolebinding white-read-pods 

6rolebinding.rbac.authorization.k8s.io "white-read-pods" deleted

7

8#删除后，在ik8s普通用户上进行获取pods资源信息，就立马出现forbidden了

9

10[ik8s@master ~]$ kubectl get pods

11Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "default"

12

13#创建clusterrolebinding

14[root@master manifests]# kubectl create clusterrolebinding white-read-all-pods  --clusterrole=cluster-reader --user=white --dry-run -o yaml >clusterrolebinding-demo.yaml

15[root@master manifests]# vim clusterrolebinding-demo.yaml

16apiVersion: rbac.authorization.k8s.io/v1beta1

17kind: ClusterRoleBinding

18metadata:

19  name: white-read-all-pods

20roleRef:

21  apiGroup: rbac.authorization.k8s.io

22  kind: ClusterRole

23  name: cluster-reader

24subjects:

25- apiGroup: rbac.authorization.k8s.io

26  kind: User

27  name: white

28  

29

30[root@master manifests]# kubectl apply -f clusterrolebinding-demo.yaml

31clusterrolebinding.rbac.authorization.k8s.io/white-read-all-pods created

32[root@master manifests]# kubectl get clusterrolebinding|grep white

33white-read-all-pods  

34[root@master manifests]# kubectl describe clusterrolebinding white-read-all-pods

35Name:         white-read-all-pods

36Labels:       <none>

37Annotations:  kubectl.kubernetes.io/last-applied-configuration:

38                {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"white-read-all-pods"},"...

39Role:

40  Kind:  ClusterRole

41  Name:  cluster-reader

42Subjects:

43  Kind  Name   Namespace

44  ----  ----   ---------

45  User  white  

46

角色绑定后在ik8s终端上进行获取pods信息，已经不会出现forbidden了



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1[ik8s@master ~]$ kubectl get pods   

2NAME          READY   STATUS    RESTARTS   AGE

3myapp-0       1/1     Running   0          4d18h

4myapp-1       1/1     Running   0          4d18h

5myapp-2       1/1     Running   0          4d18h

6myapp-3       1/1     Running   0          4d18h

7pod-sa-demo   1/1     Running   0          3d21h

8[ik8s@master ~]$ kubectl get pods -n kube-system

9NAME                             READY   STATUS    RESTARTS   AGE

10coredns-78d4cf999f-6cb69         1/1     Running   0          11d

11coredns-78d4cf999f-tflpn         1/1     Running   0          11d

12etcd-master                      1/1     Running   0          11d

13kube-apiserver-master            1/1     Running   0          11d

14kube-controller-manager-master   1/1     Running   0          11d

15kube-flannel-ds-amd64-gtv85      1/1     Running   0          11d

16kube-flannel-ds-amd64-gwbql      1/1     Running   1          11d

17kube-flannel-ds-amd64-ml7nf      1/1     Running   0          11d

18kube-proxy-ch4vp                 1/1     Running   0          11d

19kube-proxy-cz2rf                 1/1     Running   1          11d

20kube-proxy-kdp7d                 1/1     Running   0          11d

21kube-scheduler-master            1/1     Running   0          11d

22

但是进行删除pod就无法进行，因为在授权时是没有delete权限的



1
2
3
1[ik8s@master ~]$ kubectl delete pods myapp-0

2Error from server (Forbidden): pods "myapp-0" is forbidden: User "white" cannot delete resource "pods" in API group "" in the namespace "default"

3

从上面的实验，我们可以知道对用户white进行集群角色绑定，用户white将会获取对集群内所有资源的对应权限。
3、User –> Rolebinding –> Clusterrole
将white通过rolebinding到集群角色white-read-pods当中，此时，white仅作用于当前名称空间的所有pods资源的权限



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1[root@master manifests]# kubectl delete clusterrolebinding white-read-all-pods

2clusterrolebinding.rbac.authorization.k8s.io "white-read-all-pods" deleted

3

4[root@master manifests]# kubectl create rolebinding white-read-pods --clusterrole=cluster-reader --user=white --dry-run -oyaml >rolebinding-clusterrole-demo.yaml

5

6[root@master manifests]# vim rolebinding-clusterrole-demo.yaml

7apiVersion: rbac.authorization.k8s.io/v1

8kind: RoleBinding

9metadata:

10  name: white-read-pods

11roleRef:

12  apiGroup: rbac.authorization.k8s.io

13  kind: ClusterRole

14  name: cluster-reader

15subjects:

16- apiGroup: rbac.authorization.k8s.io

17  kind: User

18  name: white

19

20

21[root@master manifests]# kubectl apply -f rolebinding-clusterrole-demo.yaml 

22rolebinding.rbac.authorization.k8s.io/white-read-pods created

23

24[ik8s@master ~]$  kubectl get pods

25NAME          READY   STATUS    RESTARTS   AGE

26myapp-0       1/1     Running   0          4d18h

27myapp-1       1/1     Running   0          4d18h

28myapp-2       1/1     Running   0          4d18h

29myapp-3       1/1     Running   0          4d18h

30pod-sa-demo   1/1     Running   0          3d21h

31[ik8s@master ~]$  kubectl get pods -n ingress-nginx

32Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "ingress-nginx"

33[ik8s@master ~]$  kubectl get pods -n kube-system

34Error from server (Forbidden): pods is forbidden: User "white" cannot list resource "pods" in API group "" in the namespace "kube-system"

35[ik8s@master ~]$ 

36

RBAC的三种授权访问

BAC不仅仅可以对user进行访问权限的控制，还可以通过group和serviceaccount进行访问权限控制。当我们想对一组用户进行权限分配时，即可将这一组用户归并到一个组内，从而通过对group进行访问权限的分配，达到访问权限控制的效果。

从前面serviceaccount我们可以了解到，Pod可以通过 spec.serviceAccountName来定义其是以某个serviceaccount的身份进行运行，当我们通过RBAC对serviceaccount进行访问授权时，即可以实现Pod对其他资源的访问权限进行控制。也就是说，当我们对serviceaccount进行rolebinding或clusterrolebinding，会使创建Pod拥有对应角色的权限和apiserver进行通信。如图：

Related posts:

  1. Kubernetes之（二十）Helm程序包管理器
  2. Kubernetes入门
  3. 带你玩转kubernetes-k8s（第39篇：深入分析集群安全机制二[RBAC授权模式]）
  4. Kubernetes之（十九）资源指标和集群监控

给TA打赏
共{{data.count}}人
人已打赏
[db:标签]dnskube-proxyKuberneteslinuxmysql命令敏感信息数据系统
安全运维

故障复盘的简洁框架-黄金三问

2021-9-30 19:18:23

安全运维

OpenSSH-8.7p1离线升级修复安全漏洞

2021-10-23 10:13:25

猜你喜欢

Kubernetes入门

029
❯

解锁会员权限

开通会员

解锁海量优质VIP资源

立刻开通
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索

  • 扫码打开当前页

返回顶部