K8S安全认证

一。用户认证的基本框架

在K8S集群中，客户端通常有两类：

1.User Account：一般独立于K8S之外的其他服务管理的用过户账号

2.Service Account：K8S管理的账号，用于为Pod中的服务进程在访问K8S提供身份标识

ApiServer是访问及管理资源对象的唯一入口，任何一个请求访问ApiServer，都要经过以下三个过程

1.authentication(认证)：身份鉴别，只有正确的账号才能通过认证

2.authorization(授权)：判断用户是否有权限对访问的资源执行特定的动作 

3.admission control(准入控制)：用于补充授权机制以实现更精细的控制访问控制功能

二。认证管理：

K8S集群安全的关键在于如何识别并认证客户端的身份，他提供了客户端3种认证方式：

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

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

3.HTTPS证书认证：基于CA根证书签名的双向数字认证的认证方式

注释：K8S配置了多种认证方式，只要其中一种通过即可

三。授权管理：

授权发生在认证成功之后，通过了认证就可以知道请求用户是谁，然后K8S会根据事先定义的授权的授权策略来决定用户是否具有访问权限：

API Server目前常见的授权策略：

1.AlwaysDeny：表示拒绝所有请求，一般用户测试

2.AlwaysAllow：允许接受所有请求，相当于集群不需要授权流程

3.ABAC：基于属性的访问控制，表示使用用户配置的授权配置的授权规则对用户请求匹配和控制

4.Webhook：通过调用外部REST服务进行授权

5.Node：是一种专用的模式，用于对K8S发出的请求进行访问控制

6.RBAC：基于角色的访问控制

其中涉及了以下概念：

对象：User，Group，ServiceAccount

角色：代表着一组定义的资源上的课操作的动作集合

绑定：将定义好的角色和用户绑定到一起

四。操作方式：

使用apiserver证书去签署：

1.cd /etc/kubernetes/pki：进入目录

2.(umask 077;openssl genrsa -out devman.key 2048)

genrsa 是 openssl 的一个子命令，用于生成 RSA 私钥。-out devman.key 指定将生成的私钥保存到 devman.key 文件中，2048 表示私钥的长度为 2048 位

3.openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"

对于证书devman.csr提供私钥，subj "/CN=devman/O=devgroup"：-subj 选项用于指定 CSR 的主题信息。CN 表示通用名称（Common Name），这里设置为 devman；O 表示组织（Organization），这里设置为 devgroup。
4.openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.csr -days 365

penssl x509：x509 子命令用于处理 X.509 证书，-req：表示输入是一个 CSR，-in devman.csr：指定输入的 CSR 文件为 devman.csr，CA ca.crt：指定使用的 CA（证书颁发机构）证书文件为 ca.crt，-CAkey ca.key：指定使用的 CA 私钥文件为 ca.key，-CAcreateserial：如果 CA 证书的序列号文件不存在，会自动创建一个-days 365：指定生成的证书的有效期为 365 天。

5.kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.142.133:6443

kubectl config set-credentials：用于配置 Kubernetes 用户的认证信息，devman：指定用户的名称为 devman，--embed-certs=true：同样表示将证书信息嵌入到 kubeconfig 文件中，-client-certificate=/etc/kubernetes/pki/devman.csr：这里应该是 --client-certificate=/etc/kubernetes/pki/devman.crt，因为客户端证书应该是经过 CA 签名后的证书文件（.crt 扩展名），而不是 CSR 文件。指定用于客户端认证的证书文件路径，--client-key=/etc/kubernetes/pki/devman.key：指定用于客户端认证的私钥文件路径。

6.kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.csr --client-key=/etc/kubernetes/pki/devman.key 

kubectl config set-context：用于配置 Kubernetes 的上下文信息，上下文定义了集群、用户和命名空间的组合，devman@kubernetes：指定上下文的名称为 devman@kubernetes，--cluster=kubernetes：指定该上下文使用的集群为之前配置的 kubernetes 集群，--user=devman：指定该上下文使用的用户为之前配置的 devman 用户。

7.kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman 

8.kubectl config use-context devman@kubernetes：切到devman的身份

注释：kubectl config use-context kubernetes-admin@kubernetes：切换回管理员

9.vi devman.yml

10.kubectl apply -f devman.yml

测试：切换回devman身份进行获取pod值