用户管理

Kubernetes 包括两种类型的用户：

  • service accounts：直接被Kubernetes管理，主要用于Pod访问 APIService 的认证；
  • normal users：这些用户被外部系统管理，Kubernetes没有代表普通用户帐户的对象，

无法通过API调用将普通用户添加到群集中。通常情况下，第三方服务范围Kubernetes时应该使用normal users。

认证管理

Kubernetes 并没有完整的用户系统，因此目前认证的方式并不是统一的而是提供了很多可以配置的认证方式供用户选择，当前可以用的认证配置包括：

  • 客户端证书认证：

    • 基于HTTPS双向认证机制工作，apiserver 启动的时候通过参数 –client-ca-file=SOMEFILE 来配置签发客户端证书的 CA。但客户发送证书时，apiserver会使用CA对客户端证书进行验证，并且从中提取中用户名，Group名称。

  • 静态密码文件认证

    • 基于静态密码文件工作，apiserver的相关参数是–basic-auth-file
    • 客户端在发送请求的时候需要在请求头部添加上 Authorization 字段，对应的值是 Basic BASE64ENCODED(USER:PASSWORD)。apiserver 解析出客户端提供的用户名和密码，如果和文件中的某一行匹配，就认为认证成功。

  • 静态Token文件认证

    • 基于静态Token文件工作，apiserver的相关参数是–token-auth-file
    • 客户端只要在请求的头部加上 Authorization 字段就能完成认证，对应的值是 Bearer TOKEN。

  • Service Account Tokens 认证

  • OpenID

    • 基于 OAuth2 协议进行认证，但是并不是主流方案

  • Webhook Token

    • 基于HTTP回调，但请求发生时向特定的URL发送消息，参考：Webhook模式。

  • Keystone 认证

    • Keystone 是 openstack 提供的认证和授权组件，这个方法对于已经使用 openstack 来搭建 Iaas 平台的公司比较适用，直接使用 keystone 可以保证 Iaas 和 Caas 平台保持一致的用户体系。

  • 匿名请求

Service Account

Service Account 使用场景：让Pod中的进程能通过HTTPS的方式访问Kubernetes的API。

每个NS下包含一个名为default的ServiceAccount，创建POD时这个SA会被自动注入Pod中（通过volume的方式）。

每个ServiceAccount包含以下内容：

  • namespace：表明工作空间
  • token：apiserver 通过私钥签发 token
  • CA：用于验证apiserver的服务端证书（HTTPS双向验证）

上述信息都通过Secret的方式存储，关联Secret的名称格式为{ServiceAccountName}-token-{随机字符串}。

Kubernetes一定程度上实现了Service Account的自动化管理，通过以下组件能够自动实现Pod的Serivce Account控制：

Token的生成规则

通过controller-manager的参数–service-account-private-key-file参数可以将Service Account密匙（key）文件传递给Token controller，从而控制Service Account Token签名。

此时需要使用–service-account-key-file 参数选项将相应的（public key）公匙传递给kube-apiserver ，公钥用于在认证期间验证Token。

否则默认情况：k8s会使用自动生成TLS公钥和私钥生成Token

参考

kubernetes 权限管理

认证机制说明

Certificate Rotation：Kubelet证书滚动更新

Kubernetes RBAC