Certificates

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

サーバー認証局CA証明書
サーバーCAによって署名されたサーバーTLS証明書
クライアントCA証明書
クライアントCAによって生成されたストリーミングレプリケーションクライアント証明書

注釈

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

CloudNativePGは、TLS証明書に関して非常に柔軟です。主に2つのモードで動作します。

オペレーター管理モード –証明書は完全に自動化された方法でオペレーターによって内部管理され、CloudNativePGによって作成されたCAを使用して署名されます。
ユーザー提供の証明書モード – 証明書はオペレーターの外部で生成され、シークレットとしてクラスター定義にインポートされます。 CloudNativePGは cert-manager と自分自身を統合します

Cert-managerの例を参照してください。

証明書の一部のみがCNPG外部で生成されるハイブリッドアプローチを選択することもできます。

注釈

オペレーターとインスタンスは、DNS名を無視して、CAのみに対してサーバー証明書を検証します。このアプローチは、クラスター内の通信に使用される`<cluster>-rw` サービスのユーザー指定証明書にDNS名が一般的に欠如しているためです。

オペレーター管理モード

デフォルトでは、オペレーターは単一の認証局CAを自動的に生成して、クライアントとサーバーの証明書の両方を発行します。これらの証明書は事業者によって継続的に管理され、有効期限の7日前に自動更新されます90日の有効期間内。

注釈

CERTIFICATE_DURATION および`EXPIRING_CHECK_THRESHOLD` 環境変数を構成することにより、このデフォルトの動作を調整できます。詳細なガイダンスについては、 Operator configuration を参照してください。

注釈

単純なリロード操作で十分であるため、証明書の更新はPostgreSQLサーバーのダウンタイムを発生させません。ただし、CloudNativePGによって制御されないユーザー管理証明書は、更新プロセスの後に再発行する必要があります。

証明書を生成するとき、オペレーターは、KubernetesクラスターのDNSゾーンがデフォルトでcluster.local に設定されていることを想定しています。この動作は、 KUBERNETES_CLUSTER_DOMAIN 環境変数を設定することによりカスタマイズできます。便利な代替方法は、 operator's configuration capability を使用することです。

サーバー証明書

サーバーCAシークレット

オペレーターは、自己署名CAを生成し、次のキーを含む汎用シークレットに保存します。

ca.crt – サーバー証明書の検証に使用されるCA証明書。クライアントの接続文字列でsslrootcert として使用されます。
ca.key – サーバーSSL証明書に自動的に署名するために使用されるキー。

サーバーTLSシークレット

オペレーターは、生成された自己署名CAを使用して、サーバーTLS証明書に署名します。これはkubernetes.io/tls タイプのシークレットに保存され、インスタンスによってssl_cert_file およびssl_key_file として使用されるように構成されます。このアプローチにより、クライアントは自分のIDを確認し、安全に接続できます。

サーバー代替DNS名

デフォルトのものに加えて、生成されたサーバーTLSシークレットの一部としてDNSサーバーの代替名を指定できます。

クライアント証明書

クライアントCAシークレット

デフォルトでは、サーバーCAと同じ自己署名CAが使用されます。パブリック部分はssl_ca_file としてすべてのインスタンスに渡されるため、署名したクライアント証明書を検証できます。プライベートキーは同じシークレットに保存され、 kubectl cnpg プラグインによって生成されたクライアント証明書の署名に使用されます。

クライアント`streaming_replica` 証明書

オペレーターは、生成された自己署名CAを使用して、ユーザーstreaming_replica のクライアント証明書に署名し、kubernetes.io/tls タイプのシークレットに保存します。プライマリインスタンスへの安全な接続を許可するために、この証明書はレプリカの接続文字列でsslcert およびsslkey として渡されます。

ユーザー提供の証明書モード

サーバー証明書

必要に応じて、 2つのサーバー証明書を提供し、 cert-manager などの別のコンポーネントを使用して生成することもできます。クラスターにカスタムサーバーTLS証明書を使用するには、次のパラメーターを指定する必要があります。

serverTLSSecret – サーバーTLS証明書を含むkubernetes.io/tls タイプのシークレットの名前。これには、標準のtls.crt およびtls.key キーの両方が含まれている必要があります。
serverCASecret – ca.crt キーを含むシークレットの名前。

注釈

オペレーターは、引き続きクライアント証明書に関連する2つのシークレットを作成および管理します。

注釈

オペレーターとインスタンスは、DNS名を無視して、CAのみに対してサーバー証明書を検証します。このアプローチは、クラスター内の通信に使用される`<cluster>-rw` サービスのユーザー指定証明書にDNS名が一般的に欠如しているためです。

注釈

ConfigMapとシークレットをインスタンスによってリロードする場合は、キー cnpg.io/reload のラベルを追加できます。それ以外の場合は、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

例

次のファイルがあるとします。

server-ca.crt – サーバーTLS証明書に署名したCAの証明書。
server.crt – サーバーTLS証明書の証明書。
server.key –サーバーTLS証明書のプライベートキー。

CA証明書を含むシークレットを作成します。

kubectl create secret generic my-postgresql-server-ca \
  --from-file=ca.crt=./server-ca.crt

TLS証明書を使用してシークレットを作成します。

