你好赵伟

这个屌丝很懒，什么也没留下！

热门标签

安全认证、准入控制、RBAC_防火墙中准入和用户认证的区别

作者：你好赵伟 | 2024-02-10 01:19:15

踩

防火墙中准入和用户认证的区别

准入机制

Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部
各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计
的。Kubernetes 使用了`认证（Authentication）、鉴权（Authorization）、准入控制（Admission
Control）`三步来保证API Server的安全
1
2
3
4

Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证
Authorization（授权）：判断用户是否有权限对访问的资源执行特定的动作
Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

在这里插入图片描述

一、Authentication:认证

-HTTP Token认证：通过一个 Token 来识别合法用户 HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token

HTTP Header里放入 Token HTTP Base 认证：通过用户名+密码的方式认证用户名+：+密码用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码
最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式

1.https的认证

在这里插入图片描述

需要认证的节点

在这里插入图片描述

[root@k8s-master-01 ~]# cd .kube/
[root@k8s-master-01 .kube]# ll
总用量 8
drwxr-x--- 4 root root   35 12月  4 21:20 cache
-rw------- 1 root root 5565 12月  4 20:54 config
[root@k8s-master-01 .kube]# cat config 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1USXdOREV5TkRFME9Wb1hEVE14TVRJd01qRXlOREUwT1Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTSsrClBaaml6b1JIQ3I5TmpWQ3djNFJFZ2xQdUhaWDRlZFY4ZE1HZW4zRVdGTk5TcWFMbWsyQzhNc080elpFZ0dSdCsKcDU4cUcvUzZDUS9aVDRNY1JmMnNVT2s1Ykk1c1VBak43RHpCS2hnd2VHd3lZWE0vMW10a3lxN1M3eXI3dHdBcQo2OTk0bGIrTXNwVEliTnNxTW5FemFzOFkzSGZNZ2c0OTR5bWpHUVBmRzJqcHkycU9UZ1JMcWF2ZzZMWHh5aTd2CmFJRWZCcGxpSU5XMFkyK0J3cGc1UDF3aXZGNUxueElzakZacnllTVl3ZTBpeS9qeGtPMkpCUitSbEkzK0F4Q3QKZTlWWTdSVFhLZEM5NGd4NGVtaEl1bkNESWUxWGdGTG16MXZqcFU2Zm9aQkYyeG1ENHVtdzltMFcwV3BsdzBuTwo4UGFuMERORmRmcWt6TVNEakZjQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZIeHlRYkR6cVpERmd1Q2JrRnV3ODVycUZxWFZNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFEQWYySU1qM3dKV2R5Wlo1Y213cHlFU2ljc2hkc3oxTlFkenZNZmJWRnErVGlFeEpjSApLR2M5SFpQSWp0Mm5IMGRveEFXNk9Id1NGSjZzWjR2YVJnYm1MTHhTMXNOVlUwUGtlMG9pSUNnZmlpb1pEaTYrCmhRUnBQSVUyV0dVRGY0U3F0dEdxbDFjRnkvMHRVeW9SZ01yQVZQU3hiVHFOYWt3ekFSbU1DcHlRSW8weFpnb3IKZ2RXNFVzS20rbE1wMGhJazBzd2RvRXZoV3VIRXNWVmdaOXdXNXYza1R4aStJRU4vcnU0QXRiL3BjcVd4VFJQSQplQllITzVmdnM2VXFiSTJXR3hyMkVtakIwTXo3M0t5STRSQkt2am4xS2R3MWcxMmpUZU5OeHIwc3JRcjJHdFpYCkFiT215YytJaU05K2drejhsV0U0MGEvc2toeXZTVVNFZ1BSUwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://192.168.15.31:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFekNDQWZ1Z0F3SUJBZ0lJQVUyZ1Q3N05UamN3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRFeU1EUXhNalF4TkRsYUZ3MHlNakV5TURReE1qUXhOVGhhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTFPSDlTWFNnYVh6bDVBdUcKT3FmRVdHdFZqVkVPTE1SNU05WlZmUXRPV0lqelBHb2dkUk1xWmQ3dzZORG9KQkhVUEppRHdWVk9yRlBoNzBRUQpORlovMTRWNnp2WUVFTlVrelZjRWp5YXFJNDVPZmRBS3F4azRZSXRMbXFJRFFXbW5JaytRVzNPbm9JWGRBQU5LCk14RVNCbVNtRldPY0FtQ3NUbm92dndGaXFKbUdpZkJuSGd3L3ptVHd6ZUhoRFI0OG9ET0hPbjZIOGxJTmxsVWEKYUJtZTFpRjcyN2dqVC9qN3RxSFlPTmQwcmdUWDdnYS96T01Wb0k2a1E1VlhNUmRmWFY1R21vY2ZzRmtqd3pvVgpGb05MdWFpU05wYUE4SllBQWJRNDBONkY1OVVicTF0OEM1TjljS1d5aGljNzBvRUN6WmQwSittT3dkUkI4YnArCnB4ZzBnUUlEQVFBQm8wZ3dSakFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0h3WURWUjBqQkJnd0ZvQVVmSEpCc1BPcGtNV0M0SnVRVzdEem11b1dwZFV3RFFZSktvWklodmNOQVFFTApCUUFEZ2dFQkFNME1XWFZnVjF6QmVqR00zYkdvQjdrdE9oZDF3eEE5MGloM245OGhFZ0xEbDNjTXBSYzI3ci9NClA1Q2ozMTZPWGhFYWdpajRYcktDUXVPRkVhRnRYSWJTSG93Rmk2bk94UkhYZGFYc3hKMCs5WkNJVzI3aWFjZkoKN3E5OUV4dk1ReEdYQXVETHlLS2FGa3p1OHZkTjVEZk5Rb1VxNjgzL1hLa1RicXZqUHlFelNMbVQzM2VmSWpHaQpEemE2TEpiTzhYYnNVMFMyNVVBcnNSWTlYNStDMGp6RStWbnFUWFFpbk5oYWR3RFpmT09DWnlxRTNFVUhLYmJICnZQTGswZTJJRXZaV240dFprRE9IM1E1VHBUYnhWd1JFRXo5aDhQOEszc1lMNjlPRVhPb0dWYlN6WEJPT1BtaGQKMldscmlVV1NqK3B3KzdwSlhKUFMxSWhHZi92Ujlkaz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBMU9IOVNYU2dhWHpsNUF1R09xZkVXR3RWalZFT0xNUjVNOVpWZlF0T1dJanpQR29nCmRSTXFaZDd3Nk5Eb0pCSFVQSmlEd1ZWT3JGUGg3MFFRTkZaLzE0VjZ6dllFRU5Va3pWY0VqeWFxSTQ1T2ZkQUsKcXhrNFlJdExtcUlEUVdtbklrK1FXM09ub0lYZEFBTktNeEVTQm1TbUZXT2NBbUNzVG5vdnZ3RmlxSm1HaWZCbgpIZ3cvem1Ud3plSGhEUjQ4b0RPSE9uNkg4bElObGxVYWFCbWUxaUY3MjdnalQvajd0cUhZT05kMHJnVFg3Z2EvCnpPTVZvSTZrUTVWWE1SZGZYVjVHbW9jZnNGa2p3em9WRm9OTHVhaVNOcGFBOEpZQUFiUTQwTjZGNTlVYnExdDgKQzVOOWNLV3loaWM3MG9FQ3paZDBKK21Pd2RSQjhicCtweGcwZ1FJREFRQUJBb0lCQUhiRkx0OVFwajYwWkQ1NgovNFN5SFNXSG5NK2ZMVjFrc0lwdlJucmhWL0NsVjYrWk5rcWJTc2hUUGUxbXdGMS9aUDM1eVdpUUE3aTVoQkJOCjFReWVSZTBrbDRQb1ZoUmVGbzVKd2sxcnNQanRhSFZoSU5LYzI0dGhxK2kyQTBMM2d6dnRVQWoxMmN3QlkyK2kKWmo5ZmdzTDJYSU1LYy93UG01S2RNUTVMNDVOVUwrNU03cUE4aEVZYUFnRE1pUG9YOEh3Y2s5aHVuK1FWWXM4cQozVmMwK29ta3FtVU5NYVFVcldJK2FNNnYxNzdyYWFXOEtRQmNYaVJicndTUmpXRkdwc1UvS2txenM1NXEvWFRlCkpGYUVqZ0t3K2k2V2d4Tld4NVV6OVdJOUlsSGtpYmFlek9NTmlqV1loRjJ0b2ZPMzIzc3lCblJSY1Q3WlJGeG4KZmlMTmd3RUNnWUVBNjk1UWl0QmpJdHhKZC8rTys1MGh4RGQrdFFZSTNhRGNNVWxDdjM4a2xHSmJuek43QUJKSgpQRjREYTY0Y0Jxa0dpaGU4WFBnc1hlcm9ZWGVkUVgxYkhic3NWdFR0b2VMTStIcjZFN2phSHpPL0svcVNVemF4ClVUY1UwL1dSWVdCRE1FQkdHN2p1czR1ejlyeDErTzlyYjVtQUI3S2d3VnJkUDdzK0UzUnN1TGtDZ1lFQTV3MXgKT1grRVNESTViKysrclgzZTROZUVkS0YvR2RpTkIyMEszOEVsRmh5OG5xc25mNWhFeUpGTnhqVmR3djlYbFF3cApMaDdjKzk3T0Z1SFBQU1J1RjVrR0RnK2F5cHVSTHRjR25QMGxvS1BVTVdRSUZuZnRTYjlCYXJISGZ1SDYrTUZBCjMxOGxMNWJLRUZKWW9EaDJBUk9RL0J4bEloYmhCNXN5QzcwTVpna0NnWUJPZ0d0bUIvMDJ1UUpxd2MrZ3hxZGEKV3UzODZjbEJtaXd1NnljZi9Qejd0ZEN3cDcya1JISERlYmJCdSt6ditvbUdwR2U0dVpCcW9hZzk2RVdhYWxKTgpEdUt1ODZjelhmekNKb3ZjeklVc0pWalhGa3BsRDZyc1VOekp2czFvRDFYTlZWY0FHd2kzRVNRUVZxRWMvUEpRCjdsSENQaDFxdlFjdUV1K1NJZ21kWVFLQmdIaC92elFRZCttN0g4OXNCbEt1MllVRGdSWGVmODMzN1IwWlZsbDUKZnFENG5icFdZc1Fkb29uRGxmOHdKOVVobkFpa2pmbDZxUjlHaE03VU4yT1kwejNGVmE0Um4xWFpLaTkyZndGeQoyS1BkclRXUkNOTEcrdDdDT3hpczNQRWtZK0pGejFKdmFaSlhIc3pDVld4QjVmRUx4a3BsZUt6OXA2Qnk1UGZRClFWNFpBb0dBWjNTQXhzTENuTWRWcms2Q0V0bzk4SjFuWFpwaU8vdHBZdmlLcVU1Vyt4QndVam5DYzRvcXNIai8KRW42QWU1LzFrbjNiOEpveVp3RzdQZC9JOEpTVVhQUllTbjB4RzVVV0FQQjVFR01CVC9IMk1YbDFYbldUZnNOaApJaGlQd3ZZc3p4dVdqUXMrN0tjTkJnS3kzcnpNT0hmbitSRWZ3RjlDTVJLZkNMYnBmR2s9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

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

