Question

在我的10台机器裸机Kubernetes集群中，一项服务需要调用另一台使用自签名证书的基于https的服务。但是，由于此自签名证书未添加到pod的受信任根ca中，因此调用失败，说无法验证x.509证书。

所有pod都基于ubuntu docker镜像。但是，在ubuntu上添加ca cert到信任列表的方法（使用dpkg-reconfigure ca-certificates）不再适用于此pod。当然，即使我成功地将ca证书添加到一个pod上的信任root，当另一个pod被踢时它就消失了。

我搜索了Kubernetes文档，并且惊讶没有找到任何除了配置证书与API服务交谈，这不是我正在寻找的。如果pod之间需要任何安全通道，这应该是很常见的情况。有什么想法吗？

Answer 1

如果要在运行时烘烤证书，请编辑Dockerfile，添加命令以从构建上下文复制证书并更新信任。您甚至可以将此广告作为docker hub等中的内容的层。

COPY my-cert.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates

如果您尝试在运行时更新信任关系，事情将会变得更加复杂。我自己还没有完成此操作，但是您可能可以创建包含证书的configMap，将其安装到上述路径的容器中，然后使用入口点脚本在您运行之前运行update-ca-certificates主要过程。

Answer 2

如果遇到您的情况，我可以想到3种解决方案：
选项1。）（我只能提供唯一完整的解决方案，不幸的是我的其他解决方案是一半的解决方案，这归功于Paras Patidar /以下站点：）
https://medium.com/@paraspatidar/add-ssl-tls-certificate-or-pem-file-to-kubernetes-pod-s-trusted-root-ca-store-7bed5cd683d

1。）将证书添加到配置映射：可以说您的pem文件是my-cert.pem
kubectl -n <namespace-for-config-map-optional> create configmap ca-pemstore — from-file=my-cert.pem

2。）将configmap作为卷挂载到容器的退出CA根目录位置：例如，将配置映射文件作为一对一文件关系挂载在目录/ etc / ssl / certs /中的卷挂载中，例如

apiVersion: v1 
kind: Pod
metadata:
  name: cacheconnectsample
spec:
      containers:
      - name: cacheconnectsample
        image: cacheconnectsample:v1
        volumeMounts:
        - name: ca-pemstore
          mountPath: /etc/ssl/certs/my-cert.pem
          subPath: my-cert.pem
          readOnly: false
        ports:
        - containerPort: 80
        command: [ "dotnet" ]
        args: [ "cacheconnectsample.dll" ]
      volumes:
      - name: ca-pemstore
        configMap:
          name: ca-pemstore

所以我相信这里的想法是/ etc / ssl / certs /是Pod信任的tls证书的位置，并且subPath方法允许您添加文件而无需清除文件夹的内容，将包含k8s的秘密。
如果所有Pod都共享此mountPath，则可以将Pod存在并向每个名称空间添加configmap，但这在alpha中，仅对静态名称空间有用。（但是如果这是真的，那么您所有的Pod都会信任该证书。）

选项2。）（半解决方案/想法+不能完全回答您的问题，但可以解决您的问题，我相当有信心在理论上可行，需要您自己进行研究，但我认为您会发现这是最好的选择：）
从理论上讲，您应该能够利用cert-manager + external-dns + Lets Encrypt Free +一个公共域名来用公共证书替换自签名证书。
（证书管理器的最终结果是在群集中自动生成一个由Lets Encrypt Free签名的k8s tls机密，它们具有dns01挑战，可用来证明您拥有证书，这意味着您应该能够利用该证书解决方案，即使没有入口/即使群集仅用于专用网络也是如此。）

选项3。）（半解决方案/想法，可能在理论上可行，需要您自己进行研究）
我认为kubespray（适用于kubeadm的包装）可以帮助您指定构建群集所使用的证书，因此，如果您的组织中有一个CA，则可以使用该证书来签名证书，然后使用该证书构建您的群集，那么您的群集API证书将是中间证书您的组织机构的证书。

Kubernetes将ca证书添加到pods的trust root中

2 个答案: