本博客地址：https://security.blog.csdn.net/article/details/130034953

一、认证安全配置

1.1、X.509客户端证书

X.509客户端证书是目前用户最常用的认证安全配置方式，其也可称作HTTPS证书认证，是基于CA根证书签名的双向数字证书认证方式，默认情况下Kubernetes开启此参数配置。

与X.509客户端证书相关的三个kube-apiserver启动参数为：

⬤ client-ca-file：指定CA根证书文件为/etc/kubernetes/pki/ca.pem，内置CA公钥，用于验证某证书是否为CA所签发。
⬤ tls-private-key-file：指定API Server私钥文件为/etc/kubernetes/pki/apiserver-key.pem。
⬤ tls-cert-file：指定API Server证书文件为/etc/kubernetes/pki/apiserver.pem。

如果用户使用kubeadm方式部署Kubernetes，kubeadm会自动调用openssl生成证书及相关密钥，一旦为kube-apiserver配置了以上三个参数，说明开启了HTTPS认证方式，此时若在外部通过https://masterIP:6443/api访问集群会被提示未授权访问，因此只有在客户端配置了认证信息才可对集群进行访问。

1.2、OIDC令牌

OpenID Connect（OIDC）令牌目前常用在主流公有云平台中，是一种基于OAuth2 的认证方式。OIDC对OAuth2的主要扩充体现于ID令牌（ID Token），其是由服务器签名的JSON Web令牌（JWT），并在认证时与访问令牌（Access Token）一同返回。

OCID认证流程图如下：

二、RBAC授权机制

API Server认证通过后，凭据（username、ID、group）作为授权模块的第一层输入，用户请求的资源、路径、行为等作为第二层输入，授权模块负责对以上输入进行校验，若通过则进入流程的下一步验证阶段，即准入控制器，若未通过则返回HTTP 403 Forbidden错误响应信息。

对于授权模式，目前业界使用最多的是基于角色的访问控制（Role-Based AccessControl，RBAC）

RBAC策略包含以下核心概念：

⬤ Resource：指Kubernetes中的资源，如Pod、Service等。
⬤ Role：对Resource执行的操作，如对Pod执行create、update、delete等操作。
⬤ Entity：代表一个应用程序，可以是一个用户、组或服务账户。
⬤ Role Binding：将Role绑定到Entity，表明在指定Resource上运行某Entity并执行一组操作。

此处需要注意的是，就Role和Role Binding而言，Kubernetes定义了两种范围类型：

⬤ 集群范围：Cluster Role和Cluster Role Binding。
⬤ 命名空间范围：Role和Role Binding。

如何使用上述两种类型的资源，须根据具体需求而定。

举例：

# 为应用程序建立服务账户资源
kubectl create namespace coolapp
# 查看创建的服务账户
kubectl --namespace=coolapp create serviceaccount myappid# 创建Role，该Role只能在coolapp命名空间中查看和列出Pod
kubectl --namespace=coolapp create role podview --verb=get --verb=list --resource=pods
# 查看Role
kubectl --namespace=coolapp describe role/podview# 创建Role Binding，将Role podview绑定至名为myappid的应用程序中
kubectl --namespace=coolapp create rolebinding mypodviewer --role= podview --serviceaccount=coolapp:myappid
# 查看Role Binding
kubectl --namespace=coolapp

三、准入控制器

当用户请求通过API Server认证和授权后，便进入了准入控制器环节，顾名思义，准入控制器即对请求的资源如Deployment、Pod、Service、DaemonSet、StatefulSet进行准入考量，相比前面提到的API Server认证授权机制，准入控制器是更为细粒度的资源控制机制，其支持Kubernetes的许多高级功能，如Pod安全策略（Pod Security Policy）、安全上下文（Security Context）、服务账户（Service Account）等。

准入控制器实际上为一段代码，它会在用户请求通过认证授权之后，Kubernetes资源对象持久化之前进行拦截。集群管理员可以通过在kube-apiserver配置文件中指定--enable-admission-plugins参数项的值来完成启动，若未指定，默认使用--enable-admission-plugins=NodeRestriction，NodeRestriction准入控制器限制了kubelet可以修改的Node和Pod对象。

举例：

--enable-admission-plugins= NodeRestriction，MutatingAdmissionWebhook,ValidatingAdmissionWebhook

准入控制过程主要分为两个阶段，第一个阶段运行变更准入控制器，第二个阶段运行验证准入控制器。需要注意的是，Kubernetes的某些准入控制器既是变更准入控制器也是验证准入控制器。如果第一个阶段的任何准入控制器拒绝了请求，则整个请求被拒绝，并同时向终端用户返回一个错误。当上述两阶段校验全部通过后，请求的元数据被持久化至etcd组件中。

Pod安全策略是集群级别的资源，主要在Pod的创建和更新阶段提供细粒度的权限控制，其在Kubernetes中被定义为一个准入控制器，集群管理员可通过在kube-apiserver配置文件中指定--enable-admission-plugins=NodeRestriction,PodSecurityPolicy来完成启动。

Pod安全策略资源定义了一组Pod运行时必须遵循的条件及相关字段的默认值，只有Pod满足这些条件才会被Kubernetes接受。此外，Pod安全策略定义完成后，需要使用RBAC对其授权才可以正常使用。

四、Secret对象

Kubernetes使用Secret对象来保存敏感信息，如密码、令牌和SSH密钥。相比于将敏感信息放入Pod定义的yaml文件或容器镜像中，使用Secret方式更为安全灵活，该方式也是目前开发者常使用的密钥管理方式。Secret内容可以是一个字符串也可以是一个文件，用户操作Secret主要包含传递和访问两个行为。

在传递至容器的过程中，主要通过挂载宿主机文件系统的方式来进行。Kubernetes支持通过挂载卷的方式将Secret传递至Pod，当挂载的是一个临时卷时，意味着Secret不被写入磁盘而是写在内存中，所以攻击者更难获得Secret内容。此外，使用kubectl decribe或docker inspect也无法查询Secret内容。

当访问Secret时，用户通常使用以下两种方式：

⬤ 容器内访问Secret。
⬤ kubelet组件访问Secret。

第一种方式，如果攻击者获得了对容器的访问权限，便可通过docker exec或kubectl exec进而获取Secret。针对此类型的攻击，我们可通过在容器内运行较少的工具来增加攻击者获得信息的难度，如禁止cat、vim、sh等。

第二种方式，通过添加NodeRestriction准入控制器，限制kubelet仅能访问调度到其节点Pod中的Secret，可避免kubelet访问权限过大。