Certificates#

EDB CloudNativePG Global クラスターは、TLS証明書をネイティブにサポートするように設計されました。 PGDクラスターをセットアップするには、各PGDノードに以下が必要です。

サーバー証明書の構成。
クライアント証明書の構成。

注釈

クラスターPGDノードのステータスで、各PGDノードが使用するすべてのシークレットと有効期限を見つけることができます。

サーバー証明書の構成#

サーバー証明書構成は、PGDGroupカスタムリソースのspec.connectivity.tls.serverCert セクションで処理されます。この構成では、サーバーCAシークレットとcert-managerテンプレートを使用して、基になるPostgresインスタンスがTLS接続を終了するために必要なTLS証明書を生成します。

このセクションが正常に機能するには、次の前提条件を満たす必要があります。

Cert-managerをインストールする必要があります。
spec.connectivity.tls.serverCert.certManager.issuerRef で指定された発行者は、 spec.connectivity.dns.domain で指定されたドメインとspec.connectivity.tls.serverCert.certManager.spec.dnsNames にリストされている追加ドメインで利用できます。
発行者が使用するCAのパブリック証明書を含むサーバーCAシークレットを作成する必要があります。

注釈

spec.connectivity.tls.clientCert.serverCA で指定されたサーバーCAシークレットは、基になるCNPノードで`serverCASecret` として参照されます。パブリック部分 ca.crt は、サーバー証明書を検証し、 sslrootcert としてクライアント接続文字列に含まれます。プライベート部分 ca.key は、自己署名証明書が使用される場合、サーバーSSL証明書に自動的に署名するために使用されます。

注釈

PGDグループによって生成されたサーバーTLSシークレットは、基になるCNPノードの`serverTLSSecret` の値として指定されます。詳細については、 server certificates を参照してください。

DNS名#

オペレーターは、次のaltDnsNames をサーバーTLS証明書に追加します。

${nodeName}${hostSuffix}.${domain}
${groupName}${hostSuffix}.${domain}
${proxyName}${hostSuffix}.${domain}
${nodeName}${additionalHostSuffix}.${additionalDomain}
${groupName}${additionalHostSuffix}.${additionalDomain}
${proxyName}${additionalHostSuffix}.${additionalDomain}

ユーザーは、基になるネットワークアーキテクチャたとえば、ノードにアクセスするロードバランサーなどに基づいて、spec.connectivity.tls.serverCert.certManager.spec.dnsNames に必要な名前を含める責任があります。

たとえば、次のように構成されたPGDグループを検討します。

apiVersion: pgd.k8s.enterprisedb.io/v1beta1
kind: PGDGroup
metadata:
  name: region-a
spec:
  instances: 3
  ...
  connectivity:
    dns:
      # we need to configure the domain for the group so it could be resolved
      domain: enterprisedb.network
      additional:
        - domain: alternate.network
          hostSuffix: -dc1

次のすべてのサブジェクト代替名SANはサーバーTLS証明書に追加されます。

region-a-1-node.domain.enterprisedb.network
region-a-group.domain.enterprisedb.network
region-a-proxy.domain.enterprisedb.network
region-a-1-node-dc1.alternate.network
region-a-group-dc1.alternate.network
region-a-proxy-dc1.alternate.network

クライアント証明書の構成#

クライアント証明書構成は、PGDGroupカスタムリソースのspec.connectivity.tls.clientCert セクションで管理されます。この構成では、クライアントCAシークレットとクライアントcert-managerテンプレートを使用して、streaming_replica Postgresユーザーのクライアントストリーミングレプリケーション証明書を生成する必要があります。

このセクションが正常に機能するには、次の前提条件を満たす必要があります。

Cert-managerをインストールする必要があります。
spec.connectivity.tls.clientCert.certManager.issuerRef で指定された発行者が利用できます。この発行者は、一般名streaming_replica を持つ証明書に署名するために使用されます。
クライアントCAシークレットが存在する必要があります。これには、発行者が使用するCAのパブリック証明書が含まれています。

