Istio v1beta1 授权策略概述
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 RBAC 策略 | v1beta1 授权策略 |
---|---|---|
API 稳定性 | alpha :不 向后兼容 | beta :确保向后兼容 |
CRD 数量 | 三个:ClusterRbacConfig 、ServiceRole 和 ServiceRoleBinding | 一个:AuthorizationPolicy |
策略目标 | service | workload |
默认拒绝行为 | 通过显式的配置 ClusterRbacConfig 启用 | 隐式的通过 AuthorizationPolicy 启用 |
Ingress/Egress 网关支持 | 不支持 | 支持 |
策略中的 "*" 值 | 匹配所有内容(空和非空) | 仅匹配非空内容 |
下表显示了 v1alpha1
和 v1beta1
API 之间的关系。
ClusterRbacConfig
ClusterRbacConfig.Mode | AuthorizationPolicy |
---|---|
OFF | 未应用策略 |
ON | 在根命名空间中应用的全部拒绝策略 |
ON_WITH_INCLUSION | 策略应用于 ClusterRbacConfig 中包含的命名空间或工作负载 |
ON_WITH_EXCLUSION | 策略应用于 ClusterRbacConfig 中包含的命名空间或工作负载 |
ServiceRole
ServiceRole | AuthorizationPolicy |
---|---|
services | selector |
paths | to 字段下的 paths |
methods | to 字段下的 methods |
在约束中的 destination.ip | 不支持 |
在约束中的 destination.port | to 字段下的 ports |
在约束中的 destination.labels | selector |
在约束中的 destination.namespace | 替换为策略的命名空间,即元数据中的 namespace |
在约束中的 destination.user | 不支持 |
在约束中的 experimental.envoy.filters | when 字段下的 experimental.envoy.filters |
在约束中的 request.headers | when 字段下的 request.headers |
ServiceRoleBinding
ServiceRoleBinding | AuthorizationPolicy |
---|---|
user | from 字段下的 principals |
group | to 字段下的 paths |
source.ip 属性 | from 字段下的 ipBlocks |
source.namespace 属性 | from 字段下的 namespaces |
source.principal 属性 | from 字段下的 principals |
request.headers 属性 | when 字段下的 request.headers |
request.auth.principal 属性 | from 字段下的 requestPrincipals 或 when 字段下的 request.auth.principal |
request.auth.audiences 属性 | when 字段下的 request.auth.audiences |
request.auth.presenter 属性 | when 字段下的 request.auth.presenter |
request.auth.claims 属性 | when 字段下的 request.auth.claims |
除了所有差异之外,与 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 的每个服务:
- 从服务定义中获取工作负载选择器。
- 使用工作负载选择器创建一个
v1beta1
策略。 - 根据应用与服务的每个
ServiceRole
和ServiceRoleBinding
更新v1beta1
策略。 - 应用该
v1beta1
策略并监视流量,以确保该策略按预期工作。 - 对启用了 RBAC 的下一个服务重复该过程。
对于启用了 RBAC 的每个命名空间:
- 把拒绝所有流量的
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
:
假设
httpbin
服务具有以下工作负载选择器:selector: app: httpbin version: v1
通过工作负载创建
v1beta1
策略:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: selector: matchLabels: app: httpbin version: v1
根据服务所应用的
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"]
应用
v1beta1
策略并监视流量,以确保该策略按预期工作。应用下面的
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 之后的修补程序版本中发布。