kubectl create secret tls my-postgresql-server \
  --cert=./server.crt --key=./server.key

これらのシークレットを参照するPostgreSQLクラスターを作成します。

kubectl apply -f - <<EOF
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  certificates:
    serverCASecret: my-postgresql-server-ca
    serverTLSSecret: my-postgresql-server
  storage:
    storageClass: standard
    size: 1Gi
EOF

新しいクラスターは、TLS接続に提供されたサーバー証明書を使用します。

Cert-managerの例

この簡単な例は、 cert-manager の使用方法を示しています

自己署名CAをセットアップし、必要なTLSサーバー証明書を生成するには。

- --
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
- --
apiVersion: v1
kind: Secret
metadata:
  name: my-postgres-server-cert
  labels:
    cnpg.io/reload: ""
- --
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-postgres-server-cert
spec:
  secretName: my-postgres-server-cert
  usages:
    - server auth
  dnsNames:
    - cluster-example-lb.internal.mydomain.net
    - cluster-example-rw
    - cluster-example-rw.default
    - cluster-example-rw.default.svc
    - cluster-example-r
    - cluster-example-r.default
    - cluster-example-r.default.svc
    - cluster-example-ro
    - cluster-example-ro.default
    - cluster-example-ro.default.svc
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
    group: cert-manager.io

Cert-managerは、my-postgres-server-cert という名前のシークレットを作成します。これには、必要なすべてのファイルが含まれており、次のようにクラスターから参照できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  certificates:
    serverTLSSecret: my-postgres-server-cert
    serverCASecret: my-postgres-server-cert
  storage:
    size: 1Gi

cert-managerを使用して、サーバーとクライアントの両方のCAと証明書を管理する完全な例は、 cluster-example-cert-manager.yaml

展開マニフェスト。

クライアント証明書

必要に応じて、 cert-manager や HashiCorp vault などの別のコンポーネントを使用して生成し、2つのクライアント証明書を提供することもできます。カスタムCAを使用してクラスターのクライアント証明書を検証するには、次のパラメーターを指定する必要があります。

replicationTLSSecret – ユーザー streaming_replica のクライアント証明書を含むkubernetes.io/tls タイプのシークレットの名前 streaming_replica 。これには、標準のtls.crt およびtls.key キーの両方が含まれている必要があります。
clientCASecret – クライアント証明書の検証に使用するCAのca.crt キーを含むシークレットの名前。

注釈

オペレーターは、サーバー証明書に関連する2つのシークレットを作成および管理します。

注釈

クラスターはクライアントCA秘密キーを制御していないため、 kubectl cnpg certificate を使用してクライアント証明書を生成できません。

注釈

ConfigMapとシークレットをインスタンスによって自動的にリロードする場合は、キー cnpg.io/reload のラベルを追加できます。それ以外の場合、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

`streaming_replica` クライアント証明書のカスタマイズ

一部の環境では、会社のポリシーまたは複数のクラスターで共有されるCAなどのセキュリティ上の問題のため、共通名streaming_replica の証明書を生成できない場合があります。このような場合、ユーザーマッピング機能を使用して、異なる一般名を含む証明書を使用してstreaming_replica ユーザーとして認証を許可できます。

この設定を構成するには、 cnpg_streaming_replica という名前の事前定義マップのpg_ident.conf エントリーを追加します。

たとえば、共通名streaming-replica.cnpg.svc.cluster.local の証明書を使用してstreaming_replica 認証を有効にするには、次をクラスター定義に追加します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  postgresql:
    pg_ident:
    - cnpg_streaming_replica streaming-replica.cnpg.svc.cluster.local streaming_replica

オペレーターによるpg_ident.conf の管理方法の詳細については、ドキュメントの PostgreSQL Configuration を参照してください。

Cert-managerの例

この簡単な例は、 cert-manager の使用方法を示しています

自己署名CAをセットアップし、必要なTLSサーバー証明書を生成するには。

- --
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
- --
apiVersion: v1
kind: Secret
metadata:
  name: my-postgres-client-cert
  labels:
    cnpg.io/reload: ""
- --
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-postgres-client-cert
spec:
  secretName: my-postgres-client-cert
  usages:
    - client auth
  commonName: streaming_replica
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
    group: cert-manager.io

Cert-managerは、必要なすべてのファイルを含むmy-postgres-client-cert という名前のシークレットを作成します。次のようにクラスターから参照できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  certificates:
    clientCASecret: my-postgres-client-cert
    replicationTLSSecret: my-postgres-client-cert
  storage:
    size: 1Gi

cert-managerを使用してサーバーとクライアントの両方のCAと証明書を管理する完全な例は、 cluster-example-cert-manager.yaml

展開マニフェスト。

Certificates

オペレーター管理モード

サーバー証明書

サーバーCAシークレット

サーバーTLSシークレット

サーバー代替DNS名

クライアント証明書

クライアントCAシークレット

クライアントstreaming_replica 証明書

ユーザー提供の証明書モード

サーバー証明書

例

Cert-managerの例

クライアント証明書

streaming_replica クライアント証明書のカスタマイズ

Cert-managerの例

クライアント`streaming_replica` 証明書

`streaming_replica` クライアント証明書のカスタマイズ