24.B站薪享宏福笔记——第九章 k8s 集群安全机制

9 k8s 集群安全机制

——— 守住 Kubernetes 的底线

9.1 安全机制说明

——— 如何安全，如何安心

9.1.1 机制说明

Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API Server 来设计的

用户或pod客户端访问API Server -> ①认证（是不是自己人） -> ②鉴权（是否有权利） -> ③准入控制（操作是否合理） -> ④访问对应资源对象

9.2 认证

——— 是不是自己人

9.2.1 认证模式

（1）Kubernetes 认证类型

1.HTTP Token 认证：通过一个 Token 来识别合法用户

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

2.HTTP Base 认证：通过用户名+密码的方式认证

　　用户名 + 密码用 base64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端，服务端收到后进行解编码，获取用户名及密码

3.最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式（金融级别的安全方式，也是现在使用的模式）

（2）HTTPS 认证工作模式

1.服务端向 CA架构申请证书，CA 向服务端下发证书

2.客户端向 CA架构申请证书，CA 向客户端下发证书

3.当需要通信时，客户端尝试连接服务器端，服务端将证书公钥A发送给客户端，客户端验证有效期通过后，将自己的证书公钥B发送给服务端，服务端验证有效期通过后，互相认证（双向 HTTPS 认证），认证成功

4.客户端创建一个随机的字符串当做对称加密的密钥，通过公钥A将加密的密钥发送给服务端，服务端收到后，进行解密，获得对称加密密钥和对称加密算法，返回数据使用公钥B加密，从而可以进行双向加密数据传输

（3）HTTPS 认证方式

　　单向 HTTPS 认证：

　　　　客户端认证服务端（浏览器例：访问 www.baidu.com）

　　双向 HTTPS 认证：

　　　　客户端与浏览器端双向认证（金融行业例：ATM机与银行系统）

9.2.2 组件认证

（1）API Server 访问

Kubernetes 组件对 API Server 的访问：Kubectl（命令行请求调用 create、delete等）、Controller Manager（监听API获取各节点状态、Pod 状态）、Scheduler（监听API获取未绑定的 Pod）、Kubelet（监听获取当前节点需要启动的 Pod）、Kube-proxy（监听API，再调用IPvs生成对应路由规则），其中部分组件虽是以 Pod 形式运行，但安全机制仍然按照 组件通信方式运行。

Kubernetes 管理的 Pod 对容器的访问：Pod（DNS 插件、Calico 插件以 Pod 形式运行，需要访问 API 获取网络信息）（dashborad 也是以 Pod 形式运行）

（2）Kubeadm 方式安装的各组件认证形式

　　当 Controller Manager、Scheduler 与 API Server 在同一台机器，可以直接使用 API Server 的非安全端口访问， --insecure-bind-address=127.0.0.1（同一个家中，不该加密结果加密会浪费资源的）

　　Kubectl（客户端工具，每个节点都能安装）、Kubelet（所有节点都有）、Kube-proxy（所有节点都有）与 API Server 不在同一台机器，访问 API Server 都需要证书进行 HTTPS 双向认证（该加密结果不加密，不安全的）

（3）证书签发模式

手动签发：通过 k8s 集群，跟 CA 进行签发 HTTPS 证书（手动执行命令）

自动签发：Kubelet 首次访问 API Server 时，使用 token 做认证，通过后，Controller Manager 会为 Kubelet 生成一个证书，以后的访问都是基于此证书做认证

kubeadm 是 kubernetes 的工具，使用 kubeadm 方式安装 kubernetes，各组件被 kubeadm 工具分发了证书，而不是 kubernetes 自动分发证书

kubeadm join 192.168.66.11:6443 --token uoxcrw.tojl3gdya7vo6tjt --discovery-token-ca-cert-hash sha256:86968cb95dc2ff4df8b5960ee5712a148a485ec2bf8dd4ab9ecd5cef97158a6f --cri-socket unix:///var/run/cri-dockerd.sock

192.168.66.11:6443                     指定当前 master服务器 API Server 的地址和端口
--token uoxcrw.tojl3gdya7vo6tjt        集群给 node节点 颁发的令牌，用于 API Server 识别 kubelet 是否合法（双向认证，有时效，在时效内访问，才可以加入集群，类似123321口令）
--discovery-token-ca-cert-hash         当前 CA 证书的 hash 值，用于 kubelet 确认 API Server 发送来的证书是否合法（双向认证，黑虎帮信物，别加错帮派）
--cri-socket unix:///var/run/cri-dockerd.sock  容器运行时接口，kubelet 调用启动容器的接口

（4）kubeconfig

kubeconfig 文件包含集群参数（CA证书、API Servere地址），客户端参数（上面生成的证书和私钥），集群 context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的 kubeconfig 文件可以切换到不同集群

