安全

 23 分钟阅读  

将单体应用程序分解成原子服务可以带来各种好处，包括更高的敏捷性、更好的可扩展性和更好的服务重用能力。但是，微服务也有特定的安全需求。

  • 为了防御中间人攻击，它们需要流量加密。
  • 为了提供灵活的服务访问控制，它们需要双向 TLS 和细粒度的访问策略。
  • 为了确定谁在何时做了什么，它们需要审计工具。

Istio 安全提供了一个全面的安全解决方案来解决这些问题。本页概述了如何使用 Istio 安全功能来保护您的服务，无论您在何处运行它们。特别是，Istio 安全可以减轻针对您的数据、端点、通信和平台的内部和外部威胁。

Security overview
安全概述

Istio 安全功能提供强大的身份、强大的策略、透明的 TLS 加密以及身份验证、授权和审计 (AAA) 工具来保护您的服务和数据。Istio 安全的目标是

  • 默认安全：无需更改应用程序代码和基础架构
  • 纵深防御：与现有安全系统集成以提供多层防御
  • 零信任网络：在不可信网络上构建安全解决方案

访问我们的 双向 TLS 迁移文档，开始使用 Istio 安全功能与您已部署的服务。访问我们的 安全任务，了解使用安全功能的详细说明。

高级架构

Istio 中的安全涉及多个组件

控制平面处理来自 API 服务器的配置，并配置数据平面中的 PEP。PEP 使用 Envoy 实现。下图显示了架构。

Security Architecture
安全架构

在以下部分中，我们将详细介绍 Istio 安全功能。

Istio 身份

身份是任何安全基础架构的基本概念。在工作负载到工作负载通信开始时，双方必须交换包含其身份信息的凭据以进行相互身份验证。在客户端，会根据 安全命名 信息检查服务器的身份，以查看它是否是被授权运行工作负载的运行程序。在服务器端，服务器可以根据 授权策略 确定客户端可以访问哪些信息，审计谁在何时访问了什么，根据客户端使用的工作负载对客户端收费，以及拒绝任何未能支付账单的客户端访问工作负载。

Istio 身份模型使用一流的 服务身份 来确定请求来源的身份。此模型允许服务身份具有极大的灵活性和粒度，以表示人类用户、单个工作负载或一组工作负载。在没有服务身份的平台上，Istio 可以使用其他可以对工作负载实例进行分组的身份，例如服务名称。

以下列表显示了您可以在不同平台上使用的服务身份示例

  • Kubernetes：Kubernetes 服务帐户
  • GCE：GCP 服务帐户
  • 内部部署（非 Kubernetes）：用户帐户、自定义服务帐户、服务名称、Istio 服务帐户或 GCP 服务帐户。自定义服务帐户指的是与客户的标识目录管理的身份相同的现有服务帐户。

身份和证书管理

Istio 使用 X.509 证书为每个工作负载安全地提供强大的身份。Istio 代理与每个 Envoy 代理一起运行，并与 istiod 协同工作，以自动大规模地进行密钥和证书轮换。下图显示了身份配置流程。

Identity Provisioning Workflow
身份配置工作流

Istio 通过以下流程配置密钥和证书

  1. istiod 提供了一个 gRPC 服务来接收 证书签名请求 (CSR)。
  2. 启动时，Istio 代理创建私钥和 CSR，然后将 CSR 与其凭据一起发送到 istiod 进行签名。
  3. istiod 中的 CA 验证 CSR 中携带的凭据。验证成功后，它会对 CSR 进行签名以生成证书。
  4. 启动工作负载时，Envoy 通过 Envoy 秘密发现服务 (SDS) API 从同一容器中的 Istio 代理请求证书和密钥。
  5. Istio 代理通过 Envoy SDS API 将从 istiod 收到的证书和私钥发送到 Envoy。
  6. Istio 代理监视工作负载证书的到期时间。上述过程会定期重复以进行证书和密钥轮换。

身份验证

Istio 提供两种类型的身份验证

  • 对等身份验证：用于服务到服务身份验证，以验证建立连接的客户端。Istio 提供 双向 TLS 作为传输身份验证的全栈解决方案，可以启用它，而无需更改服务代码。此解决方案

    • 为每个服务提供一个强大的身份，代表其角色，以实现跨集群和云的互操作性。
    • 保护服务到服务通信。
    • 提供密钥管理系统来自动进行密钥和证书的生成、分发和轮换。

  • 请求身份验证：用于最终用户身份验证，以验证附加到请求的凭据。Istio 使用 JSON Web 令牌 (JWT) 验证和简化的开发人员体验来启用请求级身份验证，使用自定义身份验证提供程序或任何 OpenID Connect 提供程序，例如

