Istio v1beta1 授权策略概述

Istio 1.4 引入了 v1beta1 授权策略，这是对 以前 v1alpha1 的基于角色的访问控制（RBAC）策略的重要更新。包括以下改进：

• 符合 Istio 配置模型。
• 通过简化 API 改善用户体验。
• 支持更多用例（例如，Ingress/Egress 网关支持），而不会增加复杂性。

该 v1beta1 策略不向后兼容，需要一次转换。Istio 提供了一个工具来自动执行此过程。 Istio 1.6 以后将不再支持先前的配置资源 ClusterRbacConfig、ServiceRole 和 ServiceRoleBinding。

本文描述了新的 v1beta1 授权策略模型、设计目标和从 v1alpha1 RBAC 策略的迁移。 有关 v1beta1 授权策略的详细说明，请参见 authorization concept 页面。

我们欢迎您在 discuss.istio.io 上反馈有关 v1beta1 授权策略的相关信息。

背景

迄今为止，Istio 提供了 RBAC 策略，以便使用 ClusterRbacConfig、ServiceRole 和 ServiceRoleBinding 配置资源 对 服务 实施访问控制。使用此 API，用户可以在网格级别、命名空间级别和服务级别强 制实施访问控制。与其他 RBAC 策略一样，Istio RBAC 使用相同的角色和绑定概念来授予身份权限。

尽管 Istio RBAC 一直稳定可靠的工作着，但我们还是发现了许多改进空间。

例如，用户错误地假定访问控制实施发生在服务级别，因为 ServiceRole 使用服务指定在何处应用策略，但是，策略实际上应用于 工作负载，该服务仅用于查找相应的工作负载。当多个服务引用相同的工作负载时， 这种细微差别非常重要。如果两个服务引用相同的工作负载，则服务 A 的 ServiceRole 也会影响服务 B，这可能会导致混淆和不 正确的配置。

另一个示例是，由于需要深入了解三个相关资源，用户很难维护和管理 Istio RBAC 配置。

设计目标

新的 v1beta1 授权策略具有几个设计目标：

• 与 Istio 配置模型保持一致，以便更清楚地了解策略目标。 配置模型提供统一的配置层次结构、解决方案和目标选择。

• 通过简化 API 改善用户体验。管理一个包含所有访问控制规范的 CRD（自定义资源定义）比管理多个 CRD 更容易。

• 支持更多用例，而不会增加复杂性。例如，允许在 Ingress/Egress 网关上应用策略，以对进出网格的流量实施访问控制。

AuthorizationPolicy

通过 AuthorizationPolicy 自定义资源启用对工作 负载的访问控制。本节介绍 v1beta1 授权策略中的变化。

AuthorizationPolicy 包括 selector 和一个 rule 列表。selector 指定应用策略的工作负载，rule 列表指定工作 负载的详细访问控制规则。

rule 是累加的，这意味着如果任何 rule 允许请求，则请求将被允许。每个 rule 都包含 from、to 和 when 的定义， 其指定了允许谁在哪些条件下执行哪些操作。

selector 将替换 ClusterRbacConfig 和 ServiceRole 中的 services 字段提供的功能。 rule 将替换 ServiceRoleBinding 和 ServiceRole 中的其他字段。

示例

以下授权策略适用于 foo 命名空间中含有 app: httpbin 和 version: v1 标签的工作负载：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.headers[version]
     values: ["v1", "v2"]

当来自 cluster.local/ns/default/sa/sleep 的请求头中包含值为 v1 或 v2 的 version 字段时， 该策略将允许其通过 GET 请求访问工作负载。默认情况下，任何与策略不匹配的请求都将被拒绝。

假设 httpbin 服务定义为：

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    app: httpbin
    version: v1
  ports:
    # omitted