[root@k8s-master01 9]# cat /root/.kube/config 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJRGt3aHFPeUdaY0V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TlRBMU1qY3hPREU1TkRoYUZ3MHpOVEExTWpVeE9ESTBORGhhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURCUDNrOHBpN0JXd2F6OW4zVk1MenVuWjFVdVRBUEVUS05rWVJFK3BFZlJoUC9LdWFabm5PYkhMMzkKTVp0ZldYeUxQbTlsQTdJcTA5UEVmTUdQWDdTdDcrSElISXNyOGd4MzVQWTNLb2Y3SXh6QWpHSFJmenJBam83eQpYWGJkalpKZE1zTGdDb0JpbWIrcXBheXBKM2VBdFZsRTZwWGlhRStRMDM2cVI3cmY0RElqRDVGVTVneDZFb3VYCk1TcDlGYzBISC84Z0IwSmhWUktDQkpCQUFyZ29TM0NCNFlNeXJjbHRMd2RsaGQ2eGVBS3l1YUdtdDdHNjV6bFAKN0NQWmRQOUdMelgzWTNucmFRTDNRMXZKSjBtMmkxT09lOU12VE51TjkvMGE1My9pWFUyWitOS2FWMi8rRTluTApEdFZlcU43NWhHK1lOdWRTSDI2a3hlNlZiMVJuQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJSMGxUaDRjMEpJRXJkRTBCZmVvZElSWURmTUV6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ2RiSjdpcHljcgpRQmV4OVJHK21kSG5uMFJNdFhvc1ZDS0Z4NHplNEp4clVvZnhsdXJzT2pYRWswWFUrdlZzYis2NlRleTBRZEY5CmdFbENwWGFQOXpKZzFIUVNxMktYYjZIUm1xYzVlaDl0WW5vVUFwczQ2cmtEN2xaajZNcVQ3NWl6bmpFV2lrYTYKdWMvL3VoNFBEeHpzQ2YvMmtiYlcvaTBZSjExNTVwTEEwRUZYU0d5OGZwSkZ5c3htemlrYVF0YUxwRnlzSHhxNwpTTDErT1BWWkM0N0FQT29INGVlVzN0MVVmYVZvbTFOV0xkcENsRGRsOUlYOUdLYnB4dk1weGNsektYVittQW45CnRoc0ZjQkhZb09uaHRDMTk5NzZYQnIrdFdGdjVtMlpnNjd0d1kxMmhGODduREllN1RwQlVkYzAvc1pTdUtsb2sKV003QkxCQU56LzJyCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.66.11: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: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURLVENDQWhHZ0F3SUJBZ0lJT0RGaHlvdlc0czR3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TlRBMU1qY3hPREU1TkRoYUZ3MHlOakExTWpjeE9ESTBOVEJhTUR3eApIekFkQmdOVkJBb1RGbXQxWW1WaFpHMDZZMngxYzNSbGNpMWhaRzFwYm5NeEdUQVhCZ05WQkFNVEVHdDFZbVZ5CmJtVjBaWE10WVdSdGFXNHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFESEQ0WVcKVER3andIUUIxR3dYVFoyckNGb09yRE5Na20wVjY3Y2s5Y04zSXNybitJdmFzcGZNd0NXVkhvTDFGWXlneG5lZgo0Ym50MXN0eDhJQnRPUEE1UVBEbmJoUmdrUDZTZnhCcml1dWZHeTBoaVpOUGNYK2F1YTkzTGRuZ1lMZ1hQcFFJCjhZVHYxVDZ6bCtIb2NMRjlEZlhJU2llMlNxR3ZrTStjNzhzejY2WlV1SFpaQ042RFNRZURDOExEdFJrMUJHV2IKNHZCdTRjTGs1akllYWxaZUExNEVhODl6TDE0YVpPdFk4ZmtFUXhXRnNuTmZTUWFObjhxeGR4NlNEeHBYaWNrYwp4R1Z3Z3MwU0ZWeVlWWE1VejA4VXc4Q01yZmI1WmlDM01vNk15UWQ2VW85MzB5VkVadXZpTGtvWEZqSEhiL3ZDCnVOSHM1WjdIdC9KOVY5clBBZ01CQUFHalZqQlVNQTRHQTFVZER3RUIvd1FFQXdJRm9EQVRCZ05WSFNVRUREQUsKQmdnckJnRUZCUWNEQWpBTUJnTlZIUk1CQWY4RUFqQUFNQjhHQTFVZEl3UVlNQmFBRkhTVk9IaHpRa2dTdDBUUQpGOTZoMGhGZ044d1RNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUN3c2hoaDNqS3FvUXhqaFZTdjV5M3dFbWprCnkvSjRlQzFvdyt2S2Zzdnppa0RySUp3T1pFMlVXTFIwUStXckhzNjJXOHJaUGZKK0dwNGtmdUhrbS9TbjROaVkKUXVXa0xWTnFoTldBN0pwMFhBbWUva2tQbSswNEVacWVZT0tIbUtyZEx2clN6WmJEcko1cnVta0RCNkpoUU9aVApJWEI4ekxtK0ExUWhVbkx2MWZIa1RpaThwdzZ2RlJjR2J1MzYyZHBlbU84TWdSQ2VkNVYzS3JqeWVkWTd3bGdGCjg0aGxEc2RZSU5aTHViR1kzQ3VidVlSdmhiUDlDaXZvekMvSFU5WW1TSjViSzB6N3FBclZlUTBKblJsZHd4Ni8KcDFpb3N1aUR6MmxscVl1OGlTWXU5aTAvc3NXcFVmUm55bFRvVXQ3QUlYSDkyNlVqZzhzVWtYeG0yWHkwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBeHcrR0ZrdzhJOEIwQWRSc0YwMmRxd2hhRHF3elRKSnRGZXUzSlBYRGR5TEs1L2lMCjJyS1h6TUFsbFI2QzlSV01vTVozbitHNTdkYkxjZkNBYlRqd09VRHc1MjRVWUpEK2tuOFFhNHJybnhzdElZbVQKVDNGL21ybXZkeTNaNEdDNEZ6NlVDUEdFNzlVK3M1Zmg2SEN4ZlEzMXlFb250a3FocjVEUG5PL0xNK3VtVkxoMgpXUWplZzBrSGd3dkN3N1VaTlFSbG0rTHdidUhDNU9ZeUhtcFdYZ05lQkd2UGN5OWVHbVRyV1BINUJFTVZoYkp6Clgwa0dqWi9Lc1hjZWtnOGFWNG5KSE1SbGNJTE5FaFZjbUZWekZNOVBGTVBBakszMitXWWd0ektPak1rSGVsS1AKZDlNbFJHYnI0aTVLRnhZeHgyLzd3cmpSN09XZXg3ZnlmVmZhendJREFRQUJBb0lCQUQwYjUrYjZlay9qYWZtUgowNmtIdThwZ292ejBJajkwaUNaOW1WaXdWZFJDQ3haUmQrV29nKzlvWVdFNDM2MExjNE43eWdkOERVOFZiSmxLCjRySWxFNklQN0tTdlozUUpydzBjRXRkZzYxcUp4ajRRZFBlamVTL3ZwdzBvTjBXcGkzb2ZUT1M5K0RpRU4xNTgKMXU0N2dsRklzdFpNNVlvUnVUY2pkb2pRR0lxVVZtdjZ6eFozTnJRUmRJelNtTTlOYURTYzdxM1lJWC9VbC9DRgowZ1J5NU5pS3hYcjUvbUZlL1BFZUxMUElSWWtySit2ekVEcUtTUkJ3NnZmbm1tUzJwSE1EK05CQzhvSjIyU0pXCkM0QXFyYXVNYjZTMTdzSkx1dk9ueE5GZXl2OHJFdFRTZy9RNSszUnRKQS9Wb0YvM1ZWQW9uYSt0UjRNcldHcUwKTnFXUER4a0NnWUVBeDFwOURVQmNJNXJnR2VvLy82MUtBak1zSExHbTRYVXVlWk10ZmNlbXB3TUUzb3NZaHphdgpTYXoxY1J0VUtHTVd4eVhFekJtUmRVaWlOWUJMOVp2M3JQbVBCRVFDU3laalRDRUdid3hsWnJuY0M4QU5NcHVCCmJPa0daNkJNMTFMUVd2WHFHOVFWRzVUeFJzc2J0YXlyYVVJYXYyZWxpc2tZYUg0UXZhZDN2Yk1DZ1lFQS81KzcKNWttRStpNmlHbXZHaVh4cDJXSWFOS1hsRldiU21wTTNheldCRlJGZ1VtN2lwNm56TVVXb2FJUXNTT2dkYXVhMwppT1JMR1JFTTNBU0ppRU1mdUt4KzdQTmhacWZPdGFTdlVkWTRSZjVRNlU0QUJMN3g2bFMrdmZMSExEb1BQeTNBClRaV2xCcU9iREU5VXBELzQvSVRNcDd0NWwyeW1aVUVsTXl2bE9IVUNnWUVBaDVBYk5hV3NnbkhSTHc1Q2t3VXUKTEt6THRIK0NNaExUbGN6bHhJQzk3Umg2ZVRNeGJORmRCY2JkNlJwaWNreGZzdkVXRUl6YWcxenZJVjZyU012VQo4d1dKb2FiMXdGRE1lWHFEdTRROGVFeXZQRFpQUXpqSUhGMmlBMW5ZcHh3am41ZFdxYkhnNEs2NkhDQUdLZGJQCmdYWjRaZXgvZ0E4YjBBTGFNMzNzU1UwQ2dZRUFsZ2ZwbjdyczJtMytaS1YzRElEQ0czMlJ4ZTdNYXVoRG1jZm8KRWZ1QVBKNUxPM2FyZng2bmh2Yk1aak9WVG1FMXl1V0pPVVpNc1hTcGFJVWRONlcxKzR6Nm5oWW14N3FiLzA2ZQpPOWtRaER4RXZ2b3gxcGMvbzNxRHpUYXVJYzRkM3NYNmhVN2NZZTRxZFdvbVVwVGRqVkJnVWQ0ZCtuc2htbkpHCjVDYlNUWFVDZ1lCb2NzOEdXWmlERE4vVE5CRTRlTHNTckZIa3JNSWhWbCtURlBKalFjM052WjAyUXRhQXdpK1IKRElWSVd3bUcyNks0cy8rSW9VVC9CdjRGM3VzWDBVd1JVdnhNTDBETjV3bjBOWWw4VnplRWRPNW0zTkl6VVI3YQpWQWdlTDdjcjdSalNaS0lUd05aZXBpbTVSWS9lNUpyRmdSQzlJS0tsaTBiaTdLZEFIRGI2bXc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=

kubectl 执行命令时，是通过调用 kubeconfig 发起连接
    certificate-authority-data:           当前集群的 CA 根证书，用以确认对方发来的证书是不是 CA 根证书签发的
    server: https://192.168.66.11: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:               用户的证书
    client-key-data:                       用户私钥

（5）Pod 认证

1.Pod 类似公司外部访客，可能待半天就走

2.各组件类似公司长期员工，需要颁发工牌，凭牌入内

3.对 Pod 颁发工牌，工牌没发下来，访客可能已经走了，而且颁发工牌流失了会不安全，所以对 Pod 颁发的是 ServerAccount

Pod 中的容器需要访问 API Server。因为 Pod 的创建、销毁是动态的，所以要为它手动生成证书就不可行了。Kubernetes 使用了 Service Account 解决 Pod 访问 API Server 的认证问题（Calico、DNS 等 Pod 插件访问 API Server 获取集群信息做 DNS解析等）

9.2.3 ServiceAccount 组成

Kubernetes 设计了一种资源对象叫做 Secret，分为两类，一种是用于 ServiceAccount 的 service-account-token，另一种是用于保存用户自定义保密信息的 Opaque 。ServiceAccount 中用到包含是哪个部分：Token、ca.crt、namespace

　　token 是使用 API Serverr 私钥签名（私密亲密关系）的 JWT（A访问B，B不需要访问A，Pod 可能需要访问 API Server，API Server 不需要访问 Pod）。用于访问 API Server 时，Server 端认证

　　ca.crt 根证书。用于 Client 端验证 API Server 发送的证书（验证是否是 CA 根证书颁发的，是否安全）

　　namespace，标识这个 service-account-token 的作用域名空间（Pod 是名称空间级别，API Server 是集群级别，不同名称空间下 Pod 名可以重复，所以要标识出名称空间）

Json web token（JWT）是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（[(RFC 7519)]）,该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密

默认情况下，每个 namespace 都会有一个 ServiceAccount，如果 Pod 在创建时没有指定 ServiceAccount，默认使用 Pod 所属 namespace 下的 ServiceAccount

在 Pod 中默认挂载目录：/run/secrets/kubernetes.io/serviceaccount/

