帶有證書管理器的 K8s 內部 ACME 服務器，僅用於發布內部 k8s 證書-htttp 挑戰問題

Question

是否可以使用 cert-manager 僅在其中一個命名空間中具有 ACME 服務器的集群中為工作負載生成證書？ 據我了解，cert-manager 嘗試通過退出集群和進入集群來訪問 dns 名稱以進行 http chalange，但是如果我不想離開集群怎么辦？ 我不希望 cert-manager 創建 Ingress 資源。 讓整個挑戰發生在集群內部。

我的情況：

• 我的一個命名空間中有 ACME 服務器（step-ca）
• 我需要在另一個命名空間中為我的 POD 創建證書，例如通用名稱“${app}.${namespace}”

備注：在我的情況下，由於板上的 istio，問題更加復雜。 對於入口流量，cert-manager 可以與內部 ACME 服務器正常工作，但對於出口流量，我需要通過 stunnel（在每個 POD 中）才能到達外面的 Squid，我需要這些證書用於 stunnel。

Answer 1

我想出的唯一方法：

每個應用程序都有自己的 Issuer

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: k8s-acme-local
  namespace: ${APP_NS}
spec:
  acme:
    email: some@email
    privateKeySecretRef:
      name: k8s-acme-local
    server: https://${ACME_SVC}.${ACME_NS}/acme/acme/directory
    solvers:
    - http01:
        ingress: 
          podTemplate:
            metadata:
              labels:
                app: ${APP}
          ingressTemplate: {}
          serviceType: ClusterIP

在創建證書資源之前，我創建了服務來接管到${APP}.{APP_NS}的流量

apiVersion: v1
kind: Service
metadata:
  name: ${APP}
  namespace: ${APP_NS}
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8089
  selector:
    app: ${APP}
  sessionAffinity: None
  type: ClusterIP

然后是證書資源：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ${APP}
  namespace: ${APP_NS}
spec:
  secretName: ${APP}
  issuerRef:
    name: k8s-acme-local
    kind: Issuer
    group: cert-manager.io
  commonName: ${APP}.${APP_NS}
  dnsNames: 
  - ${APP}.${APP_NS}

現在 Acme 服務器將對我的服務進行挑戰，而不是通過保持未使用的 Ingress（和 cer-manager 服務）。 我不喜歡它，但它有效。 這種方法有一個嚴重的缺點。 集群中的每個人都可以這樣做並模擬任何現有或不存在的應用程序。 我期待您的意見和建議。