在这里插入图片描述

总结

在这里插入图片描述

[root@k8s-master-01 ~]# kubectl get pods  -n kube-system 
NAME                                    READY   STATUS    RESTARTS   AGE
coredns-f68b4c98f-nkqlm                 1/1     Running   3          26d
coredns-f68b4c98f-wzrrq                 1/1     Running   3          26d
etcd-k8s-master-01                      1/1     Running   4          26d
kube-apiserver-k8s-master-01            1/1     Running   4          26d
kube-controller-manager-k8s-master-01   1/1     Running   5          26d
kube-flannel-ds-gn9zl                   1/1     Running   0          23h
kube-flannel-ds-vjt8b                   1/1     Running   5          15d
kube-flannel-ds-zcv5z                   1/1     Running   0          23h
kube-proxy-kl2qj                        1/1     Running   3          26d
kube-proxy-rrlg4                        1/1     Running   2          26d
kube-proxy-tc2nd                        1/1     Running   1          26d
kube-scheduler-k8s-master-01            1/1     Running   5          26d
[root@k8s-master-01 ~]# kubectl exec -it kube-proxy-tc2nd -n kube-system -- sh

# cd /run/secrets/kubernetes.io
# ll
serviceaccount

# cd serviceaccount
# ls
ca.crt	namespace  token

