k8s-身份认证

k8s-身份认证# 身份认证策略 X.509客户端证书认证 持有者令牌(bearer token) – 静态令牌文件(Static Token File) – Bootstrap令牌 – Service Accoun

API server

  • 客户端 只要请求api server的 都需要进行认证
    • scheduler kubelet kubeproxy kubectl controlermanager

认证 鉴权 准入 认证 一票通过 健全

  • 一票通过, 许可权限
  • 默认法则:拒绝 准入控制
    • 只控制写操作
    • 确保数据符合规范
    • 一票否决

身份认证策略

image.png

  • X.509客户端证书认证
  • 持有者令牌(bearer token)
    • 静态令牌文件(Static Token File)
    • Bootstrap令牌
    • Service Account令牌
    • OIDC(OpenID Connect)令牌
    • Webhook令牌
  • 身份认证代理(Authenticating Proxy)
  • 匿名请求

API Server启用的身份认证机制

image.png

基于认证插件支持多种认证方式,而相应认证插件的启用需要经 由kube-apiserver上的专用选项完成 kubeadm v1.26 部署的集群默认启用的认证机制如右图红框中的选 项,它们依次是

  • X509客户端证书认证
  • Bootstrap令牌认证
  • 身份认证代理
  • Service Account认证

注意:API Server并不保证各认证插件的生效次序与定义的次序相同

kubelet启用的身份认证机制

kubelet的REST API端点默认通过TCP协议的10250端口提供,支持管理操作

image.png

需要对客户端身份进行认证

  • 启用的身份认证
    • webhook
    • x509客户端证书认证
    • 注意:建议显式禁用匿名用户
  • API Server是该API端点的客户端,因此,kubelet需要在验证客户端身份时信任给API Server 颁发数字证书的CA

image.png

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)令牌

OAuth2认证机制,通常由底层的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 “
    ( o p e n s s l r a n d h e x 3 ) . (openssl rand -hex 3).
    (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 数字证书认证

image.png

X509客户端认证依赖于PKI证书体系,kubeadm部署Kubernetes集群时会自动生成所需要的证书,它们位于/etc/kubernetes/pki目录下

依赖到的PKI体系 image.png

另外,对Service Account的token进行签名还需要用到一个可选的密钥对儿

所有的证书

image.png

  • 各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-身份认证分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/14659.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注