使用 ABAC 授权

基于属性的访问控制 (ABAC) 定义了一种访问控制范式，其中通过使用将属性组合在一起的策略来授予用户访问权限。

策略文件格式

要启用 ABAC 模式，请在启动时指定 --authorization-policy-file=SOME_FILENAME 和 --authorization-mode=ABAC。

文件格式是每行一个 JSON 对象。 不应包含封闭的列表或映射，每行只有一个映射。

每行都是一个“策略对象”，其中每个这样的对象都是一个具有以下属性的映射

• 版本控制属性
  • apiVersion，字符串类型；有效值为 "abac.authorization.kubernetes.io/v1beta1"。允许策略格式的版本控制和转换。
  • kind，字符串类型：有效值为 "Policy"。允许策略格式的版本控制和转换。
• spec 属性设置为一个具有以下属性的映射
  • 主体匹配属性
    • user，字符串类型；来自 --token-auth-file 的用户字符串。 如果您指定了 user，它必须与经过身份验证的用户的用户名匹配。
    • group，字符串类型；如果您指定了 group，它必须与经过身份验证的用户的其中一个组匹配。 system:authenticated 匹配所有经过身份验证的请求。system:unauthenticated 匹配所有未经身份验证的请求。
  • 资源匹配属性
    • apiGroup，字符串类型；一个 API 组。
      • 例如：apps、networking.k8s.io
      • 通配符：* 匹配所有 API 组。
    • namespace，字符串类型；一个命名空间。
      • 例如：kube-system
      • 通配符：* 匹配所有资源请求。
    • resource，字符串类型；一种资源类型
      • 例如：pods、deployments
      • 通配符：* 匹配所有资源请求。
  • 非资源匹配属性
    • nonResourcePath，字符串类型；非资源请求路径。
      • 例如：/version 或 /apis
      • 通配符
        • * 匹配所有非资源请求。
        • /foo/* 匹配 /foo/ 的所有子路径。
  • readonly，布尔类型，当为 true 时，表示资源匹配策略仅适用于 get、list 和 watch 操作，非资源匹配策略仅适用于 get 操作。

授权算法

请求具有与策略对象的属性相对应的属性。

收到请求时，将确定属性。未知属性设置为其类型的零值（例如，空字符串、0、false）。

设置为 "*" 的属性将匹配相应属性的任何值。

检查属性元组与策略文件中的每个策略是否匹配。 如果至少有一行匹配请求属性，则请求被授权（但可能会在稍后的验证中失败）。

要允许任何经过身份验证的用户执行某些操作，请编写一个组属性设置为 "system:authenticated" 的策略。

要允许任何未经身份验证的用户执行某些操作，请编写一个组属性设置为 "system:unauthenticated" 的策略。

要允许用户执行任何操作，请编写一个将 apiGroup、namespace、resource 和 nonResourcePath 属性设置为 "*" 的策略。

Kubectl

Kubectl 使用 apiserver 的 /api 和 /apis 端点来发现已提供的资源类型，并通过位于 /openapi/v2 的模式信息验证通过创建/更新操作发送到 API 的对象。

使用 ABAC 授权时，这些特殊资源必须通过策略中的 nonResourcePath 属性显式公开（请参阅下面的示例）

• 用于 API 版本协商的 /api、/api/*、/apis 和 /apis/*。
• 用于通过 kubectl version 检索服务器版本的 /version。
• 用于创建/更新操作的 /swaggerapi/*。

要检查特定 kubectl 操作中涉及的 HTTP 调用，您可以提高详细程度

kubectl --v=8 version

示例

1. Alice 可以对所有资源执行任何操作

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
   

2. kubelet 可以读取任何 Pod

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
   

3. kubelet 可以读取和写入事件

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
   

4. Bob 只能读取命名空间 “projectCaribou” 中的 Pod

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
   

5. 任何人都可以对所有非资源路径发出只读请求

   {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
   

完整文件示例

关于服务帐户的简短说明

每个服务帐户都有一个相应的 ABAC 用户名，并且该服务帐户的用户名是按照命名约定生成的

system:serviceaccount:<namespace>:<serviceaccountname>

创建一个新的命名空间会导致创建一个格式如下的新服务帐户

system:serviceaccount:<namespace>:default

例如，如果您想使用 ABAC 授予默认服务帐户（在 kube-system 命名空间中）对 API 的完全权限，您应该将此行添加到您的策略文件中

{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}

需要重新启动 apiserver 才能接收新的策略行。