# cat ca.crt
-----BEGIN CERTIFICATE-----
MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIxMTIwNDEyNDE0OVoXDTMxMTIwMjEyNDE0OVowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM++
PZjizoRHCr9NjVCwc4REglPuHZX4edV8dMGen3EWFNNSqaLmk2C8MsO4zZEgGRt+
p58qG/S6CQ/ZT4McRf2sUOk5bI5sUAjN7DzBKhgweGwyYXM/1mtkyq7S7yr7twAq
6994lb+MspTIbNsqMnEzas8Y3HfMgg494ymjGQPfG2jpy2qOTgRLqavg6LXxyi7v
aIEfBpliINW0Y2+Bwpg5P1wivF5LnxIsjFZryeMYwe0iy/jxkO2JBR+RlI3+AxCt
e9VY7RTXKdC94gx4emhIunCDIe1XgFLmz1vjpU6foZBF2xmD4umw9m0W0Wplw0nO
8Pan0DNFdfqkzMSDjFcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wHQYDVR0OBBYEFHxyQbDzqZDFguCbkFuw85rqFqXVMA0GCSqGSIb3
DQEBCwUAA4IBAQDAf2IMj3wJWdyZZ5cmwpyESicshdsz1NQdzvMfbVFq+TiExJcH
KGc9HZPIjt2nH0doxAW6OHwSFJ6sZ4vaRgbmLLxS1sNVU0Pke0oiICgfiioZDi6+
hQRpPIU2WGUDf4SqttGql1cFy/0tUyoRgMrAVPSxbTqNakwzARmMCpyQIo0xZgor
gdW4UsKm+lMp0hIk0swdoEvhWuHEsVVgZ9wW5v3kTxi+IEN/ru4Atb/pcqWxTRPI
eBYHO5fvs6UqbI2WGxr2EmjB0Mz73KyI4RBKvjn1Kdw1g12jTeNNxr0srQr2GtZX
AbOmyc+IiM9+gkz8lWE40a/skhyvSUSEgPRS
-----END CERTIFICATE-----
# cat namespace
kube-system# 

# cat token
eyJhbGciOiJSUzI1NiIsImtpZCI6InVZNmNCRXo3SC1XVnMxLWlsWEZfZ3ctc2V0ZXFqWkNsRy1ic3ZYSTczVkkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlLXByb3h5LXRva2VuLWcyaGxtIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmUtcHJveHkiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJlN2Q4NTIzNC0wZWMzLTQ0MjQtOTNkMC1hODQ5ZjA0NGI0MzEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06a3ViZS1wcm94eSJ9.rFdcQnRXuhQscLdVmS5-hAY7Eef6HY5KD6MPvChpCsK8FPpvuOGGP4NtAwX6oBHjxrBunjGI_5h44zl6t-f-tzmPejr3WspedmvLiBz4w5Ykf0EB7vBzUHIU1WILzGF_g5vi64I-FohXxgL1s_tV4qxAxcNO53R74lVqAW-Ssfu4Nx2L77K6fSaKch2nJjSUwHoJnNeQCNlMTeCQLz4vf012IPDPRF50rjf0LRpMA554wBFHGp50GogurgxOsWPFrq0wh4-GvePVHY9hZD3c3vaMxPcI3C2nlxcgMIQBMBFJjJKWjnCzy4PVf-HiuqTEHrxvh-iPtuqzEJM0toDVJA# 

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