# 当创建 namespace 时，serviceaccounts 也随之创建
[root@k8s-master01 9]# kubectl create namespace test
namespace/test created
[root@k8s-master01 9]# kubectl get serviceaccounts -n test 
NAME      SECRETS   AGE
default   0         15s
# 每当 Pod 启动时 默认挂载 启动名称空间下的 serviceaccounts ，这样 Pod 就有访问 API Service 的权限了
[root@k8s-master01 9]# kubectl get pod -A|grep node
kube-system        calico-node-8nxzh                          1/1     Running   41 (71m ago)   30d
kube-system        calico-node-rgspt                          1/1     Running   40 (70m ago)   30d
kube-system        calico-node-rxwq8                          1/1     Running   41 (70m ago)   30d
[root@k8s-master01 9]# kubectl exec -it calico-node-8nxzh -n kube-system -- /bin/sh
Defaulted container "calico-node" out of: calico-node, upgrade-ipam (init), install-cni (init), mount-bpffs (init)
sh-4.4# cd /run/secrets/kubernetes.io/serviceaccount/
sh-4.4# ls -ltr
total 0
lrwxrwxrwx 1 root root 12 Jun 27 00:58 token -> ..data/token
lrwxrwxrwx 1 root root 16 Jun 27 00:58 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 13 Jun 27 00:58 ca.crt -> ..data/ca.crt
sh-4.4# cat token 
eyJhbGciOiJSUzI1NiIsImtpZCI6Ii0xX3QycUNZTnNMSFAwQTBPbExlSzRCOG5mb0tHb0lzUWdvVDF1NC1UVE0ifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzgyNTI0ODE1LCJpYXQiOjE3NTA5ODg4MTUsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsInBvZCI6eyJuYW1lIjoiY2FsaWNvLW5vZGUtOG54emgiLCJ1aWQiOiJmZGRmODg5Zi1kODkzLTRiMmYtYmZjOC1iOGNhMTk3YTlhZDEifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImNhbGljby1ub2RlIiwidWlkIjoiM2ZhZDRhNWEtMzViYi00NmZjLWIyM2QtMzA1NTcwZGRiZjJjIn0sIndhcm5hZnRlciI6MTc1MDk5MjQyMn0sIm5iZiI6MTc1MDk4ODgxNSwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmNhbGljby1ub2RlIn0.rbcaQ0v5NW88obpD7oLkatnfLMaM7dr4HsXoX0tzTltZlFiyegP0ZK8LMiWRbiembW4xKenx18wW9s3pJWnEo6ftO6c5WH0DjoZ0Yg-G8C4-CByq8MujzpZLcJQlyA8348s4PHH4MO3S7I9dq-UVvTmoRHoMFZh99q4ATVxuIkS-auLrDwb0Z1cayjatOmdyjR15seep8ye7e2w3zz8sl7IpNWZSih6hYuc9ASmJDUfzsChEy6wuThhsGX4G2Gs2DfKGkWMJjjxIFbx5ltLnY12pR8c1J1G3Bv2u9b367iI6r_IQTbNYbMwj1JW8Hll0jhyUf-4oKstDrZvzlswTpAsh-4.4# 
sh-4.4# cat ca.crt 
-----BEGIN CERTIFICATE-----
MIIDBTCCAe2gAwIBAgIIDkwhqOyGZcEwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
AxMKa3ViZXJuZXRlczAeFw0yNTA1MjcxODE5NDhaFw0zNTA1MjUxODI0NDhaMBUx
EzARBgNVBAMTCmt1YmVybmV0ZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDBP3k8pi7BWwaz9n3VMLzunZ1UuTAPETKNkYRE+pEfRhP/KuaZnnObHL39
MZtfWXyLPm9lA7Iq09PEfMGPX7St7+HIHIsr8gx35PY3Kof7IxzAjGHRfzrAjo7y
XXbdjZJdMsLgCoBimb+qpaypJ3eAtVlE6pXiaE+Q036qR7rf4DIjD5FU5gx6EouX
MSp9Fc0HH/8gB0JhVRKCBJBAArgoS3CB4YMyrcltLwdlhd6xeAKyuaGmt7G65zlP
7CPZdP9GLzX3Y3nraQL3Q1vJJ0m2i1OOe9MvTNuN9/0a53/iXU2Z+NKaV2/+E9nL
DtVeqN75hG+YNudSH26kxe6Vb1RnAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwICpDAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBR0lTh4c0JIErdE0BfeodIRYDfMEzAV
BgNVHREEDjAMggprdWJlcm5ldGVzMA0GCSqGSIb3DQEBCwUAA4IBAQCdbJ7ipycr
QBex9RG+mdHnn0RMtXosVCKFx4ze4JxrUofxlursOjXEk0XU+vVsb+66Tey0QdF9
gElCpXaP9zJg1HQSq2KXb6HRmqc5eh9tYnoUAps46rkD7lZj6MqT75iznjEWika6
uc//uh4PDxzsCf/2kbbW/i0YJ1155pLA0EFXSGy8fpJFysxmzikaQtaLpFysHxq7
SL1+OPVZC47APOoH4eeW3t1UfaVom1NWLdpClDdl9IX9GKbpxvMpxclzKXV+mAn9
thsFcBHYoOnhtC19976XBr+tWFv5m2Zg67twY12hF87nDIe7TpBUdc0/sZSuKlok
WM7BLBANz/2r
-----END CERTIFICATE-----
sh-4.4# cat namespace 
kube-systemsh-4.4# exit
exit

9.2.4 ServiceAccount 总结

1.集群中有 Pod 和 K8s组件需要被 API Servers 认证

2.组件认证中 kubectl、kube-proxy 没办法确认安全性，因此需要手动签发，kubelet 在添加到集群内时，做过双向认证，确定了安全性，因此集群自动对其签发证书

3.组件拿到证书后，封装成 kubeconfig 文件，以此发起对 API Server 的访问和双向认证

4.Pod 具有动态性，会创建和销毁，颁发证书不够灵活且不安全，因此 Pod 获取自己名称空间下 Service Account，启动时挂载 SA，拥有token、ca.crt、namespace等信息后，以此发起对 API Server 的访问和双向认证

9.3 鉴权

——— 是自己人，但是有权限吗？

9.3.1 鉴权类型

认证过程只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限。API Server 目前支持以下几种授权策略（通过 API Server 的启动参数 “--authorization-mode” 设置）

　　AlwaysDeny：表示拒绝所有的请求，一般用于测试

　　AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略（大门常打开，不可取）

　　ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制（类似 Linux 基于用户、用户组的授权方式，需要授权多次）

　　Webhook：通过调用外部 REST 接口服务对用户进行授权

　　RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则（用户关联角色，角色关联权限）

9.3.2 RBAC 特性优势

RBAC（Role-Based Access Control）：基于角色的访问控制，在 Kubernetes 1.5 中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：

　　对集群中的资源和非资源均拥有完整的覆盖（有权利进行对应调整）

　　整个 RBAC 完全由几个 API 对象完成，同其它 API 对象一样，可以用 kubectl 或 API 进行操作（利于对平台二次开发）

　　可以在运行时进行调整配置文件，无需重启 API Server（支持热加载）

9.3.3 RBAC 资源对象

RBAC 引入了 4 个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4种对象类型均可以通过 kubectl 与 API 操作

名称空间级别：Role、RoleBinding

集群级别：ClusterRole、ClusterRoleBinding

1.将资源对象的创建、获取、更新绑定成角色Role，角色再被角色绑定RoleBinding 所绑定给用户

2.角色绑定分配给用户 User、用户组 Group、认证 ServiceAccount，对应的用户就有对应权限了

9.3.4 RBAC 绑定关系

不同角色Role、集群角色ClusterRole 可以绑定不同权限：

第一种：用户 User、认证 ServiceAccount 只需要使用 Rolebinding+namespace 绑定后端对应有权限的 角色Role ，就可以实现用户对应角色Role 的功能（名称空间级别需要加名称空间 namespace）

第二种：用户组 Group 只需要使用 ClusterRolebinding 绑定后端对应有权限的 集群角色ClusterRole ，就可以实现用户组对应集群角色CluseterRole 的功能（集群级别不需要加名称空间namespace）

第三种：用户 User、认证 ServiceAccount 使用 Rolebinding+namespace 绑定后端对应有权限的 集群角色ClusterRole 可以实现用户对应角色Role 的功能（降维作用）

1.当只使用第一种：Rolebinding + namespace 这种情况，当有 A、B、C、D 四个名称空间，需要创建四个用户，四个角色Role 与之绑定（12个资源对象、4 Role、4 binding、4 用户）

2.创建集群角色ClusterRole ，如果使用 ClusterRolebinding 绑定用户，那 A、B、C、D 将拥有集群角色的权利，导致权限溢出

3.如果是 集群角色ClusterRole 使用 Rolebinding+namespace 去绑定用户 A、B、C、D ，相当于用户使用集群角色但要在对应 namespace 下才有对应的权利（校长权利大，但是关到某个班级，只能管某个班）

