Kubernetes 中的用户与身份认证授权

通过将 –client-ca-file=SOMEFILE 选项传递给 API server 来启用客户端证书认证：

• 引用的文件必须包含一个或多个证书颁发机构，用于验证提交给 API server 的客户端证书
• 如果客户端证书已提交并验证，则使用 subject 的 Common Name （CN）作为请求的 用户名

• 客户端证书还可以使用证书的 organization 字段来指示用户的 组成员 身份

  要为用户包含多个组成员身份，请在证书中包含多个 organization 字段
  

例如，使用 openssl 命令工具生成用于签名认证请求的证书：

$ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

这将为一个用户名为 ”jbeda“ 的 CSR，属于两个组“app1”和“app2”

当在命令行上指定 –token-auth-file=SOMEFILE 选项时，API server 从文件读取 bearer token

目前，token 会无限期地持续下去，并且不重新启动 API server 的话就无法更改令牌列表 

token 文件是一个 csv 文件，每行至少包含三列：token、用户名、用户 uid，其次是可选的组名

token,user,uid,"group1,group2,group3"

请注意，如果有多个组，则该列必须使用双引号

为了简化新集群的初始化引导过程，Kubernetes 中包含了一个名为 Bootstrap Token 的动态管理的 bearer token：

• 这些 token 使用 Secret 存储在 kube-system namespace 中，在那里它们可以被动态管理和创建
• Controller Manager 中包含了一个 TokenCleaner 控制器，用于在 bootstrap token 过期时删除将其删除。

这些 token 的形式是 [a-z0-9]{6}.[a-z0-9]{16} ：

1. 第一部分是 Token ID
2. 第二部分是 Token Secret

在 HTTP header 中指定的 token 如下所示：

Authorization: Bearer 781292.db7bc3a58fc5f07e

在 API server 的启动参数中加上 –experimental-bootstrap-token-auth 标志以启用 Bootstrap Token Authenticator

必须通过 Controller Manager 上的 --controllers 标志启用 TokenCleaner 控制器，如 --controllers=*,tokencleaner

如果使用它来引导集群， kubeadm 会自己完成

用户被认证为 system:bootstrap:<Token ID> 。被包含在 system:bootstrappers 组中

命名和组是有意限制用户使用过去的 bootstap token

可以使用用户名和组（kubeadm 使用）来制定适当的授权策略以支持引导集群

通过将 –basic-auth-file=SOMEFILE 选项传递给 API server 来启用基本身份验证

目前，基本身份验证凭证将无限期地保留，并且密码在不重新启动API服务器的情况下无法更改

请注意，目前支持基本身份验证只是为了方便使用，而其他模式更安全 

基本身份认证是一个 csv 文件，至少包含3列：密码、用户名和用户 ID

password,user,uid,"group1,group2,group3"

可以指定包含以逗号分隔的组名称的可选第四列

如果有多个组，则必须将第四列值用双引号括起来

当使用来自 HTTP 客户端的基本身份验证时，API server 需要Authorization header 中包含 Basic BASE64ENCODED(USER:PASSWORD) 的值

Service account 是一个 自动启用 的 验证器 ，它使用签名的 bearer token 来验证请求。该插件包括两个可选的标志：

• –service-account-key-file : 一个包含签名 bearer token 的 PEM 编码文件

  如果未指定，将使用 API server 的 TLS 私钥
  

• –service-account-lookup : 如果启用，从 API 中删除掉的 token 将被撤销

Service account:

• 通常 API server 自动创建，
• 通过 ServiceAccount 注入控制器 关联到集群中运行的 Pod 上
• Bearer token 挂载到 pod 中，并允许集群进程与 API server 通信
• 可以使用 PodSpec 的 serviceAccountName 字段显式地与Pod关联

注意： serviceAccountName 通常被省略，因为这会自动生成

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  spec:
    replicas: 3
    template:
      metadata:
        # ...
        spec:
          containers:
            - name: nginx
              image: nginx:1.7.9
              serviceAccountName: bob-the-bot

