安全 mTLS 健康检查端点上的 Kubernetes 活跃度探测答案

【问题标题】：Kubernetes liveness probe on a secure mTLS health check endpoint安全 mTLS 健康检查端点上的 Kubernetes 活跃度探测
【发布时间】：2021-01-09 17:29:49
【问题描述】：

我需要一些帮助来解决特定的 Kubernetes + mTLS 问题。

请问如何让 Kubernetes 活跃度探测在安全的 https mTLS 健康检查端点上工作？

我的应用程序是一个 Web 应用程序，其中健康检查端点通过特定端口公开，与其他业务端点相同。

根据安全性、审计和合规性审查，我必须通过 mTLS 保护我的所有端点，即使是简单且无害的健康检查端点。

根据安全、审计和合规审查，我不能暴露任何其他端口，例如在 https 端口 1 上做我的业务端点，但在 http 端口 2 上做健康。

因此，这是失败并将我的应用程序标记为关闭（因为它通过简单的 http，端点是 https）

          livenessProbe:
            httpGet:
              path: /health
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10

为了在测试期间确认，我们禁用了 https 和 mTLS，启用了普通的旧 http，一切正常，但我们根本无法做到。

请问这个问题怎么解决？

谢谢。

【问题讨论】：

您是否在集群中使用 Istio？你查了吗istio.io/latest/docs/tasks/security/authentication/authn-policy/…
您好，Marius，感谢您的评论。遗憾的是，我们没有使用 Istio，希望我能找到一个解决方案，而无需添加太多依赖项。
恐怕kubernetes默认不支持。
:'( 感谢 Marius 的评论！

标签： kubernetes https kubernetes-health-check mtls

【解决方案1】：

您可以尝试更改方案：HTTP 到 HTTPS 吗？

livenessProbe： http获取：路径：/健康端口：8080 方案：HTTPS 初始延迟秒数：10 periodSeconds: 10

如果 scheme 字段设置为 HTTPS，kubelet 发送 HTTPS 请求跳过证书验证。

【讨论】：

【解决方案2】：

我正在研究针对同一问题的解决方案。我打算做的是在 pod 内拥有一个受信任的证书，而不是使用 http 探针，而是使用命令探针并使用该证书从 pod 内部 curl 我的健康检查端点。

【讨论】：

【解决方案3】：

您可以使用脚本进行就绪探测。在该脚本中，您可以在端点上进行简单的 cURL，还可以提供所需的证书和 CA 证书。

例如：

curl -k https://<url>/health -v –key key.pem –cacert ca.pem –cert client.pem

我假设证书应该秘密存储在同一个命名空间中。因此，您可以在 pod 中挂载具有证书的秘密，以便您的脚本可以使用这些路径来访问证书。

【讨论】：

虽然这是一个使用 shell 脚本的解决方案，但我真的希望有一个使用它已经存在的 HTTP 探针的本机解决方案。此外，我们的基础镜像是经过审核的，无法安装 curl、wget 等。但是，我相信这是一个可行的解决方案
您可以尝试将方案：http 更改为 https 吗？ livenessProbe: httpGet: path: /health port: 8080 scheme: HTTPS initialDelaySeconds: 10 periodSeconds: 10

【解决方案4】：

相互 TLS (mTLS) 旨在保证两端的真实性，这意味着探测方 (kubelet) 必须有权访问它用来在 识别自己以及其他人的密钥和证书运行时。 Kubernetes 没有这个内置的，一个众所周知的解决方案是here。如果您不想直接部署该解决方案，则有许多嵌入该解决方案的服务网格解决方案。 Istio、Nginx Service Mesh、AWS App Mesh……仅举几例。

【讨论】：

【解决方案5】：

首先，能否确认是否有任何操作或8080端口正在使用中？（检查部署或 pod yaml 文件并确保您已引用它）。如果那里没有发生任何事情，您的健康检查将失败
能否删除设置为 HTTP 的“方案”部分？ HTTP 是默认方案，因此它是多余的，除非您想将其更改为 HTTPS
路径：/health 需要有效，确保它存在于应用程序中。

【讨论】：

感谢您的回答！ 1 - 是的，已确认，许多客户都在使用超过 8080（但使用 httpS）的服务。他们正在很好地获得业务有效负载响应。 2 - 是的，无论是否删除，通过 mTLS 进行的健康检查都失败了。 3 - 是的，有效，再次通过httpS，不计划http

【解决方案6】：

如果您不想遵循上述方法，则可以在 pod 内打开一个不会通过服务公开的端口。它将在 pod 内部，可用于准备就绪或活跃性目的。微服务现在遵循这些方法。

【讨论】：

第二个端口也是 https。我不认为在一项服务中，一个端口可以通过http打开，一个通过https
可以的。但这里我说的是在你的 pod 内打开端口。