安全常见问题

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

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

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

启用 STRICT 双向 TLS 时，非 Istio 工作负载无法与 Istio 服务通信，因为它们没有有效的 Istio 客户端证书。

如果需要允许这些客户端，可以将双向 TLS 模式配置为 PERMISSIVE，允许明文和双向 TLS。 这可以针对单个工作负载或整个网格来完成。

有关更多详细信息，请参阅 身份验证策略。

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 颁发的证书。

有几种选择：

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

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

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

对于在 Kubernetes 中运行的工作负载，其 Istio 证书的生命周期默认为 24 小时。

可以通过自定义 代理配置的 proxyMetadata 字段来覆盖此配置。 例如：

proxyMetadata:
  SECRET_TTL: 48h

安装 Istio 后，您可能会发现 MySQL 无法连接。 这是因为 MySQL 是 服务器优先 协议， 这会干扰 Istio 的协议检测。 特别是，使用“PERMISSIVE”mTLS 模式可能会导致问题。 您可能会看到诸如 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 这样的错误。

这可以通过确保使用 STRICT 或 DISABLE 模式或配置所有客户端来解决 发送 mTLS。 有关详细信息，请参阅 服务器优先协议。

支持。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 都可以。