严格把控K8S集群中的操作权限,为普通用户生成特定的kubeconfig文件

最新推荐文章于 2025-04-28 16:58:04 发布

50902636

最新推荐文章于 2025-04-28 16:58:04 发布

阅读量865

点赞数 18

分类专栏： # kubernetes 文章标签： kubernetes 容器云原生

本文链接：https://blog.youkuaiyun.com/weixin_50902636/article/details/146207251

版权

文章目录

前言
一、背景
二、证书和证书签名请求(了解)
二、脚本示例
总结

前言

使用并维护过K8S的ops/sre都知道,kubeconfig对于k8s的访问是非常重要。无论是部署，调试还是运维，都需要kubeconfig文件。在通过二进制或者kubeadm方式部署完一套集群后,会在/root/.kube/目录下产生一个config文件,这个文件就是集群的管理文件，如果直接给将该文件给到其他人员肯定不合适，因为管理员的kubeconfig可以干任何事情，注意是任何事情。包括删除节点等高危操作。因此，就涉及到了k8s集群的权限管理。

一、背景

生产环境已存在一套k8s集群,你是集群的管理员，你的同事目前想操作集群中test命名空间下的资源，然后跟你要管理员权限进入集群，你说你能给嘛？当然不行啦，那你作为管理员怎么办呢？那就是给他结合集群中的RBAC权限控制机制，创建一个新的config文件且只能操作test空间下的资源

二、证书和证书签名请求(了解)

Kubernetes 证书和信任包（trust bundle）API 可以通过为 Kubernetes API 的客户端提供编程接口，实现 X.509 凭据的自动化制备，从而请求并获取证书颁发机构（CA）发布的 X.509 证书。

1.证书签名请求

CertificateSigningRequest （CSR）资源用来向指定的签名者申请证书签名， 在最终签名之前，申请可能被批准，也可能被拒绝

2.请求签名流程

1、CertificateSigningRequest 资源类型允许客户端基于签名请求申请发放 X.509 证书。 
	CertificateSigningRequest 对象在 spec.request 字段中包含一个 PEM 编码的 PKCS 签名请求。 
	CertificateSigningRequest 使用 spec.signerName 字段标示签名者（请求的接收方）。 
		注意:
			1、spec.signerName 在 certificates.k8s.io/v1 之后的 API 版本是必填项。
			2、在 Kubernetes v1.22 和以后的版本，客户可以设置 spec.expirationSeconds 字段（可选）来为颁发的证书设定一个特定的有效期。
				该字段的最小有效值是 600，也就是 10 分钟。

2、创建完成的 CertificateSigningRequest，要先通过批准，然后才能签名。
	 根据所选的签名者，CertificateSigningRequest 可能会被控制器自动批准。 否则，就必须人工批准， 
	 人工批准可以使用 REST API（或 client-go），也可以执行 kubectl certificate approve 命令。 
	 同样，CertificateSigningRequest 也可能被驳回， 这就相当于通知了指定的签名者，这个证书不能签名。

3、对于已批准的证书，下一步是签名。 对应的签名控制器首先验证签名条件是否满足，然后才创建证书。 
	签名控制器然后更新 CertificateSigningRequest， 将新证书保存到现有 CertificateSigningRequest 对象的 status.certificate 字段中。 
	此时，字段 status.certificate 要么为空，要么包含一个用 PEM 编码的 X.509 证书。 
	直到签名完成前，CertificateSigningRequest 的字段 status.certificate 都为空。

4、一旦 status.certificate 字段完成填充，请求既算完成， 
客户端现在可以从 CertificateSigningRequest 资源中获取已签名的证书的 PEM 数据。 当然如果不满足签名条件，签名者可以拒签。

注意:
	为了减少集群中遗留的过时的 CertificateSigningRequest 资源的数量， 一个垃圾收集控制器将会周期性地运行。 
	此垃圾收集器会清除在一段时间内没有改变过状态的 CertificateSigningRequest:
		已批准的请求: 1 小时后自动删除
		已拒绝的请求: 1 小时后自动删除
		已失败的请求: 1 小时后自动删除
		挂起的请求: 24 小时后自动删除
		所有请求: 在颁发的证书过期后自动删除

3.Kubernetes 签名者

相关知识如下

Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知的 signerName：