オペレーターは、spec.connectivity.tls.clientCert.certManager の下の構成を使用して、streaming_replica Postgresユーザーの証明書要求を作成します。結果の証明書は、ノード間の通信を安全にするために使用されます。

注釈

spec.connectivity.tls.clientCert.clientCA で指定されたクライアントCAシークレットは、基になるCNPノードの`clientCASecret` の値として使用されます。パブリック部分`ca.crt` は、ssl_ca_file としてすべてのインスタンスに提供され、署名したクライアント証明書を検証できます。プライベート部分 ca.key はオプショナルで、 kubectl cnp plugin によって生成されたクライアント証明書に署名するために使用できます。

クライアントの事前プロビジョニングされたレプリケーション証明書#

または、 spec.connectivity.tls.clientCert.preProvisioned.streamingReplica.secretRef オプションを使用して、streaming_replica ユーザーの事前プロビジョニングされたクライアント証明書を含むシークレットを指定できます。この場合、証明書のライフサイクルは、シークレットの内容を更新するだけで、サードパーティによって手動または自動で完全に管理されます。

注釈

クライアントストリーミングレプリケーション証明書が提供される方法に関係なく、基になるCNPノードで`replicationTLSSecret` の値として使用されます。詳細については、 Client certificate のセクションを参照してください。

TLSモード#

spec.connectivity.tls.mode を使用して、ノード間の通信中にサーバー証明書を検証する方法を決定するTLSモードを構成できます。デフォルト値はverify-ca です。 PGDグループが設定されると、TLSモードは変更できないことに注意してください。 PostgreSQLドキュメントの SSL Support に記載されているように、 mode は次の値を受け入れます。

verify-full
verify-ca
required

自己署名の例#

この例は、cert-managerを使用して自己署名CAをセットアップし、必要な証明書を生成する方法を示しています。

最初に、サーバーとクライアントのCA証明書を生成する必要があります。ターゲット名前空間に2つの自己署名発行者 server-ca-issuer およびclient-ca-issuer を作成します。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
- --
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: server-ca-issuer
spec:
  ca:
    secretName: server-ca-key-pair
- --
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: client-ca-issuer
spec:
  ca:
    secretName: client-ca-key-pair

次の証明書オブジェクトを使用して、プライベートキーと発行者から署名された証明書を生成できます。プライベートキーと署名された証明書は、 server-ca-key-pair およびclient-ca-key-pair という名前のシークレットに保存されます。

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: server-ca
spec:
  isCA: true
  commonName: my-selfsigned-server-ca
  secretName: server-ca-key-pair
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
    group: cert-manager.io
- --
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: client-ca
spec:
  isCA: true
  commonName: my-selfsigned-client-ca
  secretName: client-ca-key-pair
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
    group: cert-manager.io

PGDグループを構成できるようになりました。 server-ca-key-pair およびclient-ca-key-pair は、それぞれサーバーCAシークレットとクライアントCAシークレットとして使用されます。 cert-managerテンプレートは、対応する発行者を参照するように設定して、サーバーTLS証明書とクライアントレプリケーション証明書を自動的に生成できます。

apiVersion: pgd.k8s.enterprisedb.io/v1beta1
kind: PGDGroup
metadata:
  name: region-a
spec:
  ...
  connectivity:
    tls:
      mode: verify-ca
      clientCert:
        caCertSecret: client-ca-key-pair
        certManager:
          spec:
            issuerRef:
              name: client-ca-issuer
              kind: Issuer
              group: cert-manager.io
      serverCert:
        caCertSecret: server-ca-key-pair
        certManager:
          spec:
            issuerRef:
              name: server-ca-issuer
              kind: Issuer
              group: cert-manager.io

証明書の仕組みの詳細については、 :ref:` EDB CloudNativePG Cluster documentation <Certificates>` を参照してください。

Certificates

目次

Certificates#

サーバー証明書の構成#

DNS名#

クライアント証明書の構成#

クライアントの事前プロビジョニングされたレプリケーション証明書#

TLSモード#

自己署名の例#