二、鉴权（Authorization）

API Server目前支持以下几种授权策略：

通过apiver server的启动参数“–Authorization-mode设置”

AlwaysDeny：表示拒绝所有请求，一般用于测试
AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）
ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
Webhook：通过调用外部REST服务对用户进行授权
-Node：是一种专用模式，用于对kubelet发出的请求进行访问控制
RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）

RBAC授权

在这里插入图片描述

RBAC的API资源说明对象

RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限

其中涉及到了下面几个概念：

对象：User、Groups、ServiceAccount
角色：代表着一组定义在资源上的可操作动作(权限)的集合
绑定：将定义好的角色跟用户绑定在一起

4个资源对象：
Role、ClusterRole RoleBinding、ClusterRoleBinding

在这里插入图片描述

在这里插入图片描述
需要注意的是kubernetes的并不会提供用户的管理，那么user、group、ServiceAccount、指定的用户又哪里来呢？kubernetes组件（kubectl kube-proxy ）或是其他自定义的用户，在向CA申请证书时，需要提供一个证书请求文件。

在这里插入图片描述

1、Role and ClusterRole

一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）。

在RBAC Api中。Role表示一组规则权限，权限只会增加（累加权限），不存在一个资源一开始就会有很多权限，而通过RBAC对其进行减少的操作，Role可以定义在一个namespace中，如果想要跨nameapace则可以创建ClusterRole。

# Role只能对命名空间内的资源进行授权，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader   #Role名
rules: # 规则
- apiGroups: [""]  # 支持的API组列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许的对资源对象的操作方法列表


1
2
3
4
5
6
7
8
9
10
11
12

ClusterRole具有与Role相同的权限角色能力控制能力，不同的是ClusterRole是集群级别的，ClusterRole可用于：

集群级别资源的控制（例如node访问权限）
非资源型的endpoints （例如/healthz）
所有命名空间的资源控制（例如pods）

# ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secret"]
  verbs: ["get", "watch", "list"]



1
2
3
4
5
6
7
8
9
10
11
12

2、RoleBinding、ClusterRoleBinding

RoleBinding可以将角色中定义的权限授予用户或者用户组，RoleBinding包含一组权限列表（subjects），权限列表中包含有不同形势的待授予权限资源类型的（user、groups、service accouts）；RoleBinding同样包含对被Bind的Role引用，RoleBinding适用于某个命名空间内授权，而ClusterRoleBinding适用于集群范围内的授权。

将default命名空间内的pod-reader Role授予jane用户，此后jane用户在default命名空间中将具有pod-reader的权限。

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Rolebinding同样可以引用ClusterRole来对当前的namespace内用户、用户组或ServiceAccount进行授权，这种操作允许集群管理员在整个集群内定义一些通过的clusterRole，然而在不同的namespace中使用RoleBinding来引用。

例如：以下RoleBinding中引用一个ClusterRole，这个ClusterRole具有整个集群内对secrets的访问权限，但是对其授权用户dave只能访问developoment空间中的secrets（因为RoleBinding定义在development命名空间）

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

使用ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权，以下ClusterRoleBinding样例展示了授权manager组内所有用户在全部命名空间中随secrets进行访问。

# ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: read-secrets-global
subjects:
- kind: User
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Resources

kubernets 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在API的URL地址中出现，：同时某些资源也会包含子资源，例如logs资源就属于pods的子资源，API中样例如下：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

1
2

如果要在RBAC模型中控制这些子资源的访问权限，可以通过/ 分隔符来实现，以下是一个定义pods资源logs访问权限Role定义样例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-and-pod-logs-reader
  namespace: ddefault
rules:
- apiGroups: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list"]
  
1
2
3
4
5
6
7
8
9
10

to subject

RoleBinding、和ClusterRoleBinding 可以将Role绑定到subjects；subjects可以是groups、user、或者service accounts

subjects中的user使用字符串表示，它可以是一个普通的名字字符串，如“alice”，也可以是email格式的邮箱地址，如wangyanglinux@163.com ；甚至是一组字符串形式的的数字id，但是Users的前缀system，是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式。

Groups书写格式与Users相同，都为一个字符串，并且没有一个特定的格式要求，同样system为系统保留。

实践–创建一个用户只能管理dev命名空间

{
"CN": "devuser",
"hosts": [],
"keys": {
  "algo": "rsa",
  "size": 2048
  },
 "names": [
  {
  "C": "CN",
  "ST": "BeiJing",
  "L": "BeiJing",
  "O": "k8s",
  "OU": "System"
  }
  ]
  }



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

下载证书工具

cfssl 生成证书
cfssl-json 证书格式化成文件
cfss-certinfo 查看证书的信息，发证机构，证书有效期
下载地址
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /usr/local/bin


[root@k8s-master-01 pki]# cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /etc/kubernetes/pki/devuser-csr.json | cfssl-json -bare devuser


#创建普通用户
useradd devuser
passwd devuser

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

在这里插入图片描述

设置集群参数

[root@k8s-master-01 pki]# export KUBE_APISERVER="https://192.168.15.31:6443"

[root@k8s-master-01 pki]#  kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=devuser.kubeconfig