kubernetes.io/kube-apiserver-client：签名的证书将被 API 服务器视为客户端证书， kube-controller-manager 不会自动批准它。
1、信任分发：签名的证书将被 API 服务器视为客户端证书，CA 证书包不通过任何其他方式分发。
2、许可的主体：没有主体限制，但审核人和签名者可以选择不批准或不签署。某些主体，比如集群管理员级别的用户或组因部署和安装方式不同而不同，所以批准和签署之前需要进行额外仔细审查。用来限制 system:masters 的 CertificateSubjectRestriction 准入插件默认处于启用状态，但它通常不是集群中唯一的集群管理员主体。
3、许可的 x509 扩展：允许 subjectAltName 和 key usage 扩展，弃用其他扩展。
4、许可的密钥用途：必须包含 [“client auth”]，但不能包含 [“digital signature”, “key encipherment”, “client auth”] 之外的键。
5、过期时间/证书有效期：对于 kube-controller-manager 实现的签名者，设置为 --cluster-signing-duration 选项和 CSR 对象的 spec.expirationSeconds 字段（如有设置该字段）中的最小值。
6、允许/不允许 CA 位：不允许。

kubernetes.io/kube-apiserver-client-kubelet：签名的证书将被 kube-apiserver 视为客户端证书。 kube-controller-manager 可以自动批准它。
1、信任分发：签名的证书将被 API 服务器视为客户端证书，CA 证书包不通过任何其他方式分发。
2、许可的主体：组织名必须是 [“system:nodes”]，通用名称为 “system:node:${NODE_NAME}” 开头
3、许可的 x509 扩展：允许 key usage 扩展，禁用 subjectAltName 扩展，并删除其他扩展。
4、许可的密钥用途：[“key encipherment”, “digital signature”, “client auth”] 或 [“digital signature”, “client auth”]。
5、过期时间/证书有效期：对于 kube-controller-manager 实现的签名者，设置为 --cluster-signing-duration 选项和 CSR 对象的 spec.expirationSeconds 字段（如有设置该字段）中的最小值。
6、允许/不允许 CA 位：不允许。

kubernetes.io/kubelet-serving：签名服务端证书，该服务证书被 API 服务器视为有效的 kubelet 服务端证书，但没有其他保证。kube-controller-manager 不会自动批准它。
1、信任分发：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接，CA 证书包不通过任何其他方式分发。
2、许可的主体：组织名必须是 [“system:nodes”]，通用名称为 “system:node:${NODE_NAME}” 开头
3、许可的 x509 扩展：允许 key usage、DNSName/IPAddress subjectAltName 等扩展，禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。至少有一个 DNS 或 IP 的 SubjectAltName 存在。
4、许可的密钥用途：[“key encipherment”, “digital signature”, “server auth”] 或 [“digital signature”, “server auth”]。
5、过期时间/证书有效期：对于 kube-controller-manager 实现的签名者，设置为 --cluster-signing-duration 选项和 CSR 对象的 spec.expirationSeconds 字段（如有设置该字段）中的最小值。
6、允许/不允许 CA 位：不允许。

kubernetes.io/legacy-unknown：不保证信任。Kubernetes 的一些第三方发行版可能会使用它签署的客户端证书。稳定版的 CertificateSigningRequest API（certificates.k8s.io/v1 以及之后的版本）不允许将 signerName 设置为 kubernetes.io/legacy-unknown。 kube-controller-manager 不会自动批准这类请求。
1、信任分发：没有。这个签名者在 Kubernetes 集群中没有标准的信任或分发。
2、许可的主体：全部。
3、许可的 x509 扩展：允许 subjectAltName 和 key usage 等扩展，并弃用其他扩展。
4、许可的密钥用途：全部。
5、过期时间/证书有效期：对于 kube-controller-manager 实现的签名者，设置为 --cluster-signing-duration 选项和 CSR 对象的 spec.expirationSeconds 字段（如有设置该字段）中的最小值。
6、允许/不允许 CA 位 - 不允许。

kube-controller-manager 为每个内置签名者实现了控制平面签名。注意：所有这些故障仅在 kube-controller-manager 日志中报告。

4.证书过期时间限制字段

要使用expirationSeconds 字段前提是k8s版本是1.22+

签名请求格式并没有一种标准的方法去设置证书的过期时间或者生命期， 
因此，证书的过期时间或者生命期必须通过 CSR 对象的 spec.expirationSeconds 字段来设置。 

当 spec.expirationSeconds 没有被指定时，
内置的签名者默认使用 ClusterSigningDuration 配置选项 （kube-controller-manager 的命令行选项 --cluster-signing-duration），
该选项的默认值设为 1 年。 当 spec.expirationSeconds 被指定时，
spec.expirationSeconds 和 ClusterSigningDuration 中的最小值会被使用