安全常见问题

您可以随时使用认证策略和目标规则来为您的服务设置双向 TLS 认证。请参阅任务以获取更多细节。

认证策略可以配置为 mesh-wide（影响网络中的所有服务）、namespace-wide（namespace 中的所有服务）或某个特定服务。 您可以根据需要对集群中的服务配置一种或多种 TLS 双向认证策略。

如果您使用 values.global.proxy.privileged=true 安装 Istio，您可以使用 tcpdump 来确定加密状态。有关说明，请参见 Istio 双向 TLS 迁移。

非 Istio 服务无法与 Istio 服务通信。除非它能提供有效证书，但这基本不可能。 这是 双向 TLS 认证 的预期表现。 但是，您可以覆盖指定 namespace 或服务的全局标志。详见：认证策略

Istio 会检测目标工作负载是否具有 Envoy 代理，如果没有则丢弃双向 TLS。设置明确的目标规则可以禁用双向 TLS。例如：

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: "api-server"
spec:
 host: "kubernetes.default.svc.cluster.local"
 trafficPolicy:
   tls:
     mode: DISABLE
EOF

如果启用了双向 TLS 认证，则来自 kubelet 的 HTTP 和 TCP 健康检查将不能正常工作，因为 kubelet 没有 Istio 颁发的证书。

从 Istio 1.1 开始，我们提供了多种解决方案。

1. 使用 probe rewrite 将 liveness 和 readiness 的请求直接重定向到工作负载。有关更多信息，请参阅 Probe Rewrite。

2. 使用单独的端口进行健康检查，并且仅在常规服务端口上启用双向 TLS。有关更多信息，请参阅 Istio 服务的运行状况检查。

3. 如果对 Istio 服务使用 PERMISSIVE 模式，那么他们可以接受 HTTP 和双向 TLS 流量。请记住，由于其他人可以通过 HTTP 流量与该服务进行通信，因此不强制执行双向 TLS。

4. 健康检查使用 liveness 命令，例如，可以在服务 Pod 中安装 curl 并在 Pod 内对自身执行 curl 操作。

一个 readiness 探针的例子：

livenessProbe:
exec:
  command:
  - curl
  - -f
  - http://localhost:8080/healthz # Replace port and URI by your actual health check
initialDelaySeconds: 10
periodSeconds: 5

对于在 Kubernetes 中运行的工作负载，其 Istio 证书的生命期由在Citadel中的 workload-cert-ttl 规定。

Citadel 使用 max-workload-cert-ttl 来控制颁发给工作负载的 Istio 证书的最长生命期。其默认值为 90 天。如果 Citadel 或 Istio 代理中的 workload-cert-ttl 大于 max-workload-cert-ttl，则 Citadel 将无法颁发证书。

你可以修改生成清单文件来自定义 Citadel 配置。以下的修改指定了在 Kubernetes 中运行的工作负载的 Istio 证书，其生命期为 1 小时。除此以外，允许 Istio 证书的最大生命期为 48 小时。

...
kind: Deployment
...
metadata:
  name: istio-citadel
  namespace: istio-system
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: citadel
        ...
        args:
          - --workload-cert-ttl=1h # Lifetime of certificates issued to workloads in Kubernetes.
          - --max-workload-cert-ttl=48h # Maximum lifetime of certificates issued to workloads by Citadel.

对于在 VM 和裸机上运行的工作负载，其 Istio 证书的生命期由每个 Istio 代理中的 workload-cert-ttl 指定。其默认值也是 90 天。该值不应该大于 Citadel 中的 max-workload-cert-ttl。

您可能会发现安装 Istio 后 MySQL 无法连接。这是因为在 demo 安装配置中默认使用的 PERMISSIVE 模式不适用于 MySQL。您可能会看到类似于 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 的错误。

有两种方法可以解决此问题。

1. 禁用双向 TLS。

   如果不需要 Istio 双向 TLS，您可以选择这种方法。您可以通过显式的禁用 MySQL 上的双向 TLS 来实现。

   $ kubectl apply -f - <<EOF
   apiVersion: "authentication.istio.io/v1alpha1"
   kind: "Policy"
   metadata:
     name: mysql-nomtls-authn
   spec:
     targets:
     - name: YOUR-MYSQL-SERVICE     # The name of *your* K8s Service
   EOF
   

2. 在 STRICT 模式下启用双向 TLS。

   如果您需要为 MySQL 提供双向 TLS 保护，请使用目标规则和认证策略来启用双向 TLS。

   $ kubectl apply -f - <<EOF
   apiVersion: "authentication.istio.io/v1alpha1"
   kind: "Policy"
   metadata:
     name: mysql-mtls-authn
   spec:
     targets:
     - name: YOUR-MYSQL-SERVICE     # The name of *your* K8s Service
     peers:
     - mtls:
         mode: STRICT
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     name: mysql-mtls-dr
   spec:
     host: YOUR-MYSQL-SERVICE     # The name of *your* K8s Service
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

支持。Istio 对网格中的 HTTP 服务和普通 TCP 服务提供授权特性支持了解更多。

是的，Istio 认证的密钥和证书分发基于 Kubernetes secret 实现。

Secret 安全风险需知。 Kubernetes 团队正在研究多种特性，以从 secret 加密到节点级访问控制，全面增强 Kubernetes secret 的安全性。 从 1.6 版本开始，Kubernetes 引入了 RBAC 认证，可以提供细粒度的 secret 管理。

默认情况下，它们是 base64 编码的，但未加密。但是，您可以按照 Kubernetes 中支持的加密特性来进行操作。

请注意，在 Google Container Engine (GKE) 中尚未启用此功能。尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照此处 。

依照安全入口流量任务中的描述进行配置，可以确保 Istio Ingress 只处理 TLS 连接。

可以，并且启用或禁用双向 TLS 都可以。