常见的安全问题

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

认证策略可以配置为 网格范围（影响网络中的所有服务）、命名空间范围（命名空间中的所有服务）或某个特定服务。 您可以根据需要对集群中的服务配置一种或多种 TLS 双向认证策略。

如果您使用 values.global.proxy.privileged=true 参数安装 Istio， 您可以使用 tcpdump 来确定加密状态。同样在 Kubernetes 1.23 及以后的版本中， 作为将 Istio 安装为特权用户的另一种选择，您可以使用 kubectl debug 在临时容器（Ephemeral Container） 中运行 tcpdump。有关说明，请参见 Istio 双向 TLS 迁移。

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

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

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

如果启用了双向 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

不排除，当 traffic.sidecar.istio.io/excludeInboundPorts 用于服务器工作负载时， Istio 仍然默认配置客户端 Envoy 以发送双向 TLS 请求。要改变这一点，您需要配置一个目标规则， 将双向 TLS 模式设置为 DISABLE，用以让客户端发送纯文本到这些端口。

安装 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 Ingress 只处理 TLS 连接。

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