証明書¶

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を使用して、タイプ 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 のSecretに保存します。この証明書は、プライマリインスタンスに安全に接続できるように、レプリカの接続文字列でsslcert およびsslkey として渡されます。

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

サーバー証明書¶

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

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

注釈

オペレーターは、クライアント証明書に関連する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 キーを含むSecretの名前。

注釈

オペレーターは、サーバー証明書に関連する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証明書¶

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

サーバー証明書¶

例¶

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

クライアント証明書¶

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

前のトピックへ

次のトピックへ

目次