[root@k8s-master-01 pki]# cat devuser.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1USXdOREV5TkRFME9Wb1hEVE14TVRJd01qRS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTSsrClBaaml6b1JIQ3I5TmpWQ3djNcUcvUzZDUS9aVDRNY1JmMnNVT2s1Ykk1c1VBak43RHpCS2hnd2VHd3lZWE0vMW10a3lxN1M3ecHkycU9UZ1JMcWF2ZzZMWHh5aTd2CmFJRWZCcGxpSU5XMFkyK0J3cGc1UDF3aXZGNUxueElzaaEl1bkNESWUxWGdGTG16MXZqcFU2Zm9aQkYyeG1ENHVtdzltMFcwV3BsdzBuTwo4UGFuMERORVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZIeHlRYkR6cVpERmd1Q2JrRnV3ODVyccHlFU2ljc2hkc3oxTlFkenZNZmJWRnErVGlFeEpjSApLR2M5SFpQSWp0Mm5IMGRveEFXNk9IdV0dVRGY0U3F0dEdxbDFjRnkvMHRVeW9SZ01yQVZQU3hiVHFOYWt3ekFSbU1DcHlRSW8weFpnbcnU0QXRiL3BjcVd4VFJQSQplQllITzVmdnM2VXFiSTJXR3hyMkVtakIwTXo3M0t5STRSQkt2ac2toeXZTVVNFZ1BSUwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://192.168.15.31:6443
  name: kubernetes
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

设置客户端认证参数

[root@k8s-master-01 pki]# kubectl config set-context kubernetes --cluster=kubernetes --user=devuser --namespace=dev --kubeconfig=devuser.kubeconfig 

Context "kubernetes" created.
[root@k8s-master-01 pki]# cat devuser.kubeconfig 


kubectl create ns dev
1
2
3
4
5
6
7

设置上下文参数

[root@k8s-master-01 pki]# kubectl config set-context kubernetes --cluster=kubernetes --user=devuser --namespace=dev --kubeconfig=devuser.kubeconfig 


### 可以查看devuser.kubeconfig文件
[root@k8s-master-01 pki]# cat devuser.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1USXdOREV5TkRFME9Wb1hEVE14TVRJd01qRXlOREUwT1Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTSsrClBaaml6b1JIQ3I5TmpWQ3djNFJFZ2xQdUhaWDRlZFY4ZE1HZW4zRVdGTk5TcWFMbWsyQzhNc080elpFZ0dSdCsKcDU4cUcvUzZDUS9aVDRNY1JmMnNVT2s1Ykk1c1VBak43RHpCS2hnd2VHd3lZWE0vMW10a3lxN1M3eXI3dHdBcQo2OTk0bGIrTXNwVEliTnNxTW5FemFzOFkzSGZNZ2c0OTR5bWpHUVBmRzJqcHkycU9UZ1JMcWF2ZzZMWHh5aTd2CmFJRWZCcGxpSU5XMFkyK0J3cGc1UDF3aXZGNUxueElzakZacnllTVl3ZTBpeS9qeGtPMkpCUitSbEkzK0F4Q3QKZTlWWTdSVFhLZEM5NGd4NGVtaEl1bkNESWUxWGdGTG16MXZqcFU2Zm9aQkYyeG1ENHVtdzltMFcwV3BsdzBuTwo4UGFuMERORmRmcWt6TVNEakZjQ0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZIeHlRYkR6cVpERmd1Q2JrRnV3ODVycUZxWFZNQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFEQWYySU1qM3dKV2R5Wlo1Y213cHlFU2ljc2hkc3oxTlFkenZNZmJWRnErVGlFeEpjSApLR2M5SFpQSWp0Mm5IMGRveEFXNk9Id1NGSjZzWjR2YVJnYm1MTHhTMXNOVlUwUGtlMG9pSUNnZmlpb1pEaTYrCmhRUnBQSVUyV0dVRGY0U3F0dEdxbDFjRnkvMHRVeW9SZ01yQVZQU3hiVHFOYWt3ekFSbU1DcHlRSW8weFpnb3IKZ2RXNFVzS20rbE1wMGhJazBzd2RvRXZoV3VIRXNWVmdaOXdXNXYza1R4aStJRU4vcnU0QXRiL3BjcVd4VFJQSQplQllITzVmdnM2VXFiSTJXR3hyMkVtakIwTXo3M0t5STRSQkt2am4xS2R3MWcxMmpUZU5OeHIwc3JRcjJHdFpYCkFiT215YytJaU05K2drejhsV0U0MGEvc2toeXZTVVNFZ1BSUwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://192.168.15.31:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: dev
    user: devuser
  name: kubernetes
current-context: ""
kind: Config
preferences: {}
users: null


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

设置默认上下文


kubectl config use-context kubernetes --kubeconfig=config

cp devuser.kubeconfig /home/devuser/.kube/

[root@k8s-master-01 pki]# kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev


[root@k8s-master-01 pki]# cp devuser.kubeconfig /home/devuser/.kube/
[root@k8s-master-01 pki]# chown devuser:devuser /home/devuser/.kube/config 


看下文
1
2
3
4
5
6
7
8
9
10
11
12
13

普通用户查看pod以及状态

