问题描述
在将一个经典的 .NET 应用程序与 Kestrel 集成到 Kubernetes、OpenShift 和 AWS EKS 中时，遇到了一些关于证书处理的问题。应用程序需要在启动时进行以下两个关键步骤：
1. 在容器启动时信任自己的 CA（证书颁发机构），用户可以通过执行 docker exec -u root update-ca-certificates 命令来实现。
2. 用户可以将自己的证书添加到一个与镜像运行时挂载的卷中，并且应用程序会从该路径读取证书。
用户已经通过 Dockerfile 创建了一个自定义镜像，以便在容器启动时通过运行 update-ca-certificates 命令来解决第一个问题。然而，用户遇到了以下两个问题：
1. 由于不能以 root 用户身份运行应用程序（遵循最佳实践），如何让客户能够上传证书到应用程序？
2. 如果客户拥有自己的使用自签名证书的 MSSQL 集群，那么我的应用程序将拒绝与其连接。在无法以 root 用户身份执行命令的情况下，如何让客户的 CA 被信任？
解决方案
请注意以下操作可能因不同环境而异，涉及到特权和安全性问题，请在实际操作前仔细阅读相关文档，并进行适当的测试。
解决方案1：允许用户上传证书
对于第一个问题，用户可以通过以下方法允许客户上传证书，而不需要 root 权限：
使用 Secret 或 ConfigMap：在 Kubernetes 或 OpenShift 中，您可以让客户将其证书作为 Secret 或 ConfigMap 部署到集群中。然后，您的应用程序可以从这些 Secret 或 ConfigMap 中读取证书。这样的好处是，客户不需要直接访问容器文件系统，也不需要 root 权限。
使用 Init Container：您可以创建一个 Init Container，它以 root 用户身份运行，并负责将客户提供的证书从一个共享的卷（例如 NFS）拷贝到您的应用程序容器挂载的卷中。然后，您的应用程序可以从该卷中读取证书。
解决方案2：信任客户的自签名证书
对于第二个问题，您可以考虑以下方法来让客户的自签名证书被信任：
使用自定义CA：将您的自定义 CA 的根证书添加到应用程序容器中，并在应用程序中配置来信任该 CA。然后，您可以在应用程序中忽略证书验证错误，使得连接到客户的 MSSQL 集群时不会因为证书问题而失败。
自定义证书验证逻辑：您可以编写自己的证书验证逻辑，以允许您信任客户的自签名证书。这需要对您的应用程序进行修改，以便在连接时跳过默认的证书验证流程，改为使用您自定义的验证逻辑。
解决方案3：Sidecar 容器
另一个选择是在同一个 Pod 中运行一个 Sidecar 容器，该容器以 root 用户身份运行，并且负责执行特定的任务，比如处理证书上传或执行特定的命令。然后，您的主要应用程序容器以非 root 用户身份运行，而且不需要直接处理特权操作。
总结
在 Kubernetes、OpenShift 和 AWS EKS 中以非 root 用户身份处理证书需要一些创意性的方法。您可以使用 Secret、ConfigMap、Init Container、自定义 CA 或自定义证书验证逻辑来解决证书管理和信任的问题。选择最适合您场景的方法，并根据实际需要进行适当的调整和测试。