安全策略示例

背景

此页面展示了使用 Istio 安全策略的常见模式。您可能会发现它们对您的部署很有用，或者将其用作示例策略的快速参考。

此处演示的策略仅为示例，在应用之前需要进行更改以适应您的实际环境。

还可以阅读身份验证和授权任务，以获取有关更详细地使用安全策略的实践教程。

每个主机需要不同的 JWT 发行者

JWT 验证在入口网关上很常见，您可能希望为不同的主机要求不同的 JWT 发行者。除了请求身份验证策略之外，还可以使用授权策略进行细粒度的 JWT 验证。

如果您希望在 JWT 主体匹配时允许访问给定主机，请使用以下策略。对其他主机的访问将始终被拒绝。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: jwt-per-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        # the JWT token must have issuer with suffix "@example.com"
        requestPrincipals: ["*@example.com"]
    to:
    - operation:
        hosts: ["example.com", "*.example.com"]
  - from:
    - source:
        # the JWT token must have issuer with suffix "@another.org"
        requestPrincipals: ["*@another.org"]
    to:
    - operation:
        hosts: [".another.org", "*.another.org"]

命名空间隔离

以下两个策略在命名空间foo上启用严格的 mTLS，并允许来自同一命名空间的流量。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo-isolation
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]

带有入口异常的命名空间隔离

以下两个策略在命名空间foo上启用严格的 mTLS，并允许来自同一命名空间以及入口网关的流量。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]
    - source:
        principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]

在授权层中要求 mTLS（纵深防御）

您已将PeerAuthentication配置为STRICT，但希望确保流量确实受到 mTLS 的保护，并在授权层进行额外检查，即纵深防御。

如果主体为空，则以下策略将拒绝请求。如果使用纯文本，则主体将为空。换句话说，如果主体非空，则该策略允许请求。"*"表示非空匹配，与notPrincipals一起使用表示匹配空主体。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

使用 DENY 策略要求强制授权检查

如果您希望要求必须满足的强制授权检查，并且不能被另一个更宽松的ALLOW策略绕过，则可以使用DENY策略。这是因为DENY策略优先于ALLOW策略，并且可以在ALLOW策略之前尽早拒绝请求。

使用以下策略，除了请求身份验证策略之外，还可以强制执行强制 JWT 验证。如果请求主体为空，则该策略将拒绝请求。如果 JWT 验证失败，则请求主体将为空。换句话说，如果请求主体非空，则该策略允许请求。"*"表示非空匹配，与notRequestPrincipals一起使用表示匹配空请求主体。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

类似地，使用以下策略要求强制命名空间隔离，并允许来自入口网关的请求。如果命名空间不是foo并且主体不是cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account，则该策略将拒绝请求。换句话说，该策略仅在命名空间为foo或主体为cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account时允许请求。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notNamespaces: ["foo"]
        notPrincipals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]