k8s实现身份认证策略及过程解析
身份认证策略https://img.jbzj.com/file_images/article/202302/20230213093030024.jpg
[*]X.509客户端证书认证
[*]持有者令牌（bearer token）
[*]静态令牌文件（Static Token File）
[*]Bootstrap令牌
[*]Service Account令牌
[*]OIDC（OpenID Connect）令牌
[*]Webhook令牌
[*]身份认证代理（Authenticating Proxy）
[*]匿名请求
API Server启用的身份认证机制
https://img.jbzj.com/file_images/article/202302/20230213093030025.jpg
基于认证插件支持多种认证方式，而相应认证插件的启用需要经 由kube-apiserver上的专用选项完成 kubeadm v1.26 部署的集群默认启用的认证机制如右图红框中的选 项，它们依次是
[*]X509客户端证书认证
[*]Bootstrap令牌认证
[*]身份认证代理
[*]Service Account认证
注意：API Server并不保证各认证插件的生效次序与定义的次序相同
kubelet启用的身份认证机制
kubelet的REST API端点默认通过TCP协议的10250端口提供，支持管理操作
https://img.jbzj.com/file_images/article/202302/20230213093030026.jpg
需要对客户端身份进行认证
[*]启用的身份认证
[*]webhook
[*]x509客户端证书认证
[*]注意：建议显式禁用匿名用户
[*]API Server是该API端点的客户端，因此，kubelet需要在验证客户端身份时信任给API Server 颁发数字证书的CA
https://img.jbzj.com/file_images/article/202302/20230213093030027.jpg
X.509数字证书认证
在双向TLS通信中，客户端持有数字证书，而API Server信任客户端证书的颁发者
[*]信任的CA，需要在kube-apiserver程序启动时，通过--client-ca-file选项传递
[*]认证通过后，客户端数字证书中的CN（Common Name）即被识别为用户名，而O（Organization）被识别为组名
[*]kubeadm部署的Kubernetes集群，默认使用 /etc/kubernetes/pki/ca.crt 进行客户端认证
[*]/etc/kubernetes/pki/ca.crt是kubeadm为Kubernetes各组件间颁发数字证书的CA
静态令牌文件
令牌信息保存于文本文件中 由kube-apiserver在启动时通过--token-auth-file选项加载 加载完成后的文件变动，仅能通过重启程序进行重载，因此，相关的令牌会长期有效 客户端在HTTP请求中，通过“Authorization Bearer TOKEN”标头附带令牌令牌以完成认证
Service Account令牌
[*]该认证方式将由kube-apiserver程序内置直接启用
[*]它借助于经过签名的Bearer Token来验证请求
[*]签名时使用的密钥可以由--service-account-key-file选项指定，也可以默认使用API Server的tls私钥
[*]用于将Pod认证到API Server之上，以支持集群内的进程与API Server通信
[*]Kubernetes可使用ServiceAccount准入控制器自动为Pod关联ServiceAccount
OpenID Connect（OIDC）令牌
OAuth3认证机制，通常由底层的IaaS服务所提供
Webhook令牌认证
[*]是一种用于验证Bearer Token的回调机制
[*]能够扩展支持外部的认证服务，例如LDAP等
身份认证代理
[*]由kube-apiserver从请求报文的特定HTTP标头中识别用户身份，相应的标头名称可由特定的选项配置指定
[*]kube-apiserver应该基于专用的CA来验证代理服务器身份
静态令牌认证配置案例
静态令牌认证的基础配置
[*]令牌信息保存于文本文件中
[*]文件格式为CSV，每行定义一个用户，由“令牌、用户名、用户ID和所属的用户组”四个字段组成，用户组为可选字段
[*]格式：token,user,uid,"group1,group2,group3"
[*]由kube-apiserver在启动时通过--token-auth-file选项加载
[*]加载完成后的文件变动，仅能通过重启程序进行重载，因此，相关的令牌会长期有效
[*]客户端在HTTP请求中，通过“Authorization Bearer TOKEN”标头附带令牌令牌以完成认证
配置示例
[*]① 生成token，命令：echo "(opensslrand−hex3).(openssl rand -hex 3).(opensslrand−hex3).(openssl rand -hex 8)"
[*]② 生成static token文件
[*]③ 配置kube-apiserver加载该静态令牌文件以启用相应的认证功能
[*]④ 测试，命令：curl -k -H "Authorization: Bearer TOKEN" -k https://API_SERVER:6443/api/v1/namespaces/default/pods/
X509 数字证书认证
https://img.jbzj.com/file_images/article/202302/20230213093030028.jpg
X509客户端认证依赖于PKI证书体系，kubeadm部署Kubernetes集群时会自动生成所需要的证书，它们位于/etc/kubernetes/pki目录下
依赖到的PKI体系
https://img.jbzj.com/file_images/article/202302/20230213093030029.jpg
另外，对Service Account的token进行签名还需要用到一个可选的密钥对儿
所有的证书
https://img.jbzj.com/file_images/article/202302/20230213093030030.jpg
[*]各kubelet的证书可在Bootstrap过程中自动生成证书签署请求，而后由Kubernetes CA予以签署
[*]各kube-proxy、kube-scheduler和kube-controller-manager也都有相应的数字证书以完成向API Server的身份认证
X509数字证书认证测试
创建客户端私钥和证书签署请求，为了便于说明问题，以下操作在master节点上以/etc/kubernetes/为工作目录
1 生成私钥： (umask 077; openssl genrsa -out ./pki/mason.key 4096)
2 创建证书签署请求： openssl req -new -key ./pki/mason.key -out ./pki/mason.csr -subj "/CN=mason/O=developers"
3 由Kubernetes CA签署证书： openssl x509 -req -days 365 -CA ./pki/ca.crt -CAkey ./pki/ca.key -CAcreateserial -in ./pki/mason.csr -out ./pki/mason.crt
4 将pki目录下的mason.crt、mason.key和ca.crt复制到某部署了kubectl的主机上，即可进行测试
[*]这里以k8s-node01为示例；只需要复制mason.crt和mason.key即可，因为集群工作节点上已经有cr.crt文件
[*]命令：scp -rp ./pki/{mason.crt,mason.key} k8s-node01:/etc/kubernetes/pki
以上就是k8s实现身份认证策略及过程解析的详细内容，更多关于k8s 身份认证的资料请关注脚本之家其它相关文章！
来源:https://www.jb51.net/article/275124.htm
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！
页:
[1]