在所有情况下，Istio 都通过自定义 Kubernetes API 将身份验证策略存储在 Istio 配置存储 中。 Istiod 将它们与适当的密钥一起保持最新，以供每个代理使用。此外，Istio 支持允许模式下的身份验证，以帮助您了解策略更改在强制执行之前如何影响您的安全态势。

双向 TLS 身份验证

Istio 通过客户端和服务器端的 PEP（以 Envoy 代理 实现）对服务到服务通信进行隧道传输。当工作负载使用双向 TLS 身份验证向另一个工作负载发送请求时，该请求将按如下方式处理

  1. Istio 将来自客户端的出站流量重新路由到客户端的本地 sidecar Envoy。
  2. 客户端 Envoy 与服务器端 Envoy 启动双向 TLS 握手。在握手过程中，客户端 Envoy 还会进行 安全命名 检查，以验证服务器证书中提供的服务帐户是否被授权运行目标服务。
  3. 客户端 Envoy 和服务器端 Envoy 建立双向 TLS 连接，Istio 将来自客户端 Envoy 的流量转发到服务器端 Envoy。
  4. 服务器端 Envoy 授权请求。如果授权，它将通过本地 TCP 连接将流量转发到后端服务。

Istio 将 TLSv1_2 配置为客户端和服务器的最小 TLS 版本，并使用以下密码套件

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • AES256-GCM-SHA384

  • AES128-GCM-SHA256

允许模式

Istio 双向 TLS 具有允许模式，允许服务同时接受明文流量和双向 TLS 流量。此功能极大地改善了双向 TLS 上线体验。

许多与非 Istio 服务器通信的非 Istio 客户端对于希望将该服务器迁移到启用双向 TLS 的 Istio 的运营商来说是一个问题。通常，运营商无法同时为所有客户端安装 Istio sidecar，甚至没有权限在某些客户端上安装 Istio sidecar。即使在服务器上安装了 Istio sidecar 后，运营商也无法启用双向 TLS，而不会破坏现有通信。

启用允许模式后，服务器会接受明文流量和双向 TLS 流量。该模式为上线过程提供了更大的灵活性。服务器安装的 Istio sidecar 会立即接收双向 TLS 流量，而不会破坏现有明文流量。因此，运营商可以逐步安装和配置客户端的 Istio sidecar 以发送双向 TLS 流量。完成客户端配置后，运营商可以将服务器配置为仅双向 TLS 模式。有关更多信息，请访问 双向 TLS 迁移教程。

安全命名

服务器身份编码在证书中，但服务名称是通过发现服务或 DNS 获取的。安全命名信息将服务器身份映射到服务名称。身份 A 到服务名称 B 的映射表示“A 被授权运行服务 B”。控制平面监视 apiserver，生成安全命名映射，并将其安全地分发到 PEP。以下示例说明了为什么安全命名在身份验证中至关重要。

假设运行服务 datastore 的合法服务器只使用 infra-team 身份。恶意用户拥有 test-team 身份的证书和密钥。恶意用户打算假冒该服务以检查从客户端发送的数据。恶意用户部署了一个带有 test-team 身份的证书和密钥的伪造服务器。假设恶意用户成功地劫持了（通过 DNS 欺骗、BGP/路由劫持、ARP 欺骗等）发送到 datastore 的流量，并将其重定向到伪造服务器。

当客户端调用 datastore 服务时，它会从服务器的证书中提取 test-team 身份，并使用安全命名信息检查 test-team 是否被允许运行 datastore。客户端检测到 test-team 不被允许运行 datastore 服务，身份验证失败。

请注意，对于非 HTTP/HTTPS 流量，安全命名无法防御 DNS 欺骗，在这种情况下，攻击者会修改服务的目标 IP。由于 TCP 流量不包含 Host 信息，而 Envoy 只能依赖目标 IP 进行路由，因此 Envoy 可能会将流量路由到被劫持 IP 上的服务。这种 DNS 欺骗甚至可能发生在客户端 Envoy 接收流量之前。