Service account bearer token 在集群外使用也是完全有效的，并且可以用于为希望与 Kubernetes 通信的长期运行作业创建身份

要手动创建 service account，只需要使用 kubectl create serviceaccount (NAME) 命令。这将在当前的 namespace 和相关连的 secret 中创建一个 service account:

$ kubectl create serviceaccount jenkins
serviceaccount "jenkins" created
$ kubectl get serviceaccounts jenkins -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
# ...
secrets:
- name: jenkins-token-1yvwg

创建出的 secret 中拥有 API server 的公共 CA 和前面的 JSON Web Token（JWT）:

$ kubectl get secret jenkins-token-1yvwg -o yaml
apiVersion: v1
data:
ca.crt: (APISERVER'S CA BASE64 ENCODED)
  namespace: ZGVmYXVsdA==
  token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
  # ...
type: kubernetes.io/service-account-token

注意：所有值是基于 base64 编码的，因为 secret 总是基于 base64 编码

经过签名的 JWT 可以用作 bearer token 与给定的 service account 进行身份验证

通常情况下，这些 secret 被挂载到 pod 中，以便对集群内的 API server 进行访问，但也可以从集群外访问

Service account 被验证后：

• 用户名: system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
• 被指定到组 system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)

由于 service account 的 token 存储在 secret 中，所以具有对这些 secret 的读取权限的任何用户都可以作为 service account 进行身份验证

授予 service account 权限和读取 secret 功能时要谨慎

OpenID Connect 是由 OAuth2 供应商提供的 OAuth2，特别是 Azure Active Directory、Salesforce 和 Google

对 OAuth2 协议的主要扩展是返回一个称作 ID Token 的格外字段，该 token 是一个 JSON Web Token (JWT) ，有服务器签名，具有众所周知的字段，如用户的电子邮件

为了识别用户，认证者使用 OAuth2 token 响应 中的 id_token （而不是 access_token）作为 bearer token

1. 登陆到身份提供商
2. 身份提供商将提供一个 access_token ，一个 id_token 和一个 refresh_token
3. 当使用 kubectl 时，使用 –token 标志和 id_token ，或者直接加入到 kubeconfig 文件中
4. kubectl 在调用 API server 时将 id_token 置于 HTTP header 中
5. API server 将通过 检查 配置 中指定的 证书 来确保 JWT 签名有效
6. 检查以 确保 id_token 没有过期
7. 确保 用户已 授权
8. 授权 API server 后向 kubectl 返回结果
9. kubectl 向用户提供反馈

由于所有需要验证您身份的数据都在 id_token 中，Kubernetes 不需要向身份提供商 “phone home”

在每个请求都是无状态的模型中，这为认证提供了非常可扩展的解决方案

然而它确实提供了一些挑战：

• Kubernetes 没有 ”web 接口“ 来出发验证进程。没有浏览器或界面来收集凭据

  这就是为什么您需要首先认证身份提供商
  

• id_token 无法撤销，就像一个证书，所以它应该是短暂的（只有几分钟）

  所以每隔几分钟就得到一个新的令牌是非常烦人的
  

• 没有使用 kubectl proxy 命令或注入 id_token 的反向代理

  无法简单地对 Kubernetes dashboard 进行身份验证 
  

Webhook 认证是用来认证 bearer token 的 hook：

• –authentication-token-webhook-config-file 是一个用来描述如何访问远程 webhook 服务的 kubeconfig 文件
• –authentication-token-webhook-cache-ttl 缓存身份验证策略的时间。默认为两分钟

配置文件使用 kubeconfig 文件格式。文件中的 user 指的是 API server 的 webhook， clusters 是指远程服务。见下面的例子：

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.

      # users refers to the API server's webhook configuration.
      users:
        - name: name-of-api-server
          user:
            client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
            client-key: /path/to/key.pem          # key matching the cert

            # kubeconfig files require a context. Provide one for the API server.
            current-context: webhook
            contexts:
              - context:
                  cluster: name-of-remote-authn-service
                  user: name-of-api-sever
                  name: webhook