4.节省了创建的资源对象（9个资源对象、1 ClusterRole、4 binding、4 用户）

组件发起基于 HTTPS 的双向认证，客户端向服务端发起证书，发起前证书的某一部分可以当做用户名、组，并用集群 API-Server 信任的 CA 盖章形成一个文件，就可以和 API-Server 形成验证。（在制作证书时，可以标识用户或组，再被集群认可的CA签发证书）

9.3.5 RBAC 用户创建

（1）用户哪里来

cfssl 可以通过模板，指定对应的 CA 证书，就可以签发被此CA信任的证书
CN: 用户名
hosts: 证书可访问地址（可访问证书的客户端IP，空，都可访问，填写地址 固定IP才可访问）
names.O: 用户组

（2）Role

在 RBAC API 中，Role 表示一组规则权限，权限只会增加（累加权限，初始权利为 0），不存在一个资源一开始就有很多权限而通过 RBAC 对其进行减少的操作；角色Role 可以定义在一个 namespace 中，如果想要跨 namespace 则必须创建集群角色ClusterRole

1.类别：Role 类
2.接口组版本：rbac.authorization.k8s.io/v1beta1
3.元数据：角色Role 所在名称空间名（Role 是名称空间级别，必须指定名称空间，不指定默认 default）、Role 名
4.规则：接口组版本（空，代表核心组 v1 版）、资源对象（需复数 pods ）、动作类别（对 Pods 具有 获取get、监听资源变化watch、列出list 三种类型）

（3）ClusterRole

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

　　集群级别的资源控制（例如 node 访问权限）（级别高可以控制级别低，级别低不可以控制级别高，集群级别可以控制命名空间，命名空间不可以控制集群级别）

　　非资源型 endpoints 资源控制（例如 /health 访问）（endpoints 可以跨集群连接外部mysql）

　　所有命名空间资源控制（例如 pods）（级别高对级别低的控制）

1.类别：ClusterRole 类
2.接口组版本：rbac.authorization.k8s.io/v1beta1版本
3.元数据：ClusterRole 名（集群角色不需要声明命名空间！）
4.规则：接口组：核心组v1（默认为空，即v1版本）、资源类别：secrets、动作类型：获取、监听资源变化、列出

（4）RoleBinding + Role

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

1.类别：RoleBinding
2.接口组版本：rbac.authorization.k8s.io/v1beta1版本
3.元数据：rolebinding 名、所在名称空间（名称空间级别，必须要有名称空间）
4.绑定附着点：绑定类别：user、用户名：jane、接口组版本：rbac.authorization.k8s.io
5.角色来源：角色类型、角色名、接口组版本
整体意为：jane 用户在 default 名称空间下，使用 pod-reader 角色 可以对pod 做 获取get、展示资源watch、列出list 动作，基于 核心版v1 接口

（5）RoleBinding + ClusterRole

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

1.类别： RoleBinding
2.接口组版本：rbac.authorization.k8s.io/v1beta1
3.元数据：RoleBinding 名、RoleBinding 所在名称空间
4.权利附着点：类别：用户、用户名：dave、用户组：rbac.authorization.k8s.io
5.角色来源：类别：ClusterRole 集群角色、集群角色名、
虽然是 集群角色ClusterRole，但是做的是 角色绑定RoleBinding，原集群角色被限制在了 dev 名称空间下，被 dave 用户所使用

（6）ClusterRoleBinding + ClusterRole

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

1.类别：ClusterRoleBinding
2.接口组版本：rabc.authorization.k8s.io 组 v1beta1 版本
3.元数据：ClusterRoleBinding 名（集群绑定，不需要写名称空间）
4.绑定对象：类别：用户组、用户组名：manager、接口组版本：rbac.authorization.k8s.io
5.角色来源：类别：ClusterRole、角色名：、接口组版本：rbac.authorization.k8s.io
整体意思：manager 组在任意名称空间下或当前集群对 secret-reader 发起 查询get 动作

9.3.6 Resources 子资源

Kubernetes 集群内一些资源一般以其名称字符串来表示，这些字符串一般会在 API 的 URL 地址中出现，同时某些资源也会包含子资源（类似 pod.log、pod.pid、pod.network），例如 logs 资源就属于 pods 的子资源，API 中 URL 样例如下

# 主要控制是否有权利对以下类似的 URL 发起访问
GET /api/v1/namespaces/{namespaceName}/pods/{PodName}/log

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

1.类别：Role
2.接口组版本：rbac.authorization.k8s.io 组 v1beta1 版本
3.元数据：Role 所在名称空间、Role 名
4.规则：核心组 V1 版接口动作、资源对象：pods/log（只能访问 pod 的l og 接口）、动作类别：获取get、列出list

9.3.7 Subjects 对象（权利附着点）

RoleBinding 和 ClusterRoleBinding 可以将 Role 绑定到 Subjects；Subjects 可以是组groups、用户users 或者 service accounts

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

Groups 书写格式与 Users 相同，都为一个字符串，并且没有特定的格式要求；同样 system: 前缀为系统保留（类似 Linux 中 nobody 用户，系统内部执行权限或调用就是使用的此用户）

9.3.8 创建一个用户只能管理 dev 名字空间（资源分割）

创建证书 > 转换为 kubeconfig 文件 > 创建名字空间 > 角色绑定

（1）创建证书

用户创建无法使用 kubectl create user 命令创建，所以要先创建证书并被 API Server 信任的 CA 签发

# 进入到 API-Server 通信的密钥的目录
[root@k8s-master01 9]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# ls -ltr
total 56
-rw------- 1 root root 1679 May 28 02:24 ca.key
-rw-r--r-- 1 root root 1107 May 28 02:24 ca.crt
-rw------- 1 root root 1675 May 28 02:24 apiserver.key
-rw-r--r-- 1 root root 1289 May 28 02:24 apiserver.crt
-rw------- 1 root root 1679 May 28 02:24 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1176 May 28 02:24 apiserver-kubelet-client.crt
-rw------- 1 root root 1679 May 28 02:24 front-proxy-ca.key
-rw-r--r-- 1 root root 1123 May 28 02:24 front-proxy-ca.crt
-rw------- 1 root root 1675 May 28 02:24 front-proxy-client.key
-rw-r--r-- 1 root root 1119 May 28 02:24 front-proxy-client.crt
drwxr-xr-x 2 root root  162 May 28 02:24 etcd
-rw------- 1 root root 1679 May 28 02:24 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1123 May 28 02:24 apiserver-etcd-client.crt
-rw------- 1 root root  451 May 28 02:24 sa.pub
-rw------- 1 root root 1679 May 28 02:24 sa.key
[root@k8s-master01 pki]# cat devuser.json 
{
 "CN": "devuser",
 "hosts": [],
 "key": {
   "algo": "rsa",
   "size": 2048
  },
 "names": [
    {
     "C": "CN",
     "ST": "BeiJing",
     "L": "BeiJing",
     "O": "k8s",
     "OU": "System"
    }
  ]
}
# cfssl 是一个工具集，三个的下载地址
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
# 将 cfssl 工具集命令放到默认可执行目录下添加权限，输入 cfssl + Tab 输出提示命令，安转完成
[root@k8s-master01 pki]# ls -ltr
total 18868
-rw-r--r-- 1 root root  2277873 Sep 28  2020 cfssljson
-rw-r--r-- 1 root root  6595195 Sep 28  2020 cfssl-certinfo
-rw-r--r-- 1 root root 10376657 Sep 28  2020 cfssl
..........
[root@k8s-master01 pki]# mv cfssl* /usr/local/bin/
[root@k8s-master01 pki]# chmod a+x /usr/local/bin/cfssl*
[root@k8s-master01 pki]# cfssl
cfssl           cfssl-certinfo  cfssljson 
# 指定当前 ca根证书、指定当前 ca 私钥、指定当前导出文件给谁使用、指定当前证书如何描述创建、当前证书头部信息
[root@k8s-master01 pki]# cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes devuser.json | cfssljson -bare devuser
2025/06/30 12:10:03 [INFO] generate received request
2025/06/30 12:10:03 [INFO] received CSR
2025/06/30 12:10:03 [INFO] generating key: rsa-2048
2025/06/30 12:10:03 [INFO] encoded CSR
2025/06/30 12:10:03 [INFO] signed certificate with serial number 587875083199070826796435116458259501711848762321
2025/06/30 12:10:03 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").
# devuser.csr 证书请求文件、devuser.pem devuser 用户证书、devuser-key.pem 用户私钥
[root@k8s-master01 pki]# ls -ltr
total 72
..........
-rw-r--r-- 1 root root  209 Jun 30 11:56 devuser.json
-rw-r--r-- 1 root root 1281 Jun 30 12:10 devuser.pem
-rw-r--r-- 1 root root  997 Jun 30 12:10 devuser.csr
-rw------- 1 root root 1675 Jun 30 12:10 devuser-key.pem