身份验证架构

您可以使用对等和请求身份验证策略来指定接收 Istio 网格中请求的工作负载的身份验证要求。网格运营商使用 .yaml 文件来指定策略。策略部署后会保存在 Istio 配置存储中。Istio 控制器会监视配置存储。

在任何策略变更时，新策略会被翻译成相应的配置，告诉 PEP 如何执行所需的认证机制。控制平面可以获取公钥并将其附加到配置中以进行 JWT 验证。或者，Istiod 提供密钥和证书的路径，Istio 系统管理并将其安装到应用程序 pod 以进行双向 TLS。您可以在 身份和证书管理部分 中找到更多信息。

Istio 异步地将配置发送到目标端点。一旦代理收到配置，新的认证要求将立即在该 pod 上生效。

客户端服务（即发送请求的服务）负责遵循必要的认证机制。对于请求认证，应用程序负责获取并附加 JWT 凭据到请求中。对于对等认证，Istio 会自动将两个 PEP 之间的所有流量升级到双向 TLS。如果认证策略禁用双向 TLS 模式，Istio 将继续在 PEP 之间使用明文。要显式地覆盖此行为，请使用 目标规则 禁用双向 TLS 模式。您可以在 双向 TLS 认证部分 中了解更多关于双向 TLS 如何工作的信息。

Authentication Architecture
认证架构

Istio 会将身份信息输出到下一层：授权，包括两种认证类型，以及凭据中如果有其他声明的话。

身份验证策略

本节将提供更多关于 Istio 认证策略如何工作的细节。正如您在 架构部分 中所了解到的，认证策略适用于服务收到的请求。要在双向 TLS 中指定客户端认证规则，您需要在 DestinationRule 中指定 TLSSettings。您可以在我们的 TLS 设置参考文档 中找到更多信息。

与其他 Istio 配置一样，您可以在 .yaml 文件中指定认证策略。您可以使用 kubectl 部署策略。以下示例认证策略指定使用双向 TLS 对具有 app:reviews 标签的工作负载进行传输认证

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

策略存储

Istio 将网格范围内的策略存储在根命名空间中。这些策略具有一个空的 selector，应用于网格中的所有工作负载。具有命名空间范围的策略存储在相应的命名空间中。它们只适用于其命名空间内的工作负载。如果您配置了 selector 字段，认证策略只适用于与您配置的条件匹配的工作负载。

对等和请求认证策略分别按类型（PeerAuthentication 和 RequestAuthentication）单独存储。

选择器字段

对等和请求认证策略使用 selector 字段来指定策略应用到的工作负载的标签。以下示例显示了应用于具有 app:product-page 标签的工作负载的策略的 selector 字段

selector:
  matchLabels:
    app: product-page

如果您没有为 selector 字段提供值，Istio 会将策略与策略存储范围内的所有工作负载匹配。因此，selector 字段可以帮助您指定策略的范围

  • 网格范围策略：为根命名空间指定且没有或具有空 selector 字段的策略。
  • 命名空间范围策略：为非根命名空间指定且没有或具有空 selector 字段的策略。
  • 工作负载特定策略：在常规命名空间中定义的策略，具有非空 selector 字段。

对等和请求认证策略遵循 selector 字段的相同层次结构原则，但 Istio 以略微不同的方式组合和应用它们。

网格中只能有一个网格范围的对等认证策略，每个命名空间中只能有一个命名空间范围的对等认证策略。当您为同一个网格或命名空间配置多个网格范围或命名空间范围的对等认证策略时，Istio 会忽略较新的策略。当多个工作负载特定对等认证策略匹配时，Istio 会选择最旧的策略。

Istio 使用以下顺序为每个工作负载应用最窄的匹配策略

  1. 工作负载特定
  2. 命名空间范围
  3. 网格范围

Istio 可以组合所有匹配的请求认证策略，使其工作起来就像它们来自单个请求认证策略一样。因此，您可以在网格或命名空间中拥有多个网格范围或命名空间范围的策略。但是，避免拥有多个网格范围或命名空间范围的请求认证策略仍然是一个好习惯。

对等身份验证