[devuser@k8s-master-01 .kube]$ kubectl config use-context kubernetes --kubeconfig=config
Switched to context "kubernetes".
[devuser@k8s-master-01 .kube]$ kubectl get pods
No resources found in dev namespace.
[devuser@k8s-master-01 .kube]$ 
#运行nginx容器
[devuser@k8s-master-01 .kube]$ kubectl run nginx --image=wangyanglinux/myapp:v2
pod/nginx created
[devuser@k8s-master-01 .kube]$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          4s


#master节点管理员用户查看，可以看见dev  命名空间
[root@k8s-master-01 pki]# kubectl get pods -o wide --all-namespaces |grep nginx

dev             nginx                                      1/1     Running   0          84s    10.244.1.148    k8s-node-01     <none>           <none>
ingress-nginx   ingress-nginx-controller-944f8df68-5vzg4   1/1     Running   1          3d3h   10.244.1.128    k8s-node-01     <none>           



#再次回到devuser用户查到default命名空间没有权限查看
[devuser@k8s-master-01 .kube]$ kubectl get pods -n default
Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"

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

准入控制

通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver才会处理这个请求。

准入控制是一个可配置的控制器列表，可以通过在Api-Server上通过命令行设置选择执行哪些准入控制器：

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

1
2
3

只有当所有的准入控制器都检查通过之后，apiserver才执行该请求，否则返回拒绝。

当前可配置的Admission Control准入控制如下：

AlwaysAdmit：允许所有请求
AlwaysDeny：禁止所有请求，一般用于测试
AlwaysPullImages：在启动容器之前总去下载镜像
DenyExecOnPrivileged：它会拦截所有想在Privileged
Container上执行命令的请求
ImagePolicyWebhook：这个插件将允许后端的一个
Webhook程序来完成admission controller的功能。
Service Account：实现ServiceAccount实现了自动化
SecurityContextDeny：这个插件将使用SecurityContext的Pod中的定义全部失效
ResourceQuota：用于资源配额管理目的，观察所有请求，确保在namespace上的配额不会超标
LimitRanger：用于资源限制管理，作用于namespace上，确保对Pod进行资源限制
InitialResources：为未设置资源请求与限制的Pod，根据其镜像的历史资源的使用情况进行设置
NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象。
DefaultStorageClass：为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节
DefaultTolerationSeconds：这个插件为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的“容忍”时间，为5min
PodSecurityPolicy：这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制

二、RBAC的认识

前面我们学习了Kubernetes中的两个用于配置信息的重要资源对象：ConfigMap和Secret，其实到这里我们基本上学习的内容已经覆盖到Kubernetes中一些重要的资源对象了，来部署一个应用程序是完全没有问题的了。在我们演示一个完整的示例之前，我们还需要给大家讲解一个重要的概念：RBAC - 基于角色的访问控制。

RBAC使用rbac.authorization.k8s.io API Group来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，如果使用的kubeadm安装的集群，1.6 版本以上的都默认开启了RBAC，可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

$ cat /etc/kubernetes/manifests/kube-apiserver.yaml 
...
    - --authorization-mode=Node,RBAC
...
1
2
3
4

如果是二进制的方式搭建的集群，添加这个参数过后，记得要重启 apiserver 服务。

1、RBAC API 对象

Kubernetes有一个很基本的特性就是它的所有资源对象都是模型化的 API 对象，允许执行 CRUD(Create、Read、Update、Delete)操作(也就是我们常说的增、删、改、查操作)，比如下面的这下资源：

Pods
ConfigMaps
Deployments
Nodes
Secrets
Namespaces
上面这些资源对象的可能存在的操作有：
create
get
delete
list
update
edit
watch
exec
在更上层，这些资源和 API Group 进行关联，比如Pods属于 Core API Group，而Deployements属于 apps API Group，要在Kubernetes中进行RBAC的管理，除了上面的这些资源和操作以外，我们还需要另外的一些对象：
Rule：规则，规则是一组属于不同 API Group 资源上的一组操作的集合
Role 和 ClusterRole：角色和集群角色，这两个对象都包含上面的 Rules 元素，二者的区别在于，在 Role 中，定义的规则只适用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。另外 Role 和 ClusterRole 在Kubernetes中都被定义为集群内部的 API 资源，和我们前面学习过的 Pod、ConfigMap 这些类似，都是我们集群的资源对象，所以同样的可以使用我们前面的kubectl相关的命令来进行操作
Subject：主题，对应在集群中尝试操作的对象，集群中定义了3种类型的主题资源：
- User Account：用户，这是有外部独立服务进行管理的，管理员进行私钥的分配，用户可以使用 KeyStone或者 Goolge 帐号，甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象，所以用户不能通过集群内部的 API 来进行管理
- Group：组，这是用来关联多个账户的，集群中有一些默认创建的组，比如cluster-admin
- Service Account：服务帐号，通过Kubernetes API 来管理的一些用户帐号，和 namespace 进行关联的，适用于集群内部运行的应用程序，需要通过 API 来完成权限认证，所以在集群内部进行权限操作，我们都需要使用到 ServiceAccount，这也是我们这节课的重点
RoleBinding 和 ClusterRoleBinding：角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前 namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

接下来我们来通过几个示例来演示下RBAC的配置方法。

2、创建一个只能访问某个 namespace 的用户

我们来创建一个User Account，只能访问 kube-system 这个命名空间：

username: haimaxy
group: youdianzhishi

第1步：创建用户凭证