（2）将证书转换成 kubeconfig 文件

kubectl 连接集群进行认证、鉴权，就是在使用 kubeconfig 文件中的信息

# 设置集群参数
[root@k8s-master01 pki]# export KUBE_APISERVER="https://192.168.66.11:6443"
# 设定当前集群，集群名：kubernetes、指定当前集群 CA的根证书、对证书进行验证、服务器端地址、保存到的 kubeconfig文件名
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --certificate-authority=ca.crt --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=devuser.kubeconfig
Cluster "kubernetes" set.
[root@k8s-master01 pki]# ls -ltr
total 76
........
-rw-r--r-- 1 root root  209 Jun 30 11:56 devuser.json
-rw-r--r-- 1 root root 1281 Jun 30 12:10 devuser.pem
-rw-r--r-- 1 root root  997 Jun 30 12:10 devuser.csr
-rw------- 1 root root 1675 Jun 30 12:10 devuser-key.pem
-rw------- 1 root root 1679 Jun 30 12:57 devuser.kubeconfig
[root@k8s-master01 pki]# cat devuser.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJRGt3aHFPeUdaY0V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TlRBMU1qY3hPREU1TkRoYUZ3MHpOVEExTWpVeE9ESTBORGhhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURCUDNrOHBpN0JXd2F6OW4zVk1MenVuWjFVdVRBUEVUS05rWVJFK3BFZlJoUC9LdWFabm5PYkhMMzkKTVp0ZldYeUxQbTlsQTdJcTA5UEVmTUdQWDdTdDcrSElISXNyOGd4MzVQWTNLb2Y3SXh6QWpHSFJmenJBam83eQpYWGJkalpKZE1zTGdDb0JpbWIrcXBheXBKM2VBdFZsRTZwWGlhRStRMDM2cVI3cmY0RElqRDVGVTVneDZFb3VYCk1TcDlGYzBISC84Z0IwSmhWUktDQkpCQUFyZ29TM0NCNFlNeXJjbHRMd2RsaGQ2eGVBS3l1YUdtdDdHNjV6bFAKN0NQWmRQOUdMelgzWTNucmFRTDNRMXZKSjBtMmkxT09lOU12VE51TjkvMGE1My9pWFUyWitOS2FWMi8rRTluTApEdFZlcU43NWhHK1lOdWRTSDI2a3hlNlZiMVJuQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJSMGxUaDRjMEpJRXJkRTBCZmVvZElSWURmTUV6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ2RiSjdpcHljcgpRQmV4OVJHK21kSG5uMFJNdFhvc1ZDS0Z4NHplNEp4clVvZnhsdXJzT2pYRWswWFUrdlZzYis2NlRleTBRZEY5CmdFbENwWGFQOXpKZzFIUVNxMktYYjZIUm1xYzVlaDl0WW5vVUFwczQ2cmtEN2xaajZNcVQ3NWl6bmpFV2lrYTYKdWMvL3VoNFBEeHpzQ2YvMmtiYlcvaTBZSjExNTVwTEEwRUZYU0d5OGZwSkZ5c3htemlrYVF0YUxwRnlzSHhxNwpTTDErT1BWWkM0N0FQT29INGVlVzN0MVVmYVZvbTFOV0xkcENsRGRsOUlYOUdLYnB4dk1weGNsektYVittQW45CnRoc0ZjQkhZb09uaHRDMTk5NzZYQnIrdFdGdjVtMlpnNjd0d1kxMmhGODduREllN1RwQlVkYzAvc1pTdUtsb2sKV003QkxCQU56LzJyCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.66.11:6443
  name: kubernetes
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null

# 设置客户端认证参数
# 设置凭据给 dev 用户、指定当前用户的证书、用户的私钥、证书验证确认、保存的文件名
[root@k8s-master01 pki]# kubectl config set-credentials devuser --client-certificate=devuser.pem --client-key=devuser-key.pem --embed-certs=true --kubeconfig=devuser.kubeconfig
User "devuser" set.
[root@k8s-master01 pki]# cat devuser.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJRGt3aHFPeUdaY0V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TlRBMU1qY3hPREU1TkRoYUZ3MHpOVEExTWpVeE9ESTBORGhhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURCUDNrOHBpN0JXd2F6OW4zVk1MenVuWjFVdVRBUEVUS05rWVJFK3BFZlJoUC9LdWFabm5PYkhMMzkKTVp0ZldYeUxQbTlsQTdJcTA5UEVmTUdQWDdTdDcrSElISXNyOGd4MzVQWTNLb2Y3SXh6QWpHSFJmenJBam83eQpYWGJkalpKZE1zTGdDb0JpbWIrcXBheXBKM2VBdFZsRTZwWGlhRStRMDM2cVI3cmY0RElqRDVGVTVneDZFb3VYCk1TcDlGYzBISC84Z0IwSmhWUktDQkpCQUFyZ29TM0NCNFlNeXJjbHRMd2RsaGQ2eGVBS3l1YUdtdDdHNjV6bFAKN0NQWmRQOUdMelgzWTNucmFRTDNRMXZKSjBtMmkxT09lOU12VE51TjkvMGE1My9pWFUyWitOS2FWMi8rRTluTApEdFZlcU43NWhHK1lOdWRTSDI2a3hlNlZiMVJuQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJSMGxUaDRjMEpJRXJkRTBCZmVvZElSWURmTUV6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ2RiSjdpcHljcgpRQmV4OVJHK21kSG5uMFJNdFhvc1ZDS0Z4NHplNEp4clVvZnhsdXJzT2pYRWswWFUrdlZzYis2NlRleTBRZEY5CmdFbENwWGFQOXpKZzFIUVNxMktYYjZIUm1xYzVlaDl0WW5vVUFwczQ2cmtEN2xaajZNcVQ3NWl6bmpFV2lrYTYKdWMvL3VoNFBEeHpzQ2YvMmtiYlcvaTBZSjExNTVwTEEwRUZYU0d5OGZwSkZ5c3htemlrYVF0YUxwRnlzSHhxNwpTTDErT1BWWkM0N0FQT29INGVlVzN0MVVmYVZvbTFOV0xkcENsRGRsOUlYOUdLYnB4dk1weGNsektYVittQW45CnRoc0ZjQkhZb09uaHRDMTk5NzZYQnIrdFdGdjVtMlpnNjd0d1kxMmhGODduREllN1RwQlVkYzAvc1pTdUtsb2sKV003QkxCQU56LzJyCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.66.11:6443
  name: kubernetes