对等认证策略指定 Istio 在目标工作负载上强制执行的双向 TLS 模式。支持以下模式

  • PERMISSIVE：工作负载接受双向 TLS 和明文流量。此模式在迁移期间最有用，因为没有 sidecar 的工作负载无法使用双向 TLS。一旦工作负载通过 sidecar 注入成功迁移，您应该将模式切换到 STRICT。
  • STRICT：工作负载只接受双向 TLS 流量。
  • DISABLE：双向 TLS 被禁用。从安全的角度来看，除非您提供自己的安全解决方案，否则您不应该使用此模式。

当模式未设置时，将继承父范围的模式。具有未设置模式的网格范围对等认证策略默认使用 PERMISSIVE 模式。

以下对等认证策略要求命名空间 foo 中的所有工作负载使用双向 TLS

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-policy"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

使用工作负载特定对等认证策略，您可以为不同的端口指定不同的双向 TLS 模式。您只能使用工作负载已声明用于端口范围的双向 TLS 配置的端口。以下示例禁用 app:example-app 工作负载的端口 80 上的双向 TLS，并对所有其他端口使用命名空间范围对等认证策略的双向 TLS 设置

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-workload-policy"
  namespace: "foo"
spec:
  selector:
     matchLabels:
       app: example-app
  portLevelMtls:
    80:
      mode: DISABLE

上面的对等认证策略之所以有效，是因为以下服务配置将来自 example-app 工作负载的请求绑定到 example-service 的端口 80 上

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: foo
spec:
  ports:
  - name: http
    port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: example-app

请求身份验证

请求认证策略指定验证 JSON Web Token (JWT) 所需的值。这些值包括以下内容

  • 请求中 token 的位置
  • 请求的颁发者
  • 公共 JSON Web 密钥集 (JWKS)

Istio 会检查提供的 token（如果已提供）是否符合请求认证策略中的规则，并拒绝具有无效 token 的请求。当请求不携带 token 时，默认情况下会接受它们。要拒绝没有 token 的请求，请提供授权规则，指定对特定操作（例如路径或操作）的限制。

请求认证策略可以指定多个 JWT，如果每个 JWT 使用唯一的位置。当多个策略匹配工作负载时，Istio 会将所有规则组合起来，就像它们被指定为单个策略一样。这种行为有助于对工作负载进行编程，使其接受来自不同提供者的 JWT。但是，不支持具有多个有效 JWT 的请求，因为此类请求的输出主体是未定义的。

主体

当您使用对等认证策略和双向 TLS 时，Istio 会将对等认证中的身份提取到 source.principal 中。类似地，当您使用请求认证策略时，Istio 会将 JWT 中的身份分配给 request.auth.principal。使用这些主体来设置授权策略并用作遥测输出。

更新身份验证策略

您可以随时更改认证策略，Istio 会几乎实时地将新的策略推送到工作负载。但是，Istio 无法保证所有工作负载都能同时收到新的策略。以下建议有助于在更新认证策略时避免中断

  • 在将模式从 DISABLE 更改为 STRICT 反之亦然时，请使用 PERMISSIVE 模式的中间对等认证策略。当所有工作负载成功切换到所需模式时，您可以应用具有最终模式的策略。您可以使用 Istio 遥测来验证工作负载是否已成功切换。
  • 在将请求认证策略从一个 JWT 迁移到另一个 JWT 时，在不删除旧规则的情况下，将新 JWT 的规则添加到策略中。然后，工作负载会接受两种类型的 JWT，您可以在所有流量切换到新 JWT 后删除旧规则。但是，每个 JWT 必须使用不同的位置。

授权

Istio 的授权功能为网格中您的工作负载提供网格范围、命名空间范围和工作负载范围的访问控制。这种级别的控制提供了以下好处

  • 工作负载到工作负载和最终用户到工作负载的授权。
  • 简单的 API：它包含单个 AuthorizationPolicy CRD，易于使用和维护。
  • 灵活的语义：操作员可以在 Istio 属性上定义自定义条件，并使用 CUSTOM、DENY 和 ALLOW 操作。
  • 高性能：Istio 授权（ALLOW 和 DENY）在 Envoy 上原生执行。
  • 高兼容性：原生支持 gRPC、HTTP、HTTPS 和 HTTP/2，以及任何纯 TCP 协议。

授权架构

授权策略在服务器端 Envoy 代理中强制执行对入站流量的访问控制。每个 Envoy 代理都运行一个授权引擎，在运行时授权请求。当请求到达代理时，授权引擎会根据当前授权策略评估请求上下文，并返回授权结果，即 ALLOW 或 DENY。操作员使用 .yaml 文件指定 Istio 授权策略。

