深入理解K8S【安全认证机制】
1 核心概念
1.1 安全体系
对于大型系统来说，对业务的权限、网络的安全认证是必不可少的。
对于linux系统来说，用户和组、文件权限、SELinux、防火墙、pam、sudo等，究其核心的目的都是为了保证系统是安全的。
- 那么kubernetes的这种大型的任务编排系统来说，同样也陆续产生了一系列对平台的权限认证、对业务的权限认证、对网络的安全认证等认证体系
- K8s官网：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/
K8S权限及认证（3A）：
- Authentication认证：校验用户身份，若不成功返401。多个认证插件进行
或逻辑。只要有一个插件校验通过就放行，进入下一关。【是不是我们的人】- Authorization授权：什么样的用户有什么权限。不同用户获取不同的资源操作权限，比如普通用户、超级用户等。权限不足返回403<鉴权过程遵循“
或”逻辑，且任何一个插件对操作的许可授权后都将不再进行后续插件验证，如果都未许可则拒绝。【是什么角色，给你什么权限】- Admission准入控制：用户认证、授权之后，当进行一些写操作的时候，需要遵循的一些限制的要求,比如资源限制内容合规性检查，遵循“
与”逻辑，且无论成败，每次操作都要经由所有插件检验,最后统一返回结果
只对写操作进行合规性检查，在授权范围内，对用户的某些命令或者操作进行进一步的限制【操作造成的结果是否在合规范围内，需要所有插件检验通过】
分为两类:
- validaing 校验(合规性,资源默认和最大和最小限制)
- mutating 变更(补全,默认值填充)
K8s安全校验流程解析：
- UA（普通人类账户）、SA（集群内部账户，内嵌账户）发起请求
- 认证、授权插件遵循
短路与，如：多个认证插件，有一个成功就放行，让请求到达授权插件链；准入控制插件不遵循短路与，需要准入控制插件链上的插件都检测通过才允许请求往下走。- 校验通过，访问k8s对应资源。
①上图左侧的用户：
- kubernetes主要有两种用户：
- User Account:普通人类用户(交互模式)
- Service Account:集群内部的pod用户(服务进程)
②中间：每个部分都是以插件的方式来整合到 kubernetes 集群环境中：
认证和授权是按照插件的顺序依次进行检测，并且遵循 “短路模型” 的认证方式所谓的"短路"即，失败的时候，到此结束,后续的规则不会进行。
准入控制 由于仅用户写操作场景，所以它不遵循 “短路模型”，而是会全部检测通过才允许执行原因在于，它要记录为什么不执行，原因是什么，方便后续审计等动作。
③右侧部分：k8s资源
1.2 认证机制
1.2.1 k8s中的用户
- UserAccount：非pod类的客户端来访问API Server，一般是我们现实中的"人"。常见的管理方式：openssl等。（K8s将这部分外包出去，由外部的第三方服务进行管理）【真实的人操作的账户、k8s外包出去、openssl】
- ServiceAccount（SA）：k8s内部自带的、与pod关联的账号类型。主要用于集群pod内的进程访问API Server。该账号认证到API Server的信息称为Service Account Token，它们保存于同名的Secret对象中。【k8s内嵌、pod操作的账户】
- 匿名用户
1.2.2 用户组（类比windows用户组）
为了方便k8s对某一类用户账号UA进行管理，一般会通过用户组方式进行管理。
- k8s本身并没有用户组的概念。用户组是在身份提供者（如：OpenID Connect、Active Directory、kubectlconfig文件中定义的）。
- 在k8s中，用户、用户组主要在Authentication认证、Authorization授权环节中发挥作用。
①查看集群中的用户和组（CN和OU）：openssl x509 -in xx-apiserver.crt -text -noout
例如：查看用户组system：master权限
所有的k8s集群资源操作，其实都是通过node节点上的kubelet和master节点上的apiserver之间的通信实现，而在kubernetes的认证目录中有其专用的通信认证证书 apiserver-kubelet-client.crt，可以通过该文件来检查一下这两者之间是一个怎样的关系。
# 以rancher搭建的k8s为例
# 查看集群中的用户关系
openssl x509 -in /var/lib/rancher/rke2/server/tls/client-kube-apiserver.crt -text -noout
结果：
Certificate:
...
Issuer: CN = kubernetes
Validity
Not Before: Oct 3 03:06:43 2021 GMT
Not After : Oct 3 03:06:43 2022 GMT
Subject: O=system:masters, CN=kube-apiserver-kubelet-client
...
结果显示：对于kubelet，用户名是kube-apiserver-kubelet-client，而且属于system:master的组，这两者的关系是在基于openssl或者csffl工具创建用户时候基于CN和O来设定的信息。
②查看集群角色权限:kubectl get clusterrole cluster-admin -o yaml
# 查看k8s cluster-admin的用户权限
kubectl get clusterrole cluster-admin -o yaml
③查看集群和用户角色绑定关系：kubectl get clusterrolebinding cluster-admin -o yaml
# 查看cluster-admin这个绑定配置，做了什么配置
kubectl get clusterrolebinding cluster-admin -o yaml
...
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole # 被绑定人拥有cluster-admin用户的权限
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
# 将system:masters里的所有人都应用该绑定关系
name: system:masters
1.2.3 认证插件
API Server启用的身份认证机制：
- 基于认证插件支持多种认证方式，而相应认证插件的启用需要经由kube-apiserver上的专用选项完成
- kubeadm 部署的集群默认启用的认证机制包括如下几种：
- X509客户端证书认证
- Bootstrap令牌认证
- 前端代理身份认证 front-proxy
- Service Account 令牌
注意：API Server并不保证各认证插件的生效次序与定义的次序相同（认证插件遵循或关系，有一个认证通过就放行，不再进行其他认证插件的校验。直接进入下一步授权）
# 在master节点查看认证机制
cat /etc/kubernetes/manifests/kube-apiserver.yaml
①X509客户端证书认证（TSL双向认证）：k8s ca.crt签发证书
TLS双向认证，客户端持有数字证书,API Server信任客户端证书的颁发者.即服务器客户端互相验证信任的CA需要在kube-apiserver启动时,通过–client-ca-file选项指定.证书中的Subject中的 CN(CommonName)即被识别为用户名，而O（Organization）被识别为组名对于这种客户的账号，k8s是无法管理的。为了使用这个方案，api-server需要用–client-ca-file、–tls-private-key-file、–tls-cert-file选项来开启。kubeadm部署的Kubernetes集群，默认使用 /etc/kubernetes/pki/ca.crt 进行客户端认证,此文件是kubeadm为Kubernetes各组件间颁发数字证书的CA
- 由k8s的ca.crt签发证书，校验证书合法性（是否是我签发的），校验权限（是否是某个cn用户，是否是某个o组）
②Token令牌认证：节点数量很多，直接通过token进行通信
在节点数量非常多的时候，大量手动配置TLS认证比较麻烦，可以通过在api-server开启 experimental-bootstrap-token-auth 特性，通过对客户端的和k8s平台预先定义的token信息进行匹配，认证通过后，自动为节点颁发证书，可以大大减轻工作量，而且应用场景非常广。
包括: Service Account 令牌,静态令牌文件,Bootstrap令牌,OIDC(OpenID Connect)令牌,Webhook 令牌 等
- 节点数量多，手动配置tls证书麻烦。直接通过token方式通信。（token中存储了用户的信息）
③代理认证
一般借助于中间代理的方式来进行统用的认证方式，样式不固定
④匿名方式
无法认证的其它请求（无认证）
2 实战
2.1 User Account管理
2.1.1 X509客户端认证(k8s集群维护了三套CA证书系统)
官网地址：https://kubernetes.io/zh/docs/setup/best-practices/certificates/
Kubernetes集群中的X509客户端认证依赖于PKI证书体系,有如下三套CA证书系统
kubeadm部署Kubernetes集群时会自动生成所需要的证书，它们位于/etc/kubernetes/pki自录下
| 文件 | Default CN | 说明 |
|---|---|---|
| ca.crt,ca.key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,etcd/ca.key | etcd-ca | For all etcd-related functions |
| front-proxy-ca.crt,front-proxyca.crt.key | kubernetes-frontproxy-ca | For the front-end proxy |
2.1.2 X509创建用户证书（普通用户、管理员）
①创建普通用户
# 执行下面命令后展示的内容，表示默认kubernetes的CA签发的证书，都是k8s客户端的用户
grep '\-\-client-ca-file' /etc/kubernetes/manifests/kubeapiserver.yaml
- --client-ca-file=/etc/kubernetes/pki/ca.crt
# 创建存放证书的目录
mkdir pki
(umask 077; openssl genrsa -out pki/test.key 4096)
# 生成证书申请,加入ops组只具有普通权限
openssl req -new -key pki/test.key -out pki/test.csr -subj
"/CN=test/O=ops"
# 使用kubernetes-ca颁发证书
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/test.csr -out
pki/test.crt
#复制证书文件到到worker节点
#执行kubectl命令并指定apiserver地址和test用户的证书等信息
kubectl get pod --server=https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --certificateauthority=/etc/kubernetes/pki/ca.crt
# Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"
解决：
方法一：提升test用户的权限，加入管理员组或绑定其他权限
方法二：忽略证书校验
kubectl get pod -s https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --insecure-skip-tlsverify=true
# 如果没有kubectl命令，也可以通过curl命令验证
curl --cert pki/test.crt --key pki/test.key --key-type PEM --
cacert /etc/kubernetes/pki/ca.crt https://192.xx.xxx.xx:6443
②创建管理员
将创建的用户加入管理员组。创建管理员时，指定O为system:masters
# 创建管理员用户testuser证书
(umask 077; openssl genrsa -out pki/testuser.key 4096)
#生成证书申请文件,注意：加入system:masters组或System组才具有管理权限
openssl req -new -key pki/testuser.key -out pki/testuser.csr -subj
"/CN=testuser/O=system:masters"
# 通过k8s ca签发证书
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/testuser.csr -out pki/testuser.crt
# 查看目录下的文件（应该有testuser.csr testuser.key testuser.crt文件）
ls pki
# 使用证书访问节点，观察是否有权限获取pod
kubectl get pods -s https://192.xx.xxx.xx:6443 --certificateauthority=/etc/kubernetes/pki/ca.crt --client-certificate=pki/testuser.crt --clientkey=pki/testuser.key
2.2 ServiceAccount管理
2.2.1 ServiceAccount概念
官方文档：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/
- 用途：API Server对来自Pod中客户端程序进行身份验证
- ServiceAccount也是API Server支持的标准资源类型
在Pod上使用ServiceAccount：
- 自动设定：Service Account通常由API Server自动创建并通过ServiceAccount准入控制器自动关联到集群中创建的每个Pod上
- K8s自动为每个pod注入一个ServiceAccount及配套令牌
- 在每个namespace中，会自动生成(由ServiceAccount准入控制器负责)一个名称为default的ServiceAccount，并默认将其自动分配给该空间下的每个Pod共享使用
# 查看pod配置 -o yaml以yaml格式输出，-o json以json格式输出
kubectl get po nginx-statefulset-0 -o yaml | grep -C 9 -i ServiceAccount
2.2.2 创建&使用ServiceAccount
- 查看SA
- 创建和使用SA账号
①查看和创建新SA
查看SA：
#每个命名空间都会有一个默认的default的SA账号名称
kubectl get sa -A
创建SA：
- 创建一个名为mysa的ServiceAccount。
- 定义了一个名为myrole的Role，允许get, watch, 和 list操作在pods, services, 和 secrets资源上。
- 创建一个RoleBinding，将myrole绑定到mysa，这样ServiceAccount就有了相应的权限。
- 如果我们希望ServiceAccount在整个集群范围内都有权限，我们需要创建一个ClusterRole和ClusterRoleBinding。（将yml中的Role和RoleBinding换成ClusterRole和ClusterRoleBinding）
# 创建namespace
kubectl create ns mynamespace
mysa.yml:
apiVersion: v1
kind: ServiceAccount
metadata:
name: mysa
namespace: mynamespace # 指定命名空间，可忽略
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: myrole
namespace: mynamespace # 确保与ServiceAccount在同一命名空间
rules:
- apiGroups: [""]
resources: ["pods", "services", "secrets"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: bind-mysa-to-myrole
namespace: mynamespace # 同样，确保与ServiceAccount和Role在同一命名空间
subjects:
- kind: ServiceAccount
name: mysa
namespace: mynamespace
roleRef:
kind: Role
name: myrole
apiGroup: rbac.authorization.k8s.io
#创建账号
kubectl apply -f mysa.yml
# 查看sa账号(我们在mynamespace创建的，这里需要指定名称空间)
kubectl get sa -n mynamespace -o wide | grep mysa
# 查看sa详情信息
kubectl describe sa -n mynamespace
SA账号配套的token是在secrets对象中,注意:k8s v1.24版后创建SA不会自动生成对应Secret
# 查看ServiceAccount的Secret信息
kubectl get secrets -n mynamespace
# 查看ServiceAccount详情
kubectl get sa mysa -n mynamespace -o yaml
②应用SA
在pod资源中一个属性专门来设置该资源属于哪个SA管理
# 查看pod.spec.serviceAccountName作用
kubectl explain pod.spec.serviceAccountName
# 创建rolebonding（给mynamespace的mysa赋予admin权限）
kubectl create clusterrolebinding mysa-clusterrolebinding --clusterrole=admin --serviceaccount=mynamespace:mysa
注意： SA可以跨名称空间进行授权，即A名称空间的SA帐号可以授权给B名称空间的权限，甚至对所有名称空间授权
2.3 kubectlconfig管理
前面介绍的使用X509或令牌方式创建用户的命令行方式需要指定很多选项,无疑是很麻烦的。
- 因此可以将用户的凭证信息保存在kubeconfig文件中方便使用，kubeconfig 是YAML格式的文件，用于存储身份认证信息，以便于客户端加载并认证接入到API Server。
- kubeconfig 保存有认证到一或多个Kubernetes集群的相关配置信息，并允许管理员按需在各配置间灵活切换
通过kubeadm在创建集群的时候，其中有一步就是：生成kubernetes控制组件的kubeconfig文件及相关的启动配置文件,通过各种conf文件，让不同的组件具备操作相关资源的权限
总结：
- kubectlconfig文件(yaml格式文件)清晰明了，方便下载
- kubectlconfig支持配置多个环境。（类比Java SpringBoot多环境yml配置：dev、pre、pro）
2.3.1 kubectlconfig概念
kubectl管理多个context，每个context包含了访问k8s集群必要的两个配置：用户、地址。
- clusters：每个Kubernetes集群的信息，包括集群对应访问端点（API Server）的地址
- users：认证到API Server的用户的身份凭据列表
- contexts：将每一个user同可认证到的cluster建立关联关系的上下文列表
- current-context：当前默认使用的context
# 查看conf文件中的用户信息
awk '/client-certificate-data/{print $NF}' /config |
base64 -d | openssl x509 -noout -text
2.3.2 kubectlconfig创建和管理
kubectl config 命令可以创建和管理kubeconfig文件
# 查看帮助手册
kubectl config --help
Available Commands:
current-context 显示 current_context
delete-cluster 删除 kubeconfig 文件中指定的集群
delete-context 删除 kubeconfig 文件中指定的 context
delete-user Delete the specified user from the kubeconfig
get-clusters 显示 kubeconfig 文件中定义的集群
get-contexts 描述一个或多个 contexts
get-users Display users defined in the kubeconfig
rename-context Renames a context from the kubeconfig file.
set 设置 kubeconfig 文件中的一个单个值
set-cluster 设置 kubeconfig 文件中的一个集群条目
set-context 设置 kubeconfig 文件中的一个 context 条目
set-credentials 设置 kubeconfig 文件中的一个用户条目
unset 取消设置 kubeconfig 文件中的一个单个值
use-context 设置 kubeconfig 文件中的当前上下文
view 显示合并的 kubeconfig 配置或一个指定的 kubeconfig 文件
# 例如：查看当前使用的context
kubectl config current-context
# 使用testuser-context，后续执行kubectl命令
#会自动读取testuser-context存储的集群及用户凭证信息
kubectl config use-context testuser-context
3 安全认证综合案例
3.1 UserAccount创建&使用kubetlconfig
3.1.1 UserAccount创建
- 创建私钥文件（openssl genrsa -out user1.key 2048）
- genrsa：用于生成rsa私钥（不会生成公钥，因为公钥提取自私钥）
- out filename：指定私钥保存位置
- numbits：指定私钥长度，默认1024
- 签名请求（openssl req -new -key user1.key -out user1.csr -subj
“/CN=user1/O=group”）
- new 新建一个签名请求文件
- key 指定已有私钥文件，签名请求，必须与-new搭配
- out 输出证书文件名称
- subj 指定生成证书的拥有者信息（CN及O的值：用户名及组名）
- 刚才的私钥和认证并没有被Kubernetes集群纳入到管理体系，需要基于kubeadm集群的CA相关证书来
进行认证- 生成证书（openssl x509 -req -CA ./ca.crt -CAkey ./ca.key -
CAcreateserial -in user1.csr -out user1.crt -days 365）
- -req 产生证书签发申请命令
- -in 指定需要签名的请求文件
- -CA 指定CA证书文件
- -CAkey 指定CA证书的秘钥文件
- -CAcreateserial 生成唯一的证书序列号
- -x509 表示输出一个X509格式的证书
- -days 指定证书过期时间为365天
- -out 输出证书文件
- openssl x509 -in user1.crt -text -noout：查看生成的证书信息
最终生成的文件：.key 是私钥，.csr是签名请求文件，.crt是证书
# 1 创建私钥文件
(umask 077; openssl genrsa -out user1.key 2048)
# 2 签名请求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"
# 3 利用k8s ca机构签发证书
openssl x509 -req -in user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user1.crt -days 365
#结果显示：*.key 是私钥，*.csr是签名请求文件
# 查看证书信息
openssl x509 -in user1.crt -text -noout
3.1.2 使用kubectlconfig
①创建kubectlconfig用户
# 1 指定用户证书、私钥，以及生成的conf文件位置
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key --kubeconfig=/tmp/user1.conf
#参数详解：
- set-credentials #子命令的作用就是给kubeconfig认证文件创建一个用户条目
- –client-certificate=path/to/certfile #指定用户的签证证书文件
- –client-key=path/to/keyfile #指定用户的私钥文件
- –embed-certs=true #在kubeconfig中为用户条目嵌入客户端证书/密钥，默认值是false
- –kubeconfig=/path/other_config.file #表示将属性信息单独输出到一个文件，如不指定，默认存放在 ~/.kube/config文件中
②创建kubectlconfig集群
# --certificateauthority配置k8s ca证书路径
kubectl config set-cluster mycluster --server="https://localhost:6443" --embed-certs=true --kubeconfig=/tmp/user1.conf --certificate-authority=ca.crt
#参数详解：
- –server=cluster_api_server
- –certificate-authority=path/to/certificate/authority
- –embed-certs=true #默认为false,会将证书文件路径存入kubeconfig文件中,true时会将证书内容存入kubdconfig文件中
- true：则会将证书内容base64编码后存放到我们kubeconfig指定的.conf文件中。
- false：.conf文件会直接将client-key等字段设置为具体路径
#注意：这里使用到的证书必须是kubernetes的ca证书。
③创建context（关联集群）
kubectl config set-context user1@mycluster --cluster=mycluster --user=user1 --kubeconfig=/tmp/user1.conf
#属性详解
- –cluster=cluster_nickname 关联的集群名称
- –user=user_nickname 关联的用户名称
- –namespace=namespace 可以设置该生效的命名空间
查看配置文件最后效果：
kubectl config view --kubeconfig=/tmp/user1.conf
# 解析client-certificate-data、client-key-data（base64方式解析证书信息）
# kubectl config view --kubeconfig=/tmp/user1.conf --raw
总结
以rancher搭建的k8s为例
- 创建user1用户，不设置任何权限，预期用户创建成功，并能正常使用
openssl genrsa -out user1.key 2048
# 生成证书签名请求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"
# 使用集群的CA证书和私钥对证书签名请求进行签名
openssl x509 -req -in user1.csr -CA /var/lib/rancher/rke2/server/tls/client-ca.crt -CAkey /var/lib/rancher/rke2/server/tls/client-ca.key -CAcreateserial -out user1.crt -days 365
# 创建一个kubectl配置文件（--embed-certs=true将认证内嵌其中）
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key
# 查看配置信息(并且显示认证信息（经过base64编码）)
kubectl config view --raw
# 设置上下文
kubectl config set-context user1-context --cluster=default --namespace=default --user=user1
# 切换到user1用户
kubectl config use-context user1-context
# 设置context证书文件
# kubectl config --kubeconfig=/root/user1/user1.yml set-credentials user1-context --client-certificate=/root/user1/user1.crt --client-key=/root/user1/user1.key
给user1分配所有权限：
user1-clusterrole.yml：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: user1-clusterrole
rules:
- apiGroups: [ "*" ]
resources: [ "*" ]
verbs: [ "*" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: user1-clusterrole-binding
subjects:
- kind: User
name: user1 # 将user1应用ClusterRoleBinding
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: user1-clusterrole # ClusterRoleBinding绑定user1-clusterrole这个ClusterRole
apiGroup: rbac.authorization.k8s.io
3.2 SA账号创建&使用kubectlconfig
- 创建sa账号
security-sa-admin.yaml：
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin
namespace: default
---
#v1.24版之后添加下面内容手动创建secret
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
name: admin-secret
annotations:
kubernetes.io/service-account.name: "admin"
# 应用配置文件
kubectl apply -f security-sa-admin.yaml
2. 查看和配置kubectlconfig
# 查看SA账号的Token
kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d
# 将获取到的token设置到KUBEADMIN_TOKEN字段
KUBEADMIN_TOKEN=$(kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d)
# 设置用户信息
kubectl config set-credentials kubeadmin --token=$KUBEADMIN_TOKEN --kubeconfig=/root/kubeadmin.conf
# 设置集群信息--certificate-authority
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://localhost:6443" --embed-certs=true --kubeconfig=/root/kubeadmin.conf
# 设置上下文信息context（集群及用户信息）
kubectl config set-context kubeadmin@kubernetes --cluster=kubernetes --user=kubeadmin --kubeconfig=/root/kubeadmin.conf
# 指定默认context
kubectl config use-context kubeadmin@kubernetes --kubeconfig=/root/kubeadmin.conf
# 给admin角色设置admin权限
kubectl create clusterrolebinding admin-binding --serviceaccount default:admin --clusterrole cluster-admin
