Certificates¶

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

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

注釈

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

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

**operator managed** ：証明書は完全に自動化された方法で演算子によって内部的に管理され、CloudNativePG2によって作成された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 として使用されるように構成します。

サーバーの代替DNS名¶

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

クライアント証明書¶

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

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

クライアントstreaming_replica証明書¶

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

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

サーバー証明書¶

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

注釈

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

注釈

ConfigMapsとSecretsをインスタンスによって**自動的にリロードする場合、キー cnpg.io/reload のlabelを追加できます。それ以外の場合は、 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接続に提供されたサーバ証明書を使用します。

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

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を使用して cluster-example-cert-manager.yaml 展開マニフェストでサーバーとクライアントの両方のCAと証明書を管理する完全な例を見つけることができます。

クライアント証明書¶

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

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

注釈

演算子は、サーバ証明書に関連する2つの秘密を引き続き作成および管理します。

注釈

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

注釈

ConfigMapsとSecretsをインスタンスによって**自動的にリロードする場合、 cnpg.io/reload キーを持つlabelを追加できます。そうでない場合は、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

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

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を使用して、 cluster-example-cert-manager.yaml 展開マニフェストでサーバーとクライアントの両方のCAと証明書を管理する完全な例を見つけることができます。

Certificates¶

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

サーバー証明書¶

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

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

サーバーの代替DNS名¶

クライアント証明書¶

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

クライアントstreaming_replica証明書¶

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

サーバー証明書¶

例¶

Cert-managerの例¶

クライアント証明書¶

Cert-managerの例¶

前のトピックへ

次のトピックへ

目次