Istio安全性( 三 )


apiVersion: "security.istio.io/v1beta1"kind: "PeerAuthentication"metadata:name: "example-peer-policy"namespace: "foo"spec:selector:matchLabels:app: reviewsmtls:mode: STRICT策略存储
Istio将网格范围策略存储在根名称空间中 。 这些策略包含一个空选择器 , 适用于网格中的所有工作负载 。 具有命名空间范围的策略存储在相应的命名空间中 。 它们仅适用于其命名空间内的工作负载 。 如果配置选择器字段 , 则身份验证策略仅适用于与您配置的条件匹配的工作负载 。
对等和请求身份验证策略按种类分别存储 , 分别为 PeerAuthentication 和 RequestAuthentication。
标签选择
对等和请求身份验证策略使用选择器字段来指定该策略适用的工作负载的标签 。 以下示例显示了适用于带有 app:product-page 标签的工作负载的策略的选择器字段:
selector:matchLabels:app: product-page如果没有为选择器字段提供值 , 则Istio会将策略与策略存储范围内的所有工作负载进行匹配 。 因此 , 选择器字段可帮助您指定策略的范围:

  • 整个mesh级别的策略: 为根名称空间指定的策略 , 不带或带有空选择器字段 。
  • 命名空间级别的策略: 为没有或没有空选择器字段的非根名称空间指定的策略 。
  • 工作负载策略: 在常规名称空间中定义的策略 , 带有非空选择器字段 。
对等和请求身份验证策略对选择器字段遵循相同的层次结构原则 , 但是Istio以稍微不同的方式组合并应用它们 。
每个命名空间只能有一个网格范围的对等身份验证策略 , 并且只能有一个命名空间范围的对等身份验证策略 。 当您为同一网格或命名空间配置多个网格范围或命名空间范围的对等身份验证策略时 , Istio会忽略较新的策略 。 当多个特定于工作负载的对等身份验证策略匹配时 , Istio将选择最旧的策略 。
Istio使用以下顺序为每个工作负载应用最窄的匹配策略:
  1. 工作负载策略
  2. 命名空间级别的策略
  3. 整个mesh级别的策略
Istio可以将所有匹配的请求身份验证策略组合起来 , 就像它们来自单个请求身份验证策略一样 。 因此 , 您可以在网格或命名空间中具有多个网格范围或命名空间范围的策略 。 但是 , 避免使用多个网格范围或命名空间范围的请求身份验证策略仍然是一个好习惯 。
对等认证
对等身份验证策略指定Istio对目标工作负载实施的双向TLS模式 。 支持以下模式:
PERMISSIVESTRICTDISABLE取消设置模式时 , 将继承父作用域的模式 。 默认情况下 , 未设置模式的网格范围对等身份验证策略使用PERMISSIVE模式 。
以下对等身份验证策略要求名称空间foo中的所有工作负载都使用双向TLS:
apiVersion: "security.istio.io/v1beta1"kind: "PeerAuthentication"metadata:name: "example-policy"namespace: "foo"spec:mtls:mode: STRICT使用特定于工作负载的对等身份验证策略 , 可以为不同的端口指定不同的相互TLS模式 。 您只能将工作负载已声明的端口用于端口范围的双向TLS配置 。 以下示例为 app:example-app 工作负载禁用端口80上的双向TLS , 并对所有其他端口使用命名空间范围的对等身份验证策略的双向TLS设置:
apiVersion: "security.istio.io/v1beta1"kind: "PeerAuthentication"metadata:name: "example-workload-policy"namespace: "foo"spec:selector:matchLabels:app: example-appportLevelMtls:80:mode: DISABLE上面的对等身份验证策略仅起作用是因为下面的服务配置将来自example-app工作负载的请求绑定到example-service的端口80:
apiVersion: v1kind: Servicemetadata:name: example-servicenamespace: foospec:ports:- name: httpport: 8000protocol: TCPtargetPort: 80selector:app: example-app请求认证
请求身份验证策略指定验证JSON Web令牌(JWT)所需的值 。 这些值包括:
  • 令牌在请求中的位置
  • 请求的issuer
  • 公用JSON Web密钥集(JWKS)
Istio会根据请求身份验证策略中的规则检查提供的令牌(如果已提供) , 并拒绝具有无效令牌的请求 。 当请求不带有令牌时 , 默认情况下将接受它们 。 要拒绝没有令牌的请求 , 请提供授权规则 , 该规则指定对特定操作(例如 , 路径或操作)的限制 。
如果请求认证策略使用唯一的位置 , 则它们可以指定多个JWT 。 当多个策略与工作负载匹配时 , Istio会将所有规则组合起来 , 就好像它们被指定为单个策略一样 。 此行为对于编程工作负载以接受来自不同提供程序的JWT很有用 。 但是 , 不支持具有多个有效JWT的请求 , 因为此类请求的输出主体未定义 。