証明書¶

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

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

注釈

クラスターで使用されるすべてのシークレットとその有効期限は、クラスターのステータスで確認できます。

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

**operator managed** :

証明書は完全に自動化された方法でオペレーターによって内部的に管理され、CloudNativePG によって作成された CA を使用して署名されます。

**user provided** :

証明書はオペレーターの外部で生成され、シークレットとしてクラスター定義にインポートされます - CloudNativePG はそれ自体を cert-manager と統合します (以下の例を参照)

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

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

デフォルトでは、オペレーターは単一の認証局を生成し、それをクライアントとサーバーの両方の証明書に使用します。その後、認証局は自動的に管理および更新されます。

サーバー証明書¶

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

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

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

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

オペレーターは、生成された自己署名 CA を使用してサーバー TLS 証明書に署名します。この証明書は、タイプ kubernetes.io/tls の Secret に格納され、インスタンスによって 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 つのサーバー証明書を提供し、証明書マネージャーの例などの別のコンポーネントを使用して生成することもできます。クラスターにカスタムサーバー TLS 証明書を使用するには、次のパラメーターを指定する必要があります。

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

注釈

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

注釈

インスタンスによって 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

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

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 接続に使用します。

証明書マネージャーの例¶

証明書マネージャーの例を使用して自己署名 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

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

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 配置マニフェストにあります。

クライアント証明書¶

必要に応じて、2 つのクライアント証明書を提供して、証明書マネージャーの例や: hashicorp vault

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

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

注釈

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

注釈

クラスターはクライアント CA 秘密鍵を管理していないため、kubectl cnpg certificate を使用してクライアント証明書を生成することはできなくなりました。

注釈

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

証明書マネージャーの例¶

証明書マネージャーの例を使用して自己署名 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

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

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 配置マニフェストにあります。

証明書¶

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

サーバー証明書¶

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

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

サーバーの代替 DNS 名¶

クライアント証明書¶

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

クライアント streaming_replica 証明書¶

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

サーバー証明書¶

例¶

証明書マネージャーの例¶

クライアント証明書¶

証明書マネージャーの例¶

前のトピックへ

次のトピックへ

目次