.Net Core 微服务：在 Azure (AKS) 上的 Kubernetes 上使用 HTTPS [关闭]

Question

我正在使用 Linux 将各种 .NET 核心 API 项目容器化并在 Kubernetes 集群中运行它们。我对这种情况相当陌生（我通常将应用服务与 Windows 一起使用），并且开始出现有关安全连接最佳实践的问题：

1. 由于这些将作为集群内的 pod 运行，我的假设是我只需要公开端口 80 对吗？这都是由服务和入口管理的内部流量。但这是一个好习惯吗？一旦我使用证书配置域并且安全流量开始到达正在运行的 pod，是否会出现问题？

2. 到了集成 SSL 的时候，我将不得不担心在容器上打开端口 443 或管理容器本身内的任何证书，或者这一切都将由 Ingress、Services（或应用程序网关，因为我正在使用AKS)?现在，当我需要使用 HTTPS 在本地进行测试时，我必须向容器添加自签名证书并打开端口 443，我的假设是这不应该用于生产！

3. 当我部署到我的集群（我正在使用 AKS）时，只打开了 80 端口并分配了一个 LoadBalancer 服务，我得到了一个公共 IP 地址。我习惯于使用 Azure App Services，您可以在其中使用开箱即用的全局 Miscrosoft SSL 证书，如下所示：https://your-app.azurewebsites.net 但是，当我转到公共 IP 并配置 DNS 标签时就像是： your-app.southcentralus.cloudapp.azure.com 它不允许我像应用服务那样使用 HTTPS。 IP地址也没有。也许我的 Kubernetes 实例没有正确配置一些东西？

4. 由于其中许多服务将是面向公众的 API 端点（但由客户端应用程序使用），因此它们不需要自定义域名，因为大多数公众不会看到它们。有没有办法利用 IP 地址或 .cloudapp.azure.com 域的安全连接？如果我必须为我的每项服务管理证书，那将是成本/时间过高！

Answer 1

1. 这取决于您要终止 TLS 的位置。对于大多数用例，入口控制器是终止 TLS 流量并将所有内容保存在集群内的 HTTP 上的好地方。在这种情况下，任何 HTTP 端口都应该可以正常工作。如果 80 端口默认被 Dotnet core 暴露，那么你应该保留它。

2. 您在本地打开端口 443，因为您没有配置入口控制器。您也可以在本地安装 ingress。在生产环境中，只要入口控制器正在处理 TLS 流量，您就不需要打开单个 HTTP 端口之外的任何其他端口。

3. 理想情况下，您不应将每项服务都公开为负载均衡器。服务应该是ClusterIP 类型，只在集群内部公开。当您部署一个入口控制器时，它将创建一个负载均衡器服务。这将是集群中的唯一入口点。然后，入口控制器将通过主机名或路径接受流量并将其路由到各个服务。

4. Let's Encrypt 是一项免费的 TLS 证书签名服务，可用于您的设置。如果您不拥有该域名，您可以使用 https-01 质询来验证您的身份并获取证书。 Cert Manager 项目可以轻松地在任何 k8s 集群中配置 Let's Encrypt 证书。

• https://cert-manager.io/docs/installation/kubernetes/
• https://cert-manager.io/docs/tutorials/acme/ingress/（如果您使用 kubectl 或 helm3 部署了 Tillter 部分，请忽略它）

侧边栏：如果您使用应用程序网关来前端应用程序，请考虑使用Application Gateway Ingress Controller