Authorization Architecture
授权架构

隐式启用

您无需显式地启用 Istio 的授权功能；它们在安装后即可使用。要强制执行对工作负载的访问控制，您需要应用授权策略。

对于没有应用授权策略的工作负载，Istio 允许所有请求。

授权策略支持 ALLOW、DENY 和 CUSTOM 操作。您可以根据需要应用多个策略，每个策略具有不同的操作，以确保对工作负载的访问安全。

Istio 按以下顺序分层检查匹配的策略：CUSTOM、DENY，然后是 ALLOW。对于每种类型的操作，Istio 首先检查是否存在应用了该操作的策略，然后检查请求是否与策略的规范匹配。如果请求与其中一层中的策略不匹配，则检查会继续到下一层。

以下图表详细显示了策略优先级

Authorization Policy Precedence
授权策略优先级

当您将多个授权策略应用于同一个工作负载时，Istio 会将它们累加应用。

授权策略

要配置授权策略，您需要创建一个 AuthorizationPolicy 自定义资源。授权策略包含一个 selector、一个操作和一个规则列表

  • selector 字段指定策略的目标
  • action 字段指定是允许还是拒绝请求
  • rules 指定何时触发操作
    • rules 中的 from 字段指定请求的来源
    • rules 中的 to 字段指定请求的操作
    • when 字段指定应用规则所需的条件。

以下示例展示了一个授权策略，该策略允许两个来源（cluster.local/ns/default/sa/curl 服务帐户和 dev 命名空间）访问具有 foo 命名空间中的 app: httpbin 和 version: v1 标签的工作负载，前提是发送的请求具有有效的 JWT 令牌。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://#"]

以下示例展示了一个授权策略，该策略拒绝请求，如果来源不是 foo 命名空间。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["foo"]

拒绝策略优先于允许策略。与允许策略匹配的请求可能会在与拒绝策略匹配时被拒绝。Istio 首先评估拒绝策略，以确保允许策略无法绕过拒绝策略。

策略目标

您可以使用 metadata/namespace 字段和可选的 selector 字段来指定策略的范围或目标。策略应用于 metadata/namespace 字段中的命名空间。如果将其值设置为根命名空间，则该策略应用于网格中的所有命名空间。根命名空间的值是可配置的，默认值为 istio-system。如果设置为任何其他命名空间，则该策略仅应用于指定的命名空间。

您可以使用 selector 字段将策略进一步限制为应用于特定工作负载。selector 使用标签来选择目标工作负载。选择器包含一个 {key: value} 对列表，其中 key 是标签的名称。如果没有设置，则授权策略应用于与授权策略位于同一命名空间中的所有工作负载。

例如，allow-read 策略允许对 default 命名空间中具有 app: products 标签的工作负载进行 "GET" 和 "HEAD" 访问。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
         methods: ["GET", "HEAD"]

值匹配

授权策略中的大多数字段都支持以下所有匹配模式。

  • 精确匹配：精确字符串匹配。
  • 前缀匹配：以 "*" 结尾的字符串。例如，"test.abc.*" 匹配 "test.abc.com"、"test.abc.com.cn"、"test.abc.org" 等。
  • 后缀匹配：以 "*" 开头的字符串。例如，"*.abc.com" 匹配 "eng.abc.com"、"test.eng.abc.com" 等。
  • 存在匹配：* 用于指定除空之外的任何内容。要指定一个字段必须存在，请使用 fieldname: ["*"] 格式。这与未指定字段不同，这意味着匹配任何内容，包括空。

有一些例外。例如，以下字段仅支持精确匹配

  • when 部分下的 key 字段
  • source 部分下的 ipBlocks
  • to 部分下的 ports 字段

以下示例策略允许访问以 /test/* 为前缀或以 */info 为后缀的路径。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/test/*", "*/info"]

排除匹配

为了匹配 when 字段中的 notValues、source 字段中的 notIpBlocks、to 字段中的 notPorts 等否定条件，Istio 支持排除匹配。以下示例要求如果请求路径不是 /healthz，则必须提供有效的请求主体，该主体源自 JWT 身份验证。因此，该策略从 JWT 身份验证中排除了对 /healthz 路径的请求。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        notPaths: ["/healthz"]
    from:
    - source:
        requestPrincipals: ["*"]