当客户端尝试使用 bearer token 与API server 进行认证是，认证 webhook 用该 token 的对象 查询 远程服务

请注意，webhook API对象与其他 Kubernetes API 对象具有相同的 版本控制兼容性规则

实现者应该意识到 Beta 对象的宽松兼容性承诺，并检查请求的 “apiVersion” 字段以确保正确的反序列化

此外，API server 必须启用 authentication.k8s.io/v1beta1 API 扩展组 --runtime config =authentication.k8s.io/v1beta1=true 

请求远程服务的body类似下面的格式：

{
    "apiVersion": "authentication.k8s.io/v1beta1",
    "kind": "TokenReview",
    "spec": {
        "token": "(BEARERTOKEN)"
    }
}

远程服务将填写请求的 status 字段以指示登录成功。成功验证后的 bearer token 将返回：

{
    "apiVersion": "authentication.k8s.io/v1beta1",
    "kind": "TokenReview",
    "status": {
        "authenticated": true,
        "user": {
            "username": "janedoe@example.com",
            "uid": "42",
            "groups": [
                "developers",
                "qa"
            ],
            "extra": {
                "extrafield1": [
                    "extravalue1",
                    "extravalue2"
                ]
            }
        }
    }
}

响应主体的 spec 字段被忽略，可以省略

未成功的请求将返回：

{
    "apiVersion": "authentication.k8s.io/v1beta1",
    "kind": "TokenReview",
    "status": {
        "authenticated": false
    }
}

HTTP状态代码可以用来提供额外的错误上下文

可以配置 API server 从请求 header 的值中识别用户，例如 X-Remote-User 。这样的设计是用来与请求 header 值的验证代理结合使用。

• –requestheader-username-headers: 必需，大小写敏感。按 header 名称和顺序检查用户标识

  包含值的第一个 header 将被作为用户名
  

• –requestheader-group-headers: 可选。大小写敏感。建议为 X-Remote-Group 按 header 名称和顺序检查用户组

  所有指定的 header 中的所有值都将作为组名
  

• –requestheader-extra-headers-prefix: 可选，大小写敏感。建议为 X-Remote-Extra- 标题前缀可用于查找有关用户的额外信息（通常由配置的授权插件使用）

  以任何指定的前缀开头的 header 都会删除前缀，header 名称的其余部分将成为额外的键值，而 header 值则是额外的值 
  

例如下面的配置：

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

该请求：

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

将产生如下的用户信息：

name: fido
groups:
  - dogs
  - dachshunds
  extra:
    scopes:
      - openid
      - profile

为了防止 header 欺骗，验证代理需要在验证请求 header 之前向 API server 提供 有效的 客户端证书 ，以对照指定的 CA 进行验证：

• –requestheader-client-ca-file: 必需。PEM 编码的证书包。在检查用户名的请求 header 之前，必须针对指定文件中的证书颁发机构提交并验证有效的客户端证书
• –requestheader-allowed-names: 可选。Common Name （cn）列表
  • 如果设置了，则在检查用户名的请求 header 之前， 必须提供指定列表中 Common Name（cn）的有效客户端证书
  • 如果为空，则允许使用任何 Common Name

通过在启动过程中将 –experimental-keystone-url=<AuthURL> 选项传递给 API server 来启用 Keystone 认证：

• 该插件在 plugin/pkg/auth/authenticator/password/keystone/keystone.go 中实现
• 目前使用基本身份验证通过用户名和密码验证用户
• 如果为 Keystone 服务器配置了自签名证书，则在启动 Kubernetes API server 时可能需要设置 –experimental-keystone-ca-file=SOMEFILE 选项
  • 如果设置了该选项，Keystone 服务器的证书将由experimental-keystone-ca-file 中的某个权威机构验证
  • 否则，证书由主机的根证书颁发机构验证

有关如何使用 keystone 来管理项目和用户的详细信息，请参阅 Keystone 文档 http://docs.openstack.org/developer/keystone/

请注意，这个插件仍处于试验阶段，正在积极开发之中，并可能在后续版本中进行更改