我们前面已经提到过，Kubernetes没有 User Account 的 API 对象，不过要创建一个用户帐号的话也是挺简单的，利用管理员分配给你的一个私钥就可以创建了，这个我们可以参考官方文档中的方法，这里我们来使用OpenSSL证书来创建一个 User，当然我们也可以使用更简单的cfssl工具来创建：

给用户 haimaxy 创建一个私钥，命名成：haimaxy.key：

openssl genrsa -out haimaxy.key 2048
1

使用我们刚刚创建的私钥创建一个证书签名请求文件：haimaxy.csr，要注意需要确保在-subj参数中指定用户名和组(CN表示用户名，O表示组)：

openssl req -new -key haimaxy.key -out haimaxy.csr -subj "/CN=haimaxy/O=youdianzhis"
1

然后找到我们的Kubernetes集群的CA，我们使用的是kubeadm安装的集群，CA相关证书位于/etc/kubernetes/pki/目录下面，如果你是二进制方式搭建的，你应该在最开始搭建集群的时候就已经指定好了CA的目录，我们会利用该目录下面的ca.crt和ca.key两个文件来批准上面的证书请求

生成最终的证书文件，我们这里设置证书的有效期为500天：

openssl x509 -req -in haimaxy.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out haimaxy.crt -days 500
1

现在查看我们当前文件夹下面是否生成了一个证书文件：

$ ls
haimaxy.csr haimaxy.key haimaxy.crt
1
2

现在我们可以使用刚刚创建的证书文件和私钥文件在集群中创建新的凭证和上下文(Context):

 kubectl config set-credentials haimaxy --client-certificate=haimaxy.crt  --client-key=haimaxy.key
1

我们可以看到一个用户haimaxy创建了，然后为这个用户设置新的 Context

$ kubectl config set-context haimaxy-context --cluster=kubernetes --namespace=kube-system --user=haimaxy
1

到这里，我们的用户haimaxy就已经创建成功了，现在我们使用当前的这个配置文件来操作kubectl命令的时候，应该会出现错误，因为我们还没有为该用户定义任何操作的权限呢：

$ kubectl get pods --context=haimaxy-context
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"
1
2

第2步：创建角色