contexts: null
current-context: ""
kind: Config
preferences: {}
users:
- name: devuser
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURoRENDQW15Z0F3SUJBZ0lVWnZrNi9qbG0wQkZJTjBaVEhhWG5LV1hCNjlFd0RRWUpLb1pJaHZjTkFRRUwKQlFBd0ZURVRNQkVHQTFVRUF4TUthM1ZpWlhKdVpYUmxjekFlRncweU5UQTJNekF3TkRBMU1EQmFGdzB5TmpBMgpNekF3TkRBMU1EQmFNR0l4Q3pBSkJnTlZCQVlUQWtOT01SQXdEZ1lEVlFRSUV3ZENaV2xLYVc1bk1SQXdEZ1lEClZRUUhFd2RDWldsS2FXNW5NUXd3Q2dZRFZRUUtFd05yT0hNeER6QU5CZ05WQkFzVEJsTjVjM1JsYlRFUU1BNEcKQTFVRUF4TUhaR1YyZFhObGNqQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUsxdAp1OFdYU25IbUg3UzlRUXFReExqVFlhY1hqNEhHdE9sbWluLy8wRDMwYjN6WmFZaUJheEcyekFTNE1WRUhORFJpCjB2OVFzYkdqWHllME9VRER0TzYzaHhPaERhN0lLSWhPNWF0VDcrWjdtNC9UclBSa2xhZDNsbmVselgrbjVJdnUKbVJQSUxDcEY1VVpFYVdsVE9wdlNyWHFxc0lPeTJvbW5GWmVjNnFFR2F4aDVISnl4OE9tUkpkRlNLLzJ5NXdyOQpwNXQvREVHeVRyVU5UM2JFeVVVR1paSFRhVTZzQ1RIZnF4cGMzSlJ1MWJRcFY3cSs1VmhsNUU5dXJrNEdaQ1RLCkVUV2IvcUZ3VFd0YjdoaUlTUUxzU2JOL1Ixa250cmFqQmphNzNUczR6N0pFTUZtdWhpRTkyZ2tndExQcEpNc3MKcmk1Nk0yL0N0Wnk1bVNrdG1oRUNBd0VBQWFOL01IMHdEZ1lEVlIwUEFRSC9CQVFEQWdXZ01CMEdBMVVkSlFRVwpNQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNEQWpBTUJnTlZIUk1CQWY4RUFqQUFNQjBHQTFVZERnUVdCQlRDCkxRaS9NR3k0NjB6N1E5UnN3dGYyOEkyNldqQWZCZ05WSFNNRUdEQVdnQlIwbFRoNGMwSklFcmRFMEJmZW9kSVIKWURmTUV6QU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUF2eEpPRU90YjV4R0tjcEUwN25UOHYxdWdiT3RLUlNIRAo3RDZWY2ltVVhVWDJvWi9WSVcyRXMrTGlZSFVJekNvYTU5MnN2alRaMVMwMUNFZkpxVWVKbkg4QWlQakVFQi91CmtCWDAzcjl5YjZNQ1RRbHc4Vm1TcjlMUmZjMW5mZlBJNHpSRjFtaVVNTHZhR2cySlVlTEp0Nmp0QWR3c1BhM0gKQURPZ3cvcnI5SWxNQm4rRXBHUllIS2VCRklVTThPYVVZVEo4YTBwYjQySWxTRkdyaXMzbGFvVEVSRWhLSTVpRApSQ0EzUGV6amllaytBT1dReHZxbEtqTHQ3eWVlYStxcWRYZ0xFZmtUdU5hSTh4T2pxQVVWbnMvVGE1WGNDamFTCjRBdEYwUHBhczhMZmhqSHZTSG02K2FsVUYyMlBSMVl1ZkgzSkVrc3pYR3dUN1l2UTNjSDdJdz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBclcyN3haZEtjZVlmdEwxQkNwREV1Tk5ocHhlUGdjYTA2V2FLZi8vUVBmUnZmTmxwCmlJRnJFYmJNQkxneFVRYzBOR0xTLzFDeHNhTmZKN1E1UU1PMDdyZUhFNkVOcnNnb2lFN2xxMVB2NW51Ymo5T3MKOUdTVnAzZVdkNlhOZjZma2krNlpFOGdzS2tYbFJrUnBhVk02bTlLdGVxcXdnN0xhaWFjVmw1enFvUVpyR0hrYwpuTEh3NlpFbDBWSXIvYkxuQ3Yybm0zOE1RYkpPdFExUGRzVEpSUVpsa2ROcFRxd0pNZCtyR2x6Y2xHN1Z0Q2xYCnVyN2xXR1hrVDI2dVRnWmtKTW9STlp2K29YQk5hMXZ1R0loSkF1eEpzMzlIV1NlMnRxTUdOcnZkT3pqUHNrUXcKV2E2R0lUM2FDU0Mwcytra3l5eXVMbm96YjhLMW5MbVpLUzJhRVFJREFRQUJBb0lCQUdMRG5TMTNiUlBVSTdaQQpHT3cxYVhLQUhwcVRsa3ducHh0TUpBK2sxU2lUTFhLQ05kRmhNbUpTSVhtR2s3ODdSUVdZU2VUUVJZR09Na0JnCktFS3pzVFJKSEFtWHJEMGZDOFlrZURMTGlGRlBqMVduREZYWmVraDJtQi9uTWxKQ2dLc1g0K0VhRzl5dkZWU2cKM1E3NE1PWlFZaTc3U2E2V2lsSGQ3elA2VHJ3SUJhWTA1OVpjbGp0ejZ5N2Z2UFk1a0VWRVlzKy9aQmJCbk1sMApjK1RLRld5VUppbDBzeTB4SnVxY09lWEZoeXV0eng5bnZmdlB3RmRzL0U0bmMyUmRXOXFtSHVCaVhjTjJxUWtoCjM1aWdIRXZGN0ZKM1RNOThFK3RXRTVUVVptUElYTXNIWHc2aW1ad3Q0VDVLMTJScWg2elBuejA5QitTZU4vY2gKWDRKSkRBRUNnWUVBemxyNW0wRmNZaEVwMGIzWnZpQ3FpV0NZS24yVUllZVlMQ3VNWUxmMlFIbGNacWRIaGw5dgpncERVdXA5ZEswaW1tOTJtOEVJa0FndG51Q2Z4L2Y4K0hPU0JqSlZXWExtYURHd28yMG4xYWl0SnFNMnN3M2lUClcvUXRvUFFTK3BSVWZ2cFdnSVVpczNRTkZROWdMQnY1Qlk2Q0o5M1FTTjFjQ3VrT01EYlhkU0VDZ1lFQTF5YmQKblJLMHNQMkMwTnFJVkhpSEYvRllBTUlaUWVwekhheG9tYnkveVJwbHJEemc3NytRQkFEdFJzK0pMQ0x2Z3BRYgpMVkpZbVdzNEh2Mk5LdXl0TWxTV05Yc1pwbXVPL3pEZUpya0NwR0FGeU9sclRXL2oyMmJLdTFMZ0F1NGdhWEY3CnJCWEhucmdyTkNZVGFLei9ENCt4NnlkTS9sUXY1aFJxcDR2WGx2RUNnWUFReFJmdjVCbnI1bFV0dEc0VG8zZjQKZmg4ZnBPRDYrR1ZIZ2FxQTJiSnJmdkZoYmtyRHd0Ry9IS0lOSUpKanlCMnlJUXRHRHpuNTZJOWZTZS9Db3BHYgpxMzVUdkhjdVJlOGMvMVU2clFJQ3hNM1JxQlZZTlY1VVpMMm9qTzFWNitRS0JiSXQ4NlBrVFpRYW1BdEt5bU1zCmJtNXBhdjlZVEpVRVZmaFBOc1cvd1FLQmdDeFZGZFVIeGJPeWlRSUFCWmRpUG5Qd2h2R2hEUk5IKy9CaFZpeFgKZUMwNEF6czZVQjhXbWRZNVdxcjhtSWMvcTVwOGFoMHNtcFVDUXM0ZjhMYW5qZ2lRNVdLZnV1bFB3R2RVNm5HUQpMYnN4RGdBWUdNUWNDaGRyVnRyQ2VPWWhxd3dQRml5ZlVFS2tNRUxPbGJFNzlGS0FpV2lxOEhKM1ptZENUYmU0CldQUUJBb0dBSXd0aTlKVHFhNDhDZ1lmUzh2cWRMQ3p4Snp2VnFqWnYwVlRkVGZVd1UzS0thNkhXWWRONW1vSFIKWHpQaHdFYjNjSC90azAvRHFFMjlocG10Um5sYUs1OUxvK2JFb3Y1U3FHVzZFblZrN3VaRVZWM1BwQ2YwMlpScwo4ZWdGem5aQU50ekxOemJVSXltdzFRZE5xZWxCdExLeEhWUGg5N1lVdkZ6anZhNndsWEU9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

# 设置上下文参数
# 设置山下文名称 kubernetes、集群 kubernetes、用户、用户默认名字空间、保存的文件名
[root@k8s-master01 pki]# kubectl config set-context kubernetes --cluster=kubernetes --user=devuser --namespace=dev --kubeconfig=devuser.kubeconfig
Context "kubernetes" created.
[root@k8s-master01 pki]# cat devuser.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJRGt3aHFPeUdaY0V3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TlRBMU1qY3hPREU1TkRoYUZ3MHpOVEExTWpVeE9ESTBORGhhTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLCkFvSUJBUURCUDNrOHBpN0JXd2F6OW4zVk1MenVuWjFVdVRBUEVUS05rWVJFK3BFZlJoUC9LdWFabm5PYkhMMzkKTVp0ZldYeUxQbTlsQTdJcTA5UEVmTUdQWDdTdDcrSElISXNyOGd4MzVQWTNLb2Y3SXh6QWpHSFJmenJBam83eQpYWGJkalpKZE1zTGdDb0JpbWIrcXBheXBKM2VBdFZsRTZwWGlhRStRMDM2cVI3cmY0RElqRDVGVTVneDZFb3VYCk1TcDlGYzBISC84Z0IwSmhWUktDQkpCQUFyZ29TM0NCNFlNeXJjbHRMd2RsaGQ2eGVBS3l1YUdtdDdHNjV6bFAKN0NQWmRQOUdMelgzWTNucmFRTDNRMXZKSjBtMmkxT09lOU12VE51TjkvMGE1My9pWFUyWitOS2FWMi8rRTluTApEdFZlcU43NWhHK1lOdWRTSDI2a3hlNlZiMVJuQWdNQkFBR2pXVEJYTUE0R0ExVWREd0VCL3dRRUF3SUNwREFQCkJnTlZIUk1CQWY4RUJUQURBUUgvTUIwR0ExVWREZ1FXQkJSMGxUaDRjMEpJRXJkRTBCZmVvZElSWURmTUV6QVYKQmdOVkhSRUVEakFNZ2dwcmRXSmxjbTVsZEdWek1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQ2RiSjdpcHljcgpRQmV4OVJHK21kSG5uMFJNdFhvc1ZDS0Z4NHplNEp4clVvZnhsdXJzT2pYRWswWFUrdlZzYis2NlRleTBRZEY5CmdFbENwWGFQOXpKZzFIUVNxMktYYjZIUm1xYzVlaDl0WW5vVUFwczQ2cmtEN2xaajZNcVQ3NWl6bmpFV2lrYTYKdWMvL3VoNFBEeHpzQ2YvMmtiYlcvaTBZSjExNTVwTEEwRUZYU0d5OGZwSkZ5c3htemlrYVF0YUxwRnlzSHhxNwpTTDErT1BWWkM0N0FQT29INGVlVzN0MVVmYVZvbTFOV0xkcENsRGRsOUlYOUdLYnB4dk1weGNsektYVittQW45CnRoc0ZjQkhZb09uaHRDMTk5NzZYQnIrdFdGdjVtMlpnNjd0d1kxMmhGODduREllN1RwQlVkYzAvc1pTdUtsb2sKV003QkxCQU56LzJyCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.66.11:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: dev
    user: devuser
  name: kubernetes