以下示例拒绝对没有请求主体的请求访问 /admin 路径。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: enable-jwt-for-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/admin"]
    from:
    - source:
        notRequestPrincipals: ["*"]

allow-nothing、deny-all 和 allow-all 策略

以下示例展示了一个不匹配任何内容的 ALLOW 策略。如果没有其他 ALLOW 策略，由于“默认拒绝”行为，请求将始终被拒绝。

请注意，“默认拒绝”行为仅在工作负载至少有一个具有 ALLOW 操作的授权策略时才适用。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW
  # the rules field is not specified, and the policy will never match.

以下示例展示了一个显式拒绝所有访问权限的 DENY 策略。即使存在另一个允许请求的 ALLOW 策略，它也将始终拒绝请求，因为 DENY 策略优先于 ALLOW 策略。如果您想暂时禁用对工作负载的所有访问权限，这很有用。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  # the rules field has an empty rule, and the policy will always match.
  rules:
  - {}

以下示例展示了一个允许对工作负载完全访问权限的 ALLOW 策略。它将使其他 ALLOW 策略变得毫无用处，因为它将始终允许请求。如果您想暂时向工作负载公开完全访问权限，这可能很有用。请注意，请求仍然可能由于 CUSTOM 和 DENY 策略而被拒绝。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  # This matches everything.
  rules:
  - {}

自定义条件

您还可以使用 when 部分来指定其他条件。例如，以下 AuthorizationPolicy 定义包含一个条件，即 request.headers[version] 为 "v1" 或 "v2"。在这种情况下，键为 request.headers[version]，它是 Istio 属性 request.headers 中的条目，该属性是一个映射。

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

条件支持的 key 值列在 条件页面 上。

已认证和未认证身份

如果您想让工作负载公开访问，您需要将 source 部分留空。这允许来自所有（已验证和未验证）用户和工作负载的来源，例如

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - to:
   - operation:
       methods: ["GET", "POST"]

要仅允许已验证用户，请将 principals 设置为 "*"，例如

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["*"]
   to:
   - operation:
       methods: ["GET", "POST"]

在纯 TCP 协议上使用 Istio 授权

Istio 授权支持使用任何纯 TCP 协议（例如 MongoDB）的工作负载。在这种情况下，您配置授权策略的方式与配置 HTTP 工作负载的方式相同。区别在于某些字段和条件仅适用于 HTTP 工作负载。这些字段包括

  • 授权策略对象源部分中的 request_principals 字段
  • 授权策略对象操作部分中的 hosts、methods 和 paths 字段

支持的条件列在 条件页面 上。如果您对 TCP 工作负载使用任何 HTTP 专用字段，Istio 将忽略授权策略中的 HTTP 专用字段。

假设您在端口 27017 上有一个 MongoDB 服务，以下示例配置了一个授权策略，该策略仅允许 Istio 网格中的 bookinfo-ratings-v2 服务访问 MongoDB 工作负载。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: mongodb-policy
  namespace: default
spec:
 selector:
   matchLabels:
     app: mongodb
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
   to:
   - operation:
       ports: ["27017"]

对双向 TLS 的依赖

Istio 使用双向 TLS 安全地将一些信息从客户端传递到服务器。在使用授权策略中的以下任何字段之前，必须启用双向 TLS

  • source 部分下的 principals 和 notPrincipals 字段
  • source 部分下的 namespaces 和 notNamespaces 字段
  • source.principal 自定义条件
  • source.namespace 自定义条件

请注意，强烈建议始终在 PeerAuthentication 中使用 严格 双向 TLS 模式与这些字段一起使用，以避免在使用允许双向 TLS 模式时使用明文流量时潜在的意外请求拒绝或策略绕过。

如果您无法启用严格的双向 TLS 模式，请查看 安全公告 以获取更多详细信息和替代方案。

了解更多

在学习了基本概念之后，还有更多资源可供查看

  • 按照 身份验证 和 授权 任务尝试安全策略。

  • 学习一些可以用来提高网格安全性的安全 策略示例。

  • 阅读 常见问题 以更好地排查安全策略问题，以便在出现问题时进行故障排除。

这些信息有用吗？
您有什么改进建议吗？

感谢您的反馈！