如果要在 v1alpha1 中实现相同的目的，您需要配置三个资源：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    services: ["httpbin.foo.svc.cluster.local"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: httpbin
  namespace: foo
spec:
  rules:
  - services: ["httpbin.foo.svc.cluster.local"]
    methods: ["GET"]
    constraints:
    - key: request.headers[version]
      values: ["v1", "v2"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin
  namespace: foo
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/sleep"
  roleRef:
    kind: ServiceRole
    name: "httpbin"

工作负载选择器

v1beta1 授权策略中的一个主要更改是，它现在使用工作负载选择器指定应该在何处应用策略。 这与 Gateway、Sidecar 和 EnvoyFilter 配置中使用的工作负载选择器相同。

工作负载选择器显式的表明，策略是在工作负载（而不是服务）上应用和强制执行的。 如果策略适用于由多个不同服务使用的工作负载，则同一策略将影响所有不同服务的流量。

只需将 selector 留空，即可将策略应用于命名空间中的所有工作负载。以下策略适用于命名空间 bar 中的所有工作负载：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: bar
spec:
 rules:
 # omitted

根命名空间

根命名空间中的策略应用于网格中每个命名空间中的所有工作负载。 根命名空间可在 MeshConfig 中配置， 其默认值为 istio-system。

例如，您在 istio-system 命名空间中安装了 Istio，并在 default 和 bookinfo 命名空间中部署了工作负载。 把根命名空间从默认值更改为 istio-config 后，以下策略将应用于每个命名空间中的工作负载， 包括 default、bookinfo 和 istio-system：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: istio-config
spec:
 rules:
 # omitted

Ingress/Egress 网关支持

v1beta1 授权策略也可以应用于 ingress/egress 网关，以对进入或离开网格的流量实施访问控制， 您只需更改 selector 即可选择入口或出口工作负载。

以下策略适用于具有 app: istio-ingressgateway 标签的工作负载：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: ingress
 namespace: istio-system
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
 rules:
 # omitted

请注意，授权策略仅适用于与策略相同的命名空间中的工作负载，除非在根命名空间中应用该策略：

• 如果不更改根命名空间的默认值（即 istio-system），上述策略将应用于每个命名空间中 含有 app: istio-ingressgateway 标签的工作负载。

• 如果将根命名空间更改为其他值，则上述策略将仅适用于 istio-system 命名空间中 含有 app: istio-ingressgateway 标签的工作负载。

比较

下表突出显示了旧的 v1alpha1 RBAC 策略和新的 v1beta1 授权策略之间的主要区别。

特性

下表显示了 v1alpha1 和 v1beta1 API 之间的关系。

ClusterRbacConfig

ServiceRole

ServiceRoleBinding

除了所有差异之外，与 v1alpha1 类似，v1beta1 策略也由 Envoy 引擎强制执行，并支持同样的身份验证（双向 TLS 或 JWT）、条件和其他基元（如 IP、端口等）。

未来的 v1alpha1 策略

v1alpha1 RBAC 策略（ClusterRbacConfig、ServiceRole 和 ServiceRoleBinding）将被 v1beta1 授权策略替代并弃用。

Istio 1.4 继续支持 v1alpha1 RBAC 策略，以便使您有足够的时间完成迁移。

从 v1alpha1 策略迁移

对于给定的工作负载，Istio 仅支持两个版本之一：

• 如果仅为工作负载配置 v1beta1 策略，则 v1beta1 策略生效。
• 如果仅为工作负载配置 v1alpha1 策略，则 v1alpha1 策略生效。
• 如果同时为工作负载配置 v1beta1 和 v1alpha1 策略，则仅 v1beta1 策略生效，v1alpha1 策略将被忽略。

一般准则

迁移到 v1beta1 策略的典型流程是首先检查 ClusterRbacConfig，以确定哪些命名空间或服务启用了 RBAC。

对于启用了 RBAC 的每个服务：

1. 从服务定义中获取工作负载选择器。
2. 使用工作负载选择器创建一个 v1beta1 策略。
3. 根据应用与服务的每个 ServiceRole 和 ServiceRoleBinding 更新 v1beta1 策略。
4. 应用该 v1beta1 策略并监视流量，以确保该策略按预期工作。
5. 对启用了 RBAC 的下一个服务重复该过程。

对于启用了 RBAC 的每个命名空间：

1. 把拒绝所有流量的 v1beta1 策略应用到给定的命名空间。

迁移示例

假设在 foo 命名空间中您有以下 v1alpha1 策略用于 httpbin 服务：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    namespaces: ["foo"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: httpbin
  namespace: foo
spec:
  rules:
  - services: ["httpbin.foo.svc.cluster.local"]
    methods: ["GET"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin
  namespace: foo
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/sleep"
  roleRef:
    kind: ServiceRole
    name: "httpbin"

以下述方式将上面的策略迁移到 v1beta1：

1. 假设 httpbin 服务具有以下工作负载选择器：

   selector:
     app: httpbin
     version: v1
   

2. 通过工作负载创建 v1beta1 策略：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: httpbin
    namespace: foo
   spec:
    selector:
      matchLabels:
        app: httpbin
        version: v1
   

3. 根据服务所应用的 ServiceRole 和 ServiceRoleBinding 更新 v1beta1 策略：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: httpbin
    namespace: foo
   spec:
    selector:
      matchLabels:
        app: httpbin
        version: v1
    rules:
    - from:
      - source:
          principals: ["cluster.local/ns/default/sa/sleep"]
      to:
      - operation:
          methods: ["GET"]
   

4. 应用 v1beta1 策略并监视流量，以确保该策略按预期工作。

5. 应用下面的 v1beta1 策略，该策略拒绝所有到达 foo 命名空间的流量，因为命名空间 foo 启用了 RBAC：

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: deny-all
    namespace: foo
   spec:
    {}
   

确保 v1beta1 策略按预期工作，然后可以从集群中删除 v1alpha1 策略。

自动化迁移

为了帮助简化迁移，可通 istioctl experimental authz convert 转换命令自动将 v1alpha1 策略 转换为 v1beta1 策略。

迁移时您可以考虑该命令，但它在 Istio 1.4 中是实验性的，并且截至此博客文章发布，其还不能够完整支持 v1alpha1 的全部语义。

支持完整 v1alpha1 语义的命令预计在 Istio 1.4 之后的修补程序版本中发布。