Security¶
このセクションには、CloudNativePGのセキュリティに関する情報が含まれており、コード、コンテナ、クラスターの3つの異なるレイヤーで分析されます。
警告
このページに含まれる情報は、Kubernetesクラスターでの通常のInfoSec業務の実行を免除するものであってはなりません。 Kubernetes文書の Overview of Cloud Native Security ページをよく理解してください。
コード¶
CloudNativePGのソースコードは、CI / CDパイプラインで直接 GolangCI-Lint と呼ばれるGoの一般的なオープンソースリンターを使用して、 セキュリティ問題 を含む静的分析目的で体系的にスキャンされます。GolangCI-Lintはいくつかのリンターを実行できます同じソースコードで。
これらの1つは Golang Security Checker 、または単に gosec
、ソースのアブストラクト構文ツリーをスキャンして、ハードコード資格情報、整数などのコードに隠されている既知の脆弱性、脅威、および脆弱性の発見を目的とした一連のルールに対してスキャンしますオーバーフローとSQLインジェクション-いくつか例を挙げ名前。
重要
CI / CDパイプラインの静的コード分析フェーズの失敗は、CloudNativePGの配信全体のブロッカーです。つまり、GolangCI-Lintによって定義されたすべてのリンターに対して各コミットが検証されます。
コンテナ¶
CloudNativePGのパートであるすべてのコンテナーイメージは、コミットごとにCI / CDパイプラインを介して自動的に構築されます。そのようなイメージには、オペレーターだけでなくオペランドも含まれます。具体的には、サポートされるすべてのPostgreSQLバージョンです。
Dockle ：用語のベストプラクティス コンテナ構築プロセスの
重要
ベースイメージおよびパッケージレベルのセキュリティ更新の場合、すべてのオペランドイメージはパイプラインによって1日に1回自動的に再構築され、 EDBが配布するコンテナーイメージの**パッチレベルの更新**を提供します。
コンテナレベルのセキュリティでは、次のガイドラインとフレームワークがアカウントされています。
Container Image Creation and Deployment Guide 、 米国国防総省（DoD）の防衛情報システム局（DISA）が開発
CIS Benchmark for Docker 、 インターネットセキュリティセンター（CIS）が開発
クラスター¶
クラスターレベルのセキュリティでは、コントロールプレーンとノードの両方を形成するすべてのKubernetesコンポーネント、およびクラスターで実行されるアプリケーション（ PostgreSQLを含む）がアカウントされます。
役割ベースのアクセス制御（RBAC）¶
演算子は、 cnpg-manager
という専用のサービスアカウントを使用してKubernetes
APIサーバーと対話します。 Kubernetesでは、これはデフォルトで
cnpg-system
名前空間にインストールされ、このサービスアカウントと、演算子に付与されたルール/リソース/動詞のセットを定義する
cnpg-manager
clusterロールとの間のクラスターロールバインドを使用します。
重要
上記のアクセス許可は、オペレーターのサービスアカウントがKubernetes APIサーバーと対話するためにのみ予約れています。 Cluster 、 Pooler 、 Backup 、および ScheduledBackup リソースとのみ対話する演算子のユーザーは、直接アクセスできません。
以下に、いくつかの例を示します。最も重要なのは、CloudNativePGが標準Kubernetesnamespacedリソースの完全または部分的な管理を必要とする理由です。
configmaps
：演算子は、Prometheusエクスポーターモニタリングメトリックのデフォルトの構成マップを作成および管理するニーズがあります。
deployments ：演算子は、標準のKubernetes Deployment
リソースを使用してPgBouncerコネクションプーラを管理するニーズがあります。
jobs ：演算子は、異なる Cluster
のフェーズを管理するジョブをハンドルニーズがあります。
persistentvolumeclaims ： PGDATA が存在するボリュームは、
PostgreSQL Cluster
リソースの中心的な要素です。演算子は、定義されたスケジューリングポリシーに基づいて、選択されたストレージクラスと対話して、要求されたボリュームを動的にプロビジョニングするニーズがあります。
pods ：演算子は Cluster
のインスタンスを管理するニーズがあります。
secrets ： Cluster
オブジェクトに証明書とパスワードを提供しない限り、演算子はランダムに生成されたパスワードとTLS証明書を自己プロビジョニングし、それらを秘密に保存することにより、「設定より規約」のパラダイムを採用します。
serviceaccounts ：演算子は、インスタンスマネージャ（
PostgreSQLサーバーを制御するコンテナーの* PID 1
*プロセス）がKubernetes
APIサーバーと安全に通信してアクションを調整し、信頼性の高いステータスを継続的に提供できるようにするサービスアカウントを作成するニーズがあります
Cluster の。
ニーズ ：演算子は、アプリケーションからPostgreSQLクラスター（またはコネクションプーラ）へのネットワークアクセスを制御し、自動化された方法でフェイルオーバー/スイッチオーバー操作を適切に管理する必要があります（例、サービスの正しいエンドポイントを適切なプライマリPostgreSQLインスタンス）。
ポッドセキュリティポリシー¶
Pod Security Policy は、ポッドがクラスターで実行するためにニーズのあるセキュリティルールと仕様を定義するKubernetesの方法です。InfoSecの理由により、すべてのKubernetesプラットフォームはそれらを実装する必要があります。
CloudNativePGでは、コンテナの実行に特権モードは必要ありませんPostgreSQLコンテナは
postgres システムユーザとして実行されます。 root
として実行する必要のコンポーネントは一切ありません。
同様に、ボリュームへのアクセスには* privileges *モードや root
特権も必要ありませんレイヤープラットフォームや管理者によって適切なアクセス許可が適切に割り当てられている必要があります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レベルでインバウンドおよびアウトバウンドのネットワークアクセスを有効/無効にすることができます。
重要
演算子は、 PostgreSQLサーバーのステータスに関する情報を取得するために、TCPポート8000で各インスタンスと通信するニーズがあります。ネットワークポリシーを追加する場合はこれを念頭に置いてくださいmakeで詳細な制御に使用されるポートのリストについては、以下の「公開ポート」セクションを参照してください。
ネットワークポリシーはこのドキュメントの範囲外です。詳細については、Kubernetes文書の ネットワークポリシー セクションを参照してください。
露出ポート¶
CloudNativePGは、以下の表にリストされているように、 演算子、 インスタンス マネージャ 、およびoperandlevelsでポートを公開します。
System |
Port number |
Exposing |
Name |
Certificates |
Authentication |
|---|---|---|---|---|---|
operator |
9443 |
webhook server |
webhook-server |
TLS |
Yes |
operator |
8080 |
metrics |
metrics |
no TLS |
No |
instance manager |
9187 |
metrics |
metrics |
no TLS |
No |
instance manager |
8000 |
status |
status |
no TLS |
No |
operand |
5432 |
PostgreSQL instance |
postgresql |
optional TLS |
Yes |
PostgreSQL¶
CloudNativePGの現在の実装では、 postgres
スーパーユーザとデータベース所有者のパスワードと .pgpass
ファイルが自動的に作成されます。
パスワードの暗号化に関する限り、CloudNativePGはPostgreSQLのデフォルトの動作に従います。PostgreSQL14以降、
PostgreSQLはデフォルトで scram-sha-256
に設定されますが、以前のバージョンでは md5 に設定されます。
重要
詳細については、 PostgreSQL文書の ユーザー名/パスワード認証 セクションを参照してください。
enableSuperuserAccess を false に設定すると、シークレット経由で
postgres ユーザパスワードの管理を無効にできます。
注釈
演算子は、 enableSuperuserAccess オプションの切り替えをサポートしています。実行中のクラスターでそれを無効にすると、演算子はシークレットのコンテンツを無視し、それを削除し（演算子によって以前に生成された場合）、 postgres ユーザのパスワードを NULL に設定します（事実上のパスワード認証リモートアクセスの無効化）。
詳細については、 PgBouncerSecrets を参照してください。
これらのファイルを使用して、データベースへのアプリケーションアクセスを構成できます。
デフォルトでは、すべてのレプリカは、 streaming_replica
という特別なユーザーを使用して、
physicalasyncストリーミングレプリケーション
で現在のプライマリインスタンスに接続するように自動的に構成されます。ノード間の接続は
暗号化 され、認証は TLSクライアント証明書
を介して行われます（詳細については、 Client TLS/SSL Connections ページを参照してください）。
現在、演算子は、管理者が postgresql 構成の pg_hba
セクションのmanifestasパートに pg_hba.conf
行を直接追加することを許可しています。それらのanifestで定義された行は、デフォルトの
pg_hba.conf に追加されます。
演算子による pg_hba.conf
の管理方法の詳細については、文書の PostgreSQL Configuration を参照してください。
重要
の例では、Kubernetesクラスターがプライベートで安全なネットワークで実行されることを想定しています。