current-context: ""
kind: Config
preferences: {}
users:
- name: devuser
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURoRENDQW15Z0F3SUJBZ0lVWnZrNi9qbG0wQkZJTjBaVEhhWG5LV1hCNjlFd0RRWUpLb1pJaHZjTkFRRUwKQlFBd0ZURVRNQkVHQTFVRUF4TUthM1ZpWlhKdVpYUmxjekFlRncweU5UQTJNekF3TkRBMU1EQmFGdzB5TmpBMgpNekF3TkRBMU1EQmFNR0l4Q3pBSkJnTlZCQVlUQWtOT01SQXdEZ1lEVlFRSUV3ZENaV2xLYVc1bk1SQXdEZ1lEClZRUUhFd2RDWldsS2FXNW5NUXd3Q2dZRFZRUUtFd05yT0hNeER6QU5CZ05WQkFzVEJsTjVjM1JsYlRFUU1BNEcKQTFVRUF4TUhaR1YyZFhObGNqQ0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUsxdAp1OFdYU25IbUg3UzlRUXFReExqVFlhY1hqNEhHdE9sbWluLy8wRDMwYjN6WmFZaUJheEcyekFTNE1WRUhORFJpCjB2OVFzYkdqWHllME9VRER0TzYzaHhPaERhN0lLSWhPNWF0VDcrWjdtNC9UclBSa2xhZDNsbmVselgrbjVJdnUKbVJQSUxDcEY1VVpFYVdsVE9wdlNyWHFxc0lPeTJvbW5GWmVjNnFFR2F4aDVISnl4OE9tUkpkRlNLLzJ5NXdyOQpwNXQvREVHeVRyVU5UM2JFeVVVR1paSFRhVTZzQ1RIZnF4cGMzSlJ1MWJRcFY3cSs1VmhsNUU5dXJrNEdaQ1RLCkVUV2IvcUZ3VFd0YjdoaUlTUUxzU2JOL1Ixa250cmFqQmphNzNUczR6N0pFTUZtdWhpRTkyZ2tndExQcEpNc3MKcmk1Nk0yL0N0Wnk1bVNrdG1oRUNBd0VBQWFOL01IMHdEZ1lEVlIwUEFRSC9CQVFEQWdXZ01CMEdBMVVkSlFRVwpNQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNEQWpBTUJnTlZIUk1CQWY4RUFqQUFNQjBHQTFVZERnUVdCQlRDCkxRaS9NR3k0NjB6N1E5UnN3dGYyOEkyNldqQWZCZ05WSFNNRUdEQVdnQlIwbFRoNGMwSklFcmRFMEJmZW9kSVIKWURmTUV6QU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUF2eEpPRU90YjV4R0tjcEUwN25UOHYxdWdiT3RLUlNIRAo3RDZWY2ltVVhVWDJvWi9WSVcyRXMrTGlZSFVJekNvYTU5MnN2alRaMVMwMUNFZkpxVWVKbkg4QWlQakVFQi91CmtCWDAzcjl5YjZNQ1RRbHc4Vm1TcjlMUmZjMW5mZlBJNHpSRjFtaVVNTHZhR2cySlVlTEp0Nmp0QWR3c1BhM0gKQURPZ3cvcnI5SWxNQm4rRXBHUllIS2VCRklVTThPYVVZVEo4YTBwYjQySWxTRkdyaXMzbGFvVEVSRWhLSTVpRApSQ0EzUGV6amllaytBT1dReHZxbEtqTHQ3eWVlYStxcWRYZ0xFZmtUdU5hSTh4T2pxQVVWbnMvVGE1WGNDamFTCjRBdEYwUHBhczhMZmhqSHZTSG02K2FsVUYyMlBSMVl1ZkgzSkVrc3pYR3dUN1l2UTNjSDdJdz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBclcyN3haZEtjZVlmdEwxQkNwREV1Tk5ocHhlUGdjYTA2V2FLZi8vUVBmUnZmTmxwCmlJRnJFYmJNQkxneFVRYzBOR0xTLzFDeHNhTmZKN1E1UU1PMDdyZUhFNkVOcnNnb2lFN2xxMVB2NW51Ymo5T3MKOUdTVnAzZVdkNlhOZjZma2krNlpFOGdzS2tYbFJrUnBhVk02bTlLdGVxcXdnN0xhaWFjVmw1enFvUVpyR0hrYwpuTEh3NlpFbDBWSXIvYkxuQ3Yybm0zOE1RYkpPdFExUGRzVEpSUVpsa2ROcFRxd0pNZCtyR2x6Y2xHN1Z0Q2xYCnVyN2xXR1hrVDI2dVRnWmtKTW9STlp2K29YQk5hMXZ1R0loSkF1eEpzMzlIV1NlMnRxTUdOcnZkT3pqUHNrUXcKV2E2R0lUM2FDU0Mwcytra3l5eXVMbm96YjhLMW5MbVpLUzJhRVFJREFRQUJBb0lCQUdMRG5TMTNiUlBVSTdaQQpHT3cxYVhLQUhwcVRsa3ducHh0TUpBK2sxU2lUTFhLQ05kRmhNbUpTSVhtR2s3ODdSUVdZU2VUUVJZR09Na0JnCktFS3pzVFJKSEFtWHJEMGZDOFlrZURMTGlGRlBqMVduREZYWmVraDJtQi9uTWxKQ2dLc1g0K0VhRzl5dkZWU2cKM1E3NE1PWlFZaTc3U2E2V2lsSGQ3elA2VHJ3SUJhWTA1OVpjbGp0ejZ5N2Z2UFk1a0VWRVlzKy9aQmJCbk1sMApjK1RLRld5VUppbDBzeTB4SnVxY09lWEZoeXV0eng5bnZmdlB3RmRzL0U0bmMyUmRXOXFtSHVCaVhjTjJxUWtoCjM1aWdIRXZGN0ZKM1RNOThFK3RXRTVUVVptUElYTXNIWHc2aW1ad3Q0VDVLMTJScWg2elBuejA5QitTZU4vY2gKWDRKSkRBRUNnWUVBemxyNW0wRmNZaEVwMGIzWnZpQ3FpV0NZS24yVUllZVlMQ3VNWUxmMlFIbGNacWRIaGw5dgpncERVdXA5ZEswaW1tOTJtOEVJa0FndG51Q2Z4L2Y4K0hPU0JqSlZXWExtYURHd28yMG4xYWl0SnFNMnN3M2lUClcvUXRvUFFTK3BSVWZ2cFdnSVVpczNRTkZROWdMQnY1Qlk2Q0o5M1FTTjFjQ3VrT01EYlhkU0VDZ1lFQTF5YmQKblJLMHNQMkMwTnFJVkhpSEYvRllBTUlaUWVwekhheG9tYnkveVJwbHJEemc3NytRQkFEdFJzK0pMQ0x2Z3BRYgpMVkpZbVdzNEh2Mk5LdXl0TWxTV05Yc1pwbXVPL3pEZUpya0NwR0FGeU9sclRXL2oyMmJLdTFMZ0F1NGdhWEY3CnJCWEhucmdyTkNZVGFLei9ENCt4NnlkTS9sUXY1aFJxcDR2WGx2RUNnWUFReFJmdjVCbnI1bFV0dEc0VG8zZjQKZmg4ZnBPRDYrR1ZIZ2FxQTJiSnJmdkZoYmtyRHd0Ry9IS0lOSUpKanlCMnlJUXRHRHpuNTZJOWZTZS9Db3BHYgpxMzVUdkhjdVJlOGMvMVU2clFJQ3hNM1JxQlZZTlY1VVpMMm9qTzFWNitRS0JiSXQ4NlBrVFpRYW1BdEt5bU1zCmJtNXBhdjlZVEpVRVZmaFBOc1cvd1FLQmdDeFZGZFVIeGJPeWlRSUFCWmRpUG5Qd2h2R2hEUk5IKy9CaFZpeFgKZUMwNEF6czZVQjhXbWRZNVdxcjhtSWMvcTVwOGFoMHNtcFVDUXM0ZjhMYW5qZ2lRNVdLZnV1bFB3R2RVNm5HUQpMYnN4RGdBWUdNUWNDaGRyVnRyQ2VPWWhxd3dQRml5ZlVFS2tNRUxPbGJFNzlGS0FpV2lxOEhKM1ptZENUYmU0CldQUUJBb0dBSXd0aTlKVHFhNDhDZ1lmUzh2cWRMQ3p4Snp2VnFqWnYwVlRkVGZVd1UzS0thNkhXWWRONW1vSFIKWHpQaHdFYjNjSC90azAvRHFFMjlocG10Um5sYUs1OUxvK2JFb3Y1U3FHVzZFblZrN3VaRVZWM1BwQ2YwMlpScwo4ZWdGem5aQU50ekxOemJVSXltdzFRZE5xZWxCdExLeEhWUGg5N1lVdkZ6anZhNndsWEU9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

