セキュリティ¶
このセクションには、コード、コンテナ、クラスターの3つの異なるレイヤーで分析されるCloudNativePGのセキュリティに関する情報が含まれています。
警告
このページに含まれる情報は、Kubernetesクラスターで通常のInfoSecの職務を実行することを免責してはなりません。 Kubernetesドキュメントの Overview of Cloud Native Security ページを理解してください。
コード¶
CloudNativePGのソースコードは、 セキュリティの問題 を含む静的分析の目的で体系的にスキャンされます。 GolangCI-Lintは、同じソースコードで複数のリンターを実行できます。
これらの1つは Golang Security Checker 、または単に gosec です。
、整数オーバーフロー、 SQLインジェクション - いくつか例を挙げます。
重要
CI / CDパイプラインの静的コード分析フェーズでの障害は、CloudNativePGの配信全体のブロッカーです。
コンテナ¶
CloudNativePGの一部であるすべてのコンテナイメージは、すべてのコミットに続いてCI / CDパイプラインを介して自動的にビルドされます。このようなイメージには、演算子だけでなくオペランド、特にサポートされているすべてのPostgreSQLバージョンも含まれます。パイプライン内で、画像は次のようにスキャンされます。
Dockle ：コンテナビルドプロセスに関するベストプラクティス
重要
すべてのオペランドイメージは、ベースイメージおよびパッケージレベルでセキュリティ更新が行われた場合にパイプラインによって1日に1回自動的にリビルドされ、EDBが配布するコンテナイメージに**パッチレベルの更新**を提供します。
コンテナレベルのセキュリティのために、次のガイドラインとフレームワークが考慮されています。
- 米国国防総省（DoD）の国防情報システム局（DISA）によって開発された
Center for Internet Security（CIS）が開発した CIS Benchmark for Docker
クラスター¶
クラスターレベルのセキュリティでは、コントロールプレーンとノードの両方を形成するすべてのKubernetesコンポーネント、およびクラスターで実行されるアプリケーション（PostgreSQLを含む）が考慮されます。
ロールベースのアクセス制御（RBAC）¶
オペレーターは、cnpg-manager
と呼ばれる専用のサービスアカウントを使用してKubernetes
APIサーバーと対話します。
Kubernetesでは、これはデフォルトでcnpg-system
名前空間にインストールされ、このサービスアカウントとオペレーターに付与されるルール/リソース/動詞のセットを定義するcnpg-manager
クラスターロールとの間のクラスターロールがバインドされます。
重要
上記の権限は、オペレーターのサービスアカウントがKubernetes APIサーバーと対話するためにのみ予約されています。 Cluster 、Pooler 、Backup 、および`ScheduledBackup` リソースとのみ対話するオペレーターのユーザーは、直接アクセスできません。
以下にいくつかの例を示しますが、最も重要なことに、CloudNativePGが標準のKubernetes名前空間リソースの完全または部分的な管理を必要とする理由を示します。
configmaps
：オペレーターは、Prometheusエクスポーターモニタリングメトリックのデフォルト構成マップを作成および管理する必要があります。
deployments ：オペレーターは、標準のKubernetes Deployment
リソースを使用してPgBouncer接続プーラーを管理する必要があります。
jobs ：オペレーターは、さまざまなCluster
のフェーズを管理するためにジョブを処理する必要があります。
persistentvolumeclaims ： PGDATA
が存在するボリュームは、PostgreSQL Cluster
リソースの中心的な要素です。オペレーターは、定義されたスケジューリングポリシーに基づいて、選択されたストレージクラスと対話して、要求されたボリュームを動的にプロビジョニングする必要があります。
pods ：オペレーターはCluster
のインスタンスを管理する必要があります。
secrets ： Cluster
オブジェクトに証明書とパスワードを提供しない限り、オペレーターは、ランダムに生成されたパスワードとTLS証明書をセルフプロビジョニングし、それらを秘密に保存することにより、「構成よりも規約」パラダイムを採用します。
serviceaccounts
：オペレーターは、インスタンスマネージャー（PostgreSQLサーバーを制御するコンテナのPID
1プロセス）がKubernetes
APIサーバーと安全に通信して、アクションを調整し、信頼できるステータスを継続的に提供できるようにするサービスアカウントを作成する必要がありますCluster
の。
services
：オペレーターは、アプリケーションからPostgreSQLクラスター（または接続プーラー）へのネットワークアクセスを制御し、自動化された方法でフェールオーバー/スイッチオーバー操作を適切に管理する必要があります（たとえば、サービスの正しいエンドポイントを適切なプライマリPostgreSQLインスタンス）。
validatingwebhookconfigurations
およびmutatingwebhookconfigurations
：オペレーターは、管理するすべてのリソースを検証および変更するために必要な両方のWebhook構成に自己署名Webhook
CAを挿入します。詳細については、 Kubernetes documentation をご覧ください。
nodes
：オペレーターは、アフィニティとアンチアフィニティのラベルを取得する必要があるため、特にノードが異なるアベイラビリティーゾーンにある場合、ポッドをスケジュールしてレプリカが同じノードにならないように決定できます。この権限は、ノードがスケジュールされているかどうかを判断するためにも使用され、まったく作成できないポッドの作成を回避します。
オペレーターが必要とするすべての権限を表示するには、
kubectl describe clusterrole cnpg-manager を実行します。
ポッドセキュリティポリシー¶
Pod Security Policy は、ポッドがクラスターで実行するために満たす必要があるセキュリティルールと仕様を定義するためのKubernetesの方法です。
InfoSecの理由から、すべてのKubernetesプラットフォームで実装する必要があります。
CloudNativePGでは、コンテナの実行に特権モードは必要ありません。
PostgreSQLコンテナはpostgres システムユーザーとして実行されます。
root として実行する必要があるコンポーネントはありません。
同様に、ボリュームアクセスには特権モードまたはroot
特権も必要ありません。適切な権限は、Kubernetesプラットフォームおよび/または管理者が適切に割り当てる必要があります。
PostgreSQLコンテナは、読み取り専用のルートファイルシステム（つまり、書き込み可能なレイヤーなし）で実行されます。
オペレーターは、必要なセキュリティコンテキストを明示的に設定します。
AppArmorを使用したPodアクセスの制限¶
container.apparmor.security.beta.kubernetes.io
アノテーションを介して、すべてのCluster ポッド内のpostgres
、initdb 、join 、full-recovery
およびbootstrap-controller
コンテナーに AppArmorを使用したPodアクセスの制限 プロファイルを割り当てることができます。
警告
この種のアノテーションを使用すると、クラスターが動作しなくなる場合があります。この場合、注釈を`Cluster` から安全に削除できます。
AppArmor構成はKubernetesノードレベルである必要があります。つまり、基になるオペレーティングシステムでこのオプションを有効にし、適切に構成する必要があります。
これが状況ではなく、注釈が Cluster
作成時に追加された場合、ポッドは作成されません。一方、 Cluster
が作成された後にアノテーションを追加すると、クラスター内のポッドを起動できず、次のようなエラーが発生します。
metadata.annotations[container.apparmor.security.beta.kubernetes.io/postgres]: Forbidden: may not add AppArmor annotations]
このような場合は、Kubernetes管理者に連絡して、使用する適切なAppArmorプロファイルを依頼してください。
ネットワークポリシー¶
Clusterリソースによって作成されたポッドをKubernetesネットワークポリシー で制御して、IPおよびTCPレベルでインバウンドおよびアウトバウンドのネットワークアクセスを有効/無効にすることができます。
重要
オペレーターは、TCPポート8000で各インスタンスと通信して、PostgreSQLサーバーのステータスに関する情報を取得する必要があります。ネットワークポリシーを追加する場合はこのことに注意してください。CloudNativePGがより詳細に制御するために使用するポートのリストについては、以下の「公開ポート」セクションを参照してください。
ネットワーク ポリシーはこのドキュメントの範囲を超えています。詳細については、Kubernetesドキュメントの ネットワークポリシー セクションを参照してください。
公開されたポート¶
CloudNativePGは、以下の表に示すように、オペレーター、インスタンスマネージャー、およびオペランドレベルでポートを公開します。
システム |ポート番号 |露出 |名前 |証明書 |認証 :————— | :———– |
:—————— | :—————— | :———— | :————– 演算子 | 9443
|ウェブフックサーバー | webhook-server | TLS |はい演算子 | 8080
|メトリックス | metrics | TLSなし |インスタンスマネージャーなし
| 9187 |メトリックス | metrics | TLSなし
|インスタンスマネージャーなし | 8000 |ステータス | status |
TLSなし |オペランドなし | 5432 | PostgreSQLインスタンス |
postgresql |オプションのTLS |はい
PostgreSQL¶
CloudNativePGの現在の実装では、 postgres
スーパーユーザーとデータベース所有者のパスワードと.pgpass
ファイルが自動的に作成されます。
パスワードの暗号化に関する限り、CloudNativePGはPostgreSQLのデフォルトの動作に従います。PostgreSQL
14以降、 password_encryption はデフォルトでscram-sha-256
に設定されていますが、以前のバージョンではmd5 に設定されています。
重要
詳細については、PostgreSQLドキュメントの ユーザー名/パスワード認証 セクションを参照してください。
enableSuperuserAccess をfalse
に設定することにより、シークレットを介したpostgres
ユーザーパスワードの管理を無効にできます。
注釈
オペレーターは、 enableSuperuserAccess オプションのトグルをサポートしています。実行中のクラスターで無効にすると、オペレーターはシークレットの内容を無視し、それを削除し（オペレーターが以前に生成した場合）、 postgres ユーザーのパスワードを`NULL` に設定します（パスワード認証を介したリモートアクセスを事実上無効にします）。
詳細については、 PgBouncerの秘密 を参照してください。
これらのファイルを使用して、データベースへのアプリケーションアクセスを構成できます。
デフォルトでは、すべてのレプリカは、streaming_replica
と呼ばれる特別なユーザーを使用して、現在のプライマリインスタンスに
物理非同期ストリーミングレプリケーション
で接続するように構成されます。ノード間の接続は 暗号化 され、認証は
TLSクライアント証明書 を介して行われます（詳細については、
クライアントTLS / SSL接続 ページを参照してください）。
現在、オペレーターは、管理者が postgresql 構成の pg_hba
セクションの一部としてマニフェストに直接 pg_hba.conf
行を追加することを許可します。マニフェストで定義された行がデフォルトのpg_hba.conf
に追加されます。
pg_hba.conf
がオペレーターによって管理される方法の詳細については、ドキュメントの PostgreSQL設定 を参照してください。
重要
例では、Kubernetesクラスターがプライベートで安全なネットワークで実行されていることを前提としています。