用户创建完成后，接下来就需要给该用户添加操作权限，我们来定义一个YAML文件，创建一个允许用户操作 Deployment、Pod、ReplicaSets 的角色，如下定义：(haimaxy-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: haimaxy-role
  namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']
1
2
3
4
5
6
7
8
9

其中Pod属于 core 这个 API Group，在YAML中用空字符就可以，而Deployment属于 apps 这个 API Group，ReplicaSets属于extensions这个 API Group(我怎么知道的？点击这里查看)，所以 rules 下面的 apiGroups 就综合了这几个资源的 API Group：["", "extensions", "apps"]，其中verbs就是我们上面提到的可以对这些资源对象执行的操作，我们这里需要所有的操作方法，所以我们也可以使用[’*’]来代替。

然后创建这个Role：

$ kubectl create -f haimaxy-role.yaml
1

注意这里我们没有使用上面的haimaxy-context这个上下文了，因为木有权限啦

第3步：创建角色权限绑定

Role 创建完成了，但是很明显现在我们这个 Role 和我们的用户 haimaxy 还没有任何关系，对吧？这里我就需要创建一个RoleBinding对象，在 kube-system 这个命名空间下面将上面的 haimaxy-role 角色和用户 haimaxy 进行绑定:(haimaxy-rolebinding.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: haimaxy-rolebinding
  namespace: kube-system
subjects:
- kind: User
  name: haimaxy
  apiGroup: ""
roleRef:
  kind: Role
  name: haimaxy-role
  apiGroup: ""
1
2
3
4
5
6
7
8
9
10
11
12
13

上面的YAML文件中我们看到了subjects关键字，这里就是我们上面提到的用来尝试操作集群的对象，这里对应上面的 User 帐号 haimaxy，使用kubectl创建上面的资源对象：

$ kubectl create -f haimaxy-rolebinding.yaml
1

第4步. 测试

现在我们应该可以上面的haimaxy-context上下文来操作集群了：

$ kubectl get pods --context=haimaxy-context
....
1
2

我们可以看到我们使用kubectl的使用并没有指定 namespace 了，这是因为我们已经为该用户分配了权限了，如果我们在后面加上一个-n default试看看呢？

$ kubectl --context=haimaxy-context get pods --namespace=default
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"
1
2

是符合我们预期的吧？因为该用户并没有 default 这个命名空间的操作权限

3、创建一个只能访问某个 namespace 的ServiceAccount

上面我们创建了一个只能访问某个命名空间下面的普通用户，我们前面也提到过 subjects下面还有一直类型的主题资源：ServiceAccount，现在我们来创建一个集群内部的用户只能操作 kube-system 这个命名空间下面的 pods 和 deployments，首先来创建一个 ServiceAccount 对象：

 kubectl create sa haimaxy-sa -n kube-system
1

当然我们也可以定义成YAML文件的形式来创建。

然后新建一个 Role 对象：(haimaxy-sa-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: haimaxy-sa-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
1
2
3
4
5
6
7
8
9
10
11
12

可以看到我们这里定义的角色没有创建、删除、更新 Pod 的权限，待会我们可以重点测试一下，创建该 Role 对象：

$ kubectl create -f haimaxy-sa-role.yaml
1

然后创建一个RoleBinding 对象，将上面的 haimaxy-sa 和角色 haimaxy-sa-role 进行绑定：(haimaxy-sa-rolebinding.yaml)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: haimaxy-sa-rolebinding
  namespace: kube-system
subjects:
- kind: ServiceAccount
  name: haimaxy-sa
  namespace: kube-system
roleRef:
  kind: Role
  name: haimaxy-sa-role
  apiGroup: rbac.authorization.k8s.io
1
2
3
4
5
6
7
8
9
10
11
12
13

添加这个资源对象：

$ kubectl create -f haimaxy-sa-rolebinding.yaml
1

然后我们怎么去验证这个 ServiceAccount 呢？我们前面的课程中是不是提到过一个 ServiceAccount 会生成一个 Secret 对象和它进行映射，这个 Secret 里面包含一个 token，我们可以利用这个 token 去登录 Dashboard，然后我们就可以在 Dashboard 中来验证我们的功能是否符合预期了：

$ kubectl get secret -n kube-system |grep haimay-sa
haimay-sa-token-nxgqx                  kubernetes.io/service-account-token   3         47m
$ kubectl get secret haimay-sa-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d
# 会生成一串很长的base64后的字符串
1
2
3
4

使用这里的 token 去 Dashboard 页面进行登录：
在这里插入图片描述
我们可以看到上面的提示信息，这是因为我们登录进来后默认跳转到 default 命名空间，我们切换到kube-system 命名空间下面就可以了：

我们可以看到可以访问pod列表了，但是也会有一些其他额外的提示：events is forbidden: User “system:serviceaccount:kube-system:haimaxy-sa” cannot list events in the namespace “kube-system”，这是因为当前登录用只被授权了访问 pod 和 deployment 的权限，同样的，访问下deployment看看可以了吗？

同样的，你可以根据自己的需求来对访问用户的权限进行限制，可以自己通过 Role 定义更加细粒度的权限，也可以使用系统内置的一些权限……

创建一个可以访问所有 namespace 的ServiceAccount
刚刚我们创建的haimaxy-sa这个 ServiceAccount和一个 Role 角色进行绑定的，如果我们现在创建一个新的 ServiceAccount，需要他操作的权限作用于所有的 namespace，这个时候我们就需要使用到 ClusterRole 和 ClusterRoleBinding这两种资源对象了。同样，首先新建一个 ServiceAcount 对象：(haimaxy-sa2.yaml)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: haimaxy-sa2
  namespace: kube-system
1
2
3
4
5

创建：

$ kubectl create -f haimaxy-sa2.yaml
1

然后创建一个 ClusterRoleBinding 对象(haimaxy-clusterolebinding.yaml):

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: haimaxy-sa2-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: haimaxy-sa2
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
1
2
3
4
5
6
7
8
9
10
11
12

从上面我们可以看到我们没有为这个资源对象声明 namespace，因为这是一个 ClusterRoleBinding资源对象，是作用于整个集群的，我们也没有单独新建一个 ClusterRole 对象，而是使用的cluster-admin这个对象，这是Kubernetes集群内置的 ClusterRole 对象，我们可以使用kubectl get clusterrole 和kubectl get clusterrolebinding查看系统内置的一些集群角色和集群角色绑定，这里我们使用的 cluster-admin 这个集群角色是拥有最高权限的集群角色，所以一般需要谨慎使用该集群角色。

创建上面集群角色绑定资源对象，创建完成后同样使用 ServiceAccount 对应的 token 去登录 Dashboard 验证下：

$ kubectl create -f haimaxy-clusterolebinding.yaml
$ kubectl get secret -n kube-system |grep haimay-sa2
haimay-sa2-token-nxgqx                  kubernetes.io/service-account-token   3         47m
$ kubectl get secret haimay-sa2-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d
#会生成一串很长的base64后的字符串
1
2
3
4
5

我们在最开始接触到RBAC认证的时候，可能不太熟悉，特别是不知道应该怎么去编写rules规则，大家可以去分析系统自带的 clusterrole、clusterrolebinding 这些资源对象的编写方法，怎么分析？还是利用 kubectl 的 get、describe、 -o yaml 这些操作，所以kubectl最基本的用户一定要掌握好。

RBAC只是Kubernetes中安全认证的一种方式，当然也是现在最重要的一种方式，后面我们再和大家一起聊一聊Kubernetes中安全设计。

RBAC官方链接

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/你好赵伟/article/detail/73653

安全认证、准入控制、RBAC_防火墙中准入和用户认证的区别

文章目录

准入机制

一、Authentication:认证

1.https的认证

需要认证的节点

总结

二、鉴权（Authorization）

API Server目前支持以下几种授权策略：

RBAC授权

RBAC的API资源说明对象

1、Role and ClusterRole

2、RoleBinding、ClusterRoleBinding

Resources

to subject

实践–创建一个用户只能管理dev命名空间

下载证书工具

设置集群参数

设置客户端认证参数

设置上下文参数

设置默认上下文

普通用户查看pod以及状态

准入控制

二、RBAC的认识

1、RBAC API 对象

2、创建一个只能访问某个 namespace 的用户

第1步：创建用户凭证

第2步：创建角色

第3步：创建角色权限绑定

第4步. 测试

3、创建一个只能访问某个 namespace 的ServiceAccount