（3）创建名字空间

创建对应分割的名称空间，在对应名称空间下才有对应操作权限

[root@k8s-master01 pki]# kubectl create namespace dev
namespace/dev created
[root@k8s-master01 pki]# kubectl get namespaces 
NAME               STATUS   AGE
default            Active   33d
dev                Active   8s
kube-node-lease    Active   33d
kube-public        Active   33d
kube-system        Active   33d

（4）角色绑定

在 dev 名称空间下，完成用户user 和权利之间的绑定

# 创建角色绑定、角色绑定名字、引用集群角色、绑定用户、绑定名字空间
# 二选一命令行创建
[root@k8s-master01 pki]# kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
rolebinding.rbac.authorization.k8s.io/devuser-admin-binding created
# 二选一资源清单格式创建
[root@k8s-master01 pki]# kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev --dry-run -o yaml
W0630 14:24:12.181587  348765 helpers.go:704] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: devuser-admin-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: devuser

# 设置默认上下文
# 用户上下文的切换、切换的上下文是 kubernetes、通过 devuser.kubeconfig 文件
[root@k8s-master01 pki]# kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig 
Switched to context "kubernetes".
# 创建 Linux 的 dev 用户与 kubernetes 配置使用
[root@k8s-master01 pki]# useradd dev
[root@k8s-master01 pki]# passwd dev 
Changing password for user dev.
New password: 
BAD PASSWORD: The password is shorter than 8 characters
Retype new password: 
passwd: all authentication tokens updated successfully.
[root@k8s-master01 pki]# ls -ltr
total 80
........
-rw------- 1 root root 5788 Jun 30 14:28 devuser.kubeconfig
[root@k8s-master01 pki]# mkdir /home/dev/.kube
[root@k8s-master01 pki]# cp devuser.kubeconfig /home/dev/.kube/config
[root@k8s-master01 pki]# chown -R dev:dev /home/dev/.kube/
[root@k8s-master01 pki]# su - dev
# 默认只能操作 dev 名称空间，default 名称空间没有操作权限
[dev@k8s-master01 ~]$ kubectl get pod
No resources found in dev namespace.
[dev@k8s-master01 ~]$ kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"
[dev@k8s-master01 ~]$ kubectl create deployment test --image=myapp:v1 --replicas=1
deployment.apps/test created
[dev@k8s-master01 ~]$ kubectl get pod 
NAME                    READY   STATUS    RESTARTS   AGE
test-79b89cccc8-w4dd7   1/1     Running   0          5s
[dev@k8s-master01 ~]$ exit
logout
# admin 默认操作 default ,查看 pod 也启动在 dev 名称空间下
[root@k8s-master01 pki]# kubectl get pod 
No resources found in default namespace.
[root@k8s-master01 pki]# kubectl get pod -n dev 
NAME                    READY   STATUS    RESTARTS   AGE
test-79b89cccc8-w4dd7   1/1     Running   0          29s
[root@k8s-master01 pki]# kubectl get pod -A
NAMESPACE          NAME                                       READY   STATUS    RESTARTS         AGE
dev                test-79b89cccc8-w4dd7                      1/1     Running   0                32s
kube-system        calico-kube-controllers-558d465845-bqxcd   1/1     Running   5 (5h50m ago)    4d17h
kube-system        calico-node-8nxzh                          1/1     Running   42 (5h50m ago)   33d
kube-system        calico-node-rgspt                          1/1     Running   41 (5h50m ago)   33d
kube-system        calico-node-rxwq8                          1/1     Running   42 (5h50m ago)   33d
kube-system        calico-typha-5b56944f9b-l2d9z              1/1     Running   43 (5h50m ago)   33d
kube-system        coredns-857d9ff4c9-ftpzf                   1/1     Running   42 (5h50m ago)   33d
kube-system        coredns-857d9ff4c9-pzjfv                   1/1     Running   42 (5h50m ago)   33d
kube-system        etcd-k8s-master01                          1/1     Running   43 (5h50m ago)   33d
kube-system        kube-apiserver-k8s-master01                1/1     Running   57 (5h50m ago)   33d
kube-system        kube-controller-manager-k8s-master01       1/1     Running   43 (5h50m ago)   33d
kube-system        kube-proxy-fg4nf                           1/1     Running   28 (5h50m ago)   20d
kube-system        kube-proxy-frk9v                           1/1     Running   28 (5h50m ago)   20d
kube-system        kube-proxy-nrfww                           1/1     Running   29 (5h50m ago)   20d
kube-system        kube-scheduler-k8s-master01                1/1     Running   43 (5h50m ago)   33d
nfs-storageclass   nfs-client-provisioner-cf8b5f8f-pccfr      1/1     Running   5 (5h50m ago)    4d17h

9.3.9 资源与角色类型的匹配

# 集群中有些用户是默认存在的
[root@k8s-master01 pki]# kubectl get rolebinding devuser-admin-binding -n dev -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2025-06-30T06:23:08Z"
  name: devuser-admin-binding
  namespace: dev
  resourceVersion: "1452264"
  uid: 7c37f31d-806a-4df0-896e-9d2b2b2494a8
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: devuser

9.3.10 常见预定义角色

# 查看集群中所有的角色
[root@k8s-master01 pki]# kubectl get clusterrole
NAME                                                                   CREATED AT
admin                                                                  2025-05-27T18:25:43Z
calico-cni-plugin                                                      2025-05-27T20:53:53Z
calico-kube-controllers                                                2025-05-27T20:53:53Z
calico-node                                                            2025-05-27T20:53:53Z
cluster-admin                                                          2025-05-27T18:25:43Z
edit                                                                   2025-05-27T18:25:43Z
kubeadm:get-nodes                                                      2025-05-27T18:25:47Z
nfs-client-provisioner-runner                                          2025-06-21T19:37:35Z
system:aggregate-to-admin                                              2025-05-27T18:25:44Z
........

viewClusterRole

　　允许读取一个命名空间中的大多数资源，除了 Role、RoleBinding 和 Secret（Secret 中有 ServerAccount 里面有认证等信息，禁止 Secret，防止权限外溢）

editClusterRole

　　允许读取和修改 Secret。但是它也不允许查看或修改 Role 和 RoleBinding，这是为了防止权限扩散

adminClusterRole

　　一个命名空间中的资源完全控制权是由 admin ClusterRole 赋予的，有这个 ClusterRole 的主体可以读取和修改命名空间中的任何资源，除了 ResourceQuota（资源配额）和命名空间资源本身。edit 和 adminClusterRole 之间的主要区别是能否在命名空间中查看和修改 Role 和 RoleBinding

cluster-adminClusterRole

　　通过将 cluster-adminClusterRole 赋给主体，主体可以获得 Kubernetes 集群完全控制的权限

9.4 准入控制

——— 合法但无理的控制行为

准入控制是 API Server 的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于 API Server 的一些主要的功能都需要通过 Admission Controllers（准入控制）实现，比如 ServiceAccout

列举常用的准入插件与功能：

　　NamespaceLifecycle：1.防止在不存在的 namespace 上创建对象，2.防止删除系统预置 namespace（鉴权合法但准入控制不合理），删除 namespace 时，连带删除它的所有资源对象

　　LimitRanger：确保请求的资源不会超过资源所在 Namespace 的 LimitRange 的限制（有权限但不合理）

　　ServiceAccount：实现了自动化添加 ServiceAccount（当创建 namespace，自动在namespace 下添加 ServiceAccout ）

　　ResourceQuots：确保请求的资源不会超过资源的的 ResourceQuota 限制

总结：

　　1.准入控制添加额外功能

　　2.有权限合法但不合理拒绝的控制行为

———————————————————————————————————————————————————————————————————————————

无敌小马爱学习

posted on 2025-06-04 22:46 马俊南阅读(128) 评论(0) 收藏举报