【问题标题】:How to set TLS to a service in EKS with PCA on AWS?如何在 AWS 上使用 PCA 将 TLS 设置为 EKS 中的服务?
【发布时间】:2022-01-06 08:11:00
【问题描述】:

我通过这篇文章使用 AWS PCA 和 cert-manager 创建了一个启用 TLS 的服务: https://aws.amazon.com/blogs/security/tls-enabled-kubernetes-clusters-with-acm-private-ca-and-amazon-eks-2/

在我部署了一个带有入口的演示应用程序后,我在控制节点上测试了访问

$ curl https://demo.my-org.com --cacert cacert.pem

收到消息

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

cacert.pem 是从 AWS PCA 的证书正文下载的。 AWSPCAClusterIssuer 和证书在 K8s 中看起来不错。证书描述得到了这些事件:

$ kubectl describe certificate rsa-cert-2048 -n acm-pca-lab-demo
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    47m   cert-manager  Existing issued Secret is not up to date for spec: [spec.commonName spec.dnsNames]
  Normal  Reused     47m   cert-manager  Reusing private key stored in existing Secret resource "rsa-example-cert-2048"
  Normal  Requested  47m   cert-manager  Created new CertificateRequest resource "rsa-cert-2048-pp4c4"
  Normal  Issuing    47m   cert-manager  The certificate has been successfully issued

如果我从浏览器访问得到 502 错误。证书页面显示了一个假证书和一个 alt DNS 名称。

我确定 AWS 中的私有 CA 已成功激活。它的 arn 和区域被设置为 EKS 节点策略和 AWSPCAClusterIssuer。设置有什么问题?如何诊断问题?


部署的资源

我检查了 acm-pca-lab-demo 命名空间中部署的资源。

$ kubectl get secret -n acm-pca-lab-demo
NAME                    TYPE                                  DATA   AGE
default-token-jmxt7     kubernetes.io/service-account-token   3      10h
rsa-example-cert-2048   kubernetes.io/tls                     3      10h

$ kubectl get all -n acm-pca-lab-demo
NAME                               READY   STATUS    RESTARTS   AGE
pod/hello-world-57df4c69f9-nnjrl   1/1     Running   0          10h
pod/hello-world-57df4c69f9-r8f4p   1/1     Running   0          10h
pod/hello-world-57df4c69f9-xgm6w   1/1     Running   0          10h

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/hello-world   ClusterIP   102.30.45.163   <none>        80/TCP    10h

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hello-world   3/3     3            3           10h

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/hello-world-57df4c69f9   3         3         3       10h

$ kubectl get ingress -n acm-pca-lab-demo
NAME                   CLASS    HOSTS             ADDRESS                                                                          PORTS     AGE
acm-pca-demo-ingress   <none>   demo.my-org.com   11111111111111111111111111111111-2222222222222222.elb.us-east-1.amazonaws.com    80, 443   10h

在浏览器上,我也收到了这些消息:

The certificate is not trusted because it is self-signed.


HTTP Strict Transport Security: false

HTTP Public Key Pinning: false

证书文件

我在这里从 AWS 控制台下载了 PCA .pem 文件。对吗?

它是-----BEGIN CERTIFICATE----- 开始的文件。

【问题讨论】:

    标签: amazon-web-services ssl


    【解决方案1】:

    检查您的 ingress 配置,共享您在应用程序部署中使用的 YAML 配置(如果可能)。

    可能没有secret附加到入口,因为K8s Nginx入口 控制器默认附加默认FAKE 证书而不是您生成的证书。

    例如:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: acm-pca-demo-ingress
      namespace: acm-pca-lab-demo
      annotations:
        kubernetes.io/ingress.class: "nginx"
    spec:
      tls:
      - hosts:
        - www.rsa-2048.example.com
        secretName: rsa-example-cert-2048
      rules:
      - host: www.rsa-2048.example.com
        http:
          paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: hello-world
                port:
                  number: 80
    

    如上图rsa-example-cert-2048,确保你的secret存在于入口所在的命名空间中。

    【讨论】:

    • 感谢您的回答。我检查了这个演示的部署。似乎秘密在同一个命名空间中。我在问题的底部添加了一些信息。也许证书本身有问题。我刚刚从 AWS 控制台下载了它。但是这次没有 502 bad gateway。我可以看到网站。只有 TLS 不起作用。
    • 是的,可能会错过证书或机密中的某些内容。
    • 我添加了certificate file 进入问题的底部。对吗?
    • 如果证书是自签名的,浏览器可能不会允许它,除非您在浏览器中将其添加为受信任。
    • 是的,让我们加密更好,但如果您在后台使用 ACM,我还没有正确阅读整个解决方案,它也使用 let 加密,但自定义 CA 和自签名不会被浏览器信任,除非我们添加它们。
    猜你喜欢
    • 1970-01-01
    • 2022-12-12
    • 2019-07-14
    • 1970-01-01
    • 2015-09-22
    • 1970-01-01
    • 1970-01-01
    • 2021-04-28
    • 2020-01-08
    相关资源
    最近更新 更多