首页 文章

Google Kubernetes Engine：为服务类型启用HTTPS

提问于
浏览 次
13

我在GKE上有一个应用程序，我希望仅通过HTTPS提供，因此我获得了一个签名证书，以使用TLS保护应用程序 .

我已经查看了很多有关如何执行此操作的教程，但它们都是指使用Ingress并使用LetsEncrypt和KubeLego自动请求证书 . 但我希望继续使用外部负载 balancer 器（谷歌提供给我的计算引擎实例），但我只想通过https访问我的应用程序 .

如何应用我的server.crt和server.key文件来启用https.Do I apply it to the Load balancers或kubernetes集群 .

kubernetes google-cloud-platform devops

3 回答

  • 3

    在通过HTTPS公开您的应用程序时，Ingress可能是您最好的选择 . Ingress资源指定后端服务，因此您将继续将您的应用程序公开为Kubernetes服务，只需将类型设置为 ClusterIP 即可 . 这将为您的群集生成一个"internal"服务，并且一旦您进行设置，就可以通过Ingress从外部访问 .

    现在，特别是在Google Kubernetes Engine（GKE）中，群集中定义的任何入口资源都将由Google Cloud Load Balancer提供，因此我认为您不必担心部署自己的Ingress Controller（例如Nginx Ingress Controller） .

    就TLS而言，如果您有证书，可以使用自己的证书 . 必须通过Kubernetes Secret将证书上载到群集 . 一旦定义了该秘密，您就可以在Ingress定义中引用该秘密 . （https://kubernetes.io/docs/concepts/services-networking/ingress/#tls）

    您可以使用以下命令创建密钥：

    kubectl create secret tls my-app-certs --key /tmp/tls.key --cert /tmp/tls.crt

    一旦掌握了秘密，就可以在入口资源中引用它：

    apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  tls:
  - secretName: my-app-certs
  backend:
    serviceName: s1
    servicePort: 80

    创建入口资源后，GKE将配置负载均衡器并为您提供可以使用的可公开访问的IP：

    kubectl get ingress my-app-ingress

    以下是一个很好的教程，带您了解Ingress on GKE：https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer

    回复于
  • 2

    Ingress是最简单的方法 . 您不需要使用LetsEncrypt，您可以指定自己的证书 .

    Ingress控制器只是一个NGINX代理 . 如果你不想使用入口（为什么？），你必须自己创建这个代理服务 . 这基本上是这项服务的入口 .

    回复于
  • 7

    The solution:

    在运行时获取证书，许多人使用LetsEncrypt是因为它有多么容易，但您可以将证书存储在实际安全的存储中，例如您的 Cloud 平台's Key Management Store, or run your own Hashicorp Vault (I recommend Hashicorp Vault, it'非常好！）然后在运行时安全地检索您的机密 .

    您注意到每个教程或指南都建议动态获取它们 .

    但他们都提到使用Ingress并使用LetsEncrypt和KubeLego自动请求证书 .

    其原因如下：

    https://kubernetes.io/docs/concepts/configuration/secret/#risks

    风险在API服务器中，秘密数据以明文形式存储在etcd中;因此：管理员应限制对管理员用户的etcd访问权限API服务器中的秘密数据在etcd使用的磁盘上处于静止状态;管理员可能想要在不再使用时擦除/粉碎etcd使用的磁盘可以创建使用密钥的pod的用户也可以看到该秘密的值 . 即使apiserver策略不允许该用户读取秘密对象，用户也可以运行暴露秘密的pod . 如果运行了etcd的多个副本，则它们之间将共享秘密 . 默认情况下，etcd不保护与SSL / TLS的对等通信，但可以配置 . 目前，任何在任何节点上具有root权限的人都可以通过模拟kubelet从apiserver中读取任何秘密 . 计划的功能是仅向实际需要它们的节点发送秘密，以限制根漏洞对单个节点的影响 .

    因此，每个人都正确地建议您 DO NOT USE K8s SECRETS 用于存储您的宝贵证书，因为它不适合工作 .

    回复于

相关问题