Security#
このセクションには、CloudNativePG™クラスターのEDB Postgres® AIのセキュリティに関する情報が含まれており、コード、コンテナ、クラスターの3つの異なるレイヤーで分析されます。
警告
このページに含まれる情報は、Kubernetesクラスターで通常のInfoSec業務を実行することから免責されてはなりません。
Overview of Cloud Native Security についてよく理解してください
Kubernetesドキュメントのページ。
The 4C’s Security Model in Kubernetes を参照してください。
EDBがCloudNativePG™クラスターのEDB Postgres® AIのセキュリティに対して採用したアプローチのより良い理解とコンテキストを取得するブログ記事。
コード#
EDB Postgres® AI for CloudNativePG™ Clusterのソースコードは、 CI / CDパイプラインに直接統合されているGoの人気のオープンソースリンター GolangCI-Lint を使用して、セキュリティ脆弱性のチェックを含む体系的な静的分析を受けます。 GolangCI-Lintは、同じソースコードで複数のリンターを実行できます。
次のツールは、セキュリティ問題を特定するために使用されます。
** Golang Security Checker
gosec)** ハードコードされた資格情報、整数オーバーフロー、 SQLなどの既知の脆弱性、脅威、弱点を検出するように設計された一連のルールに対してソースコードの抽象構文ツリーをスキャンするリンター注射。 GolangCI-Lintは、スイートの一部としてgosecを実行します。** govulncheck :** このツールはCI / CDパイプラインで実行され、Goコードまたはコンパイラーに影響を与える既知の脆弱性を報告します。既知の脆弱性を含むGoコンパイラーのバージョンでオペレーターがビルドされている場合、
govulncheckはそれを検出します。** CodeQL :** GitHubが提供するこのツールは、セキュリティ問題をスキャンし、検出された脆弱性を含むプルリクエストをブロックします。 CodeQLは、PythonやBashなどのリポジトリ内の他の言語を除き、Goコードのみをレビューするように構成されています。
** Snyk :** スケジュールされたジョブで毎晩コードスキャンを実行し、コードのセキュリティとライセンスの問題に関連する新しい結果を強調する週次レポートを生成します。
CloudNativePG™クラスターリポジトリのEDB Postgres® AIは、 Security section で “Private vulnerability Reporting” オプションが有効になっています。この機能を使用すると、ユーザーは一般に公開される前に、注意深い取り扱いが必要なセキュリティ問題を安全に報告できます。セキュリティバグを発見した場合は、この媒体を使用して報告してください。
重要
CI / CDパイプラインの静的コード分析フェーズの障害は、CloudNativePG™クラスターのEDB Postgres® AIの配信プロセス全体をブロックします。すべてのコミットは、GolangCI-Lintで定義されたすべてのリンターを渡す必要があります。
コンテナ#
CloudNativePG™クラスターのEDB Postgres® AIのオペレーターイメージは、リリースプロセスの一部としてビルドおよび published されます。使用可能な最新のオペレーターバージョンについては、 Introduction and Release notes を参照してください。
オペランドイメージは、サポートされているPostgreSQLバージョンごとに EDB Postgres Extended および EDB Postgres Advanced を含む で毎月ビルドおよび公開されます。
画像は次のツールを使用してスキャンされます。
** Dockle :** コンテナビルドプロセスのベストプラクティスを保証します。
** Black Duck :** オープンソースコンポーネントの脆弱性をチェックし、ライセンスの一貫性を検証します。
重要
すべてのオペランドイメージは、パイプラインによって毎月自動的に再構築され、ベースイメージとパッケージレベルの両方で最新のセキュリティ更新が組み込まれ、EDBダウンロードサイトに配布されるコンテナイメージの**パッチレベルの更新**を提供します。
警告
古いイメージを実行すると、環境がセキュリティリスクとパフォーマンスの問題にさらされる可能性があります。最新のイメージバージョンに更新し、イメージを最新の状態に保つことを強くお勧めします。これにより、利用可能な最新の更新とパッチを確実に利用できます。
コンテナセキュリティのガイドラインとフレームワーク#
コンテナレベルのセキュリティを確保するために、次のガイドラインとフレームワークが検討されています。
** Container Image Creation and Deployment Guide :** 米国国防総省DoDの防衛情報システム局DISAによって開発されました。
- CIS Benchmark for Docker :**
インターネットセキュリティセンターCISによって開発されました。
参考
CloudNativePG™クラスターのEDB Postgres® AIのコンテナレベルのセキュリティに関してEDBが採用したアプローチの詳細については、ブログ記事
Security and Containers in EDB Postgres® AI for CloudNativePG™ Cluster を参照してください。
クラスター#
クラスターレベルのセキュリティでは、コントロールプレーンとノードの両方を形成するすべてのKubernetesコンポーネント、およびクラスターで実行されるアプリケーションPostgreSQLを含むが考慮されます。
ロールベースのアクセス制御RBAC#
オペレーターは、postgresql-operator-manager
という名前の専用サービスアカウントを使用してKubernetes
APIサーバーと対話します。このサービスアカウントは、通常、オペレーター名前空間、一般的にpostgresql-operator-system
にインストールされます。ただし、名前空間は、展開方法によって異なる場合があります以下のサブセクションを参照してください。
同じ名前空間に、postgresql-operator-manager
サービスアカウントとロールの間にバインディングがあります。このロールの具体的な名前とタイプ
Role またはClusterRole
も、展開方法によって異なります。このロールは、オペレーターが正常に機能するために必要な権限を定義します。これらのロールの詳細については、展開方法に応じて、
kubectl describe clusterrole またはkubectl describe role
コマンドを使用できます。この問題に関するOpenShiftの詳細については、
Red Hat OpenShift 、特に Pre-defined RBAC objects を参照してください。
重要
上記の権限は、Kubernetes APIサーバーと対話するためにオペレーターのサービスアカウント専用に予約されています。 これらは、 Cluster 、Pooler 、Backup 、ScheduledBackup 、ImageCatalog 、および`ClusterImageCatalog` リソースとのみ対話するオペレーターのユーザーは直接アクセスできません。
以下に、いくつかの例と、最も重要な理由を提供します。
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 CAを両方のWebhook構成に注入します。これらは、管理するすべてのリソースを検証および変更するために必要です。詳細については、
Kubernetes documentation を参照してください。
volumesnapshots
オペレーターは、PostgreSQLサーバーのバックアップを取得するために、VolumeSnapshots
オブジェクトを生成する必要があります。
VolumeSnapshotは、復元プロセスを開始する前に検証するために読み取られます。
nodes
オペレーターは、アフィニティとアンチアフィニティのラベルを取得して、ポッドをスケジュールできるノードを決定できるようにする必要があります。これは、たとえば、レプリカが同じノードでスケジュールされるのを防ぐ場合に役立ちます。ノードが異なるアベイラビリティーゾーンにある場合に特に重要です。この権限は、ノードがスケジュールされているかどうかを判断し、スケジュールされていないノードでのポッドの作成を防止、またはプライマリがスケジュールされていないノードに存在する場合にスイッチオーバーをトリガーするためにも使用されます。
デプロイメントとClusterRole リソース#
前述のように、各展開方法には、サービスアカウントの名前空間の場所、ロールバインディング、および各ロールの名前とタイプが異なる場合があります。
Kubernetesマニフェスト経由#
Kubernetesマニフェストを使用してCloudNativePG™クラスターのEDB Postgres®
AIをインストールすると、権限はデフォルトでClusterRoleBinding
に設定されます。次を実行して、オペレーターに必要な権限を検査できます。
kubectl describe clusterrole postgresql-operator-manager
OLM経由#
セキュリティの観点から、Operator Lifecycle ManagerOLMは、より柔軟な展開方法を提供します。すべての名前空間または特定の名前空間を監視するようにオペレーターを構成できるため、より詳細な権限管理が可能になります。
注釈
OLMでは、オペレーターを独自の名前空間に展開し、CloudNativePG™ クラスタークラスターのEDB Postgres® AIに使用される特定の名前空間を監視するように構成できます。この設定は、権限を含め、より効果的にアクセスを制限するのに役立ちます。
クラスターロールのアクセス許可が必要なのはなぜですか?#
現在、オペレーターがnodes およびClusterImageCatalog
オブジェクトを読み取るには、ClusterRole
権限が必要です。他のすべての権限は、名前空間スコープつまりRole
またはクラスター全体つまりClusterRole にすることができます。
これらの権限でも、誰かがServiceAccount
へのアクセスを取得した場合、リソースの表示に制限されているget
、list 、およびwatch
権限のみがあります。ただし、無許可のユーザーがServiceAccount
へのアクセスを取得した場合、それはより重大なセキュリティ問題を示しています。
したがって、ユーザーがオペレーターのServiceAccount
および昇格した権限で他のServiceAccount
にアクセスしないようにすることが重要です。
インスタンスマネージャーによるAPIサーバーへの呼び出し#
オペランドコンテナのエントリポイントであるインスタンスマネージャーは、Kubernetes
APIサーバーへのいくつかの呼び出しを行って、一部のリソースのステータスが正しく更新されることを確認し、そのPostgresクラスターに関連付けられている構成マップとシークレットにアクセスする必要があります。
。このような呼び出しは、同じPostgreSQL Cluster
リソース名を共有するオペレーターによって作成された専用のServiceAccount
を介して実行されます。
重要
このオペランドは、APIサーバーを介してリソースの特定の限定されたサブセットにのみアクセスできます。サービスアカウントは recommended way to access the API server from within a Pod です。
透明性を維持するために、サービスアカウントに関連付けられている権限は roles.go
ファイル。たとえば、 myns 名前空間の汎用mypg
クラスターの権限を取得するには、次のコマンドを入力します。
kubectl get role -n myns mypg -o yaml
次に、ロールがサービスアカウントにバインドされていることを確認します。
kubectl get rolebinding -n myns mypg -o yaml
重要
**ロールは特定の名前空間**に制限されていることに注意してください。
以下に、汎用のKubernetesリソースのサービスアカウントに関連付けられた権限の簡単な概要を提供します。
configmaps
インスタンスマネージャーは、カスタムモニタリングクエリなど、同じクラスターに関連する構成マップのみを読み取ることができます
secrets
インスタンスマネージャーは、同じクラスターに関連するシークレットのみを読み取ることができます。ストリーミングレプリケーションユーザー、アプリケーションユーザー、スーパーユーザー、LDAP認証ユーザー、クライアントCA、サーバーCA、サーバー証明書、バックアップ資格情報、カスタムモニタリングクエリー
events
インスタンスマネージャーは、クラスターのイベントを作成し、PostgreSQLインスタンスのライフサイクルの特定の側面についてAPIサーバーに通知できます
ここでは、代わりに、CloudNativePG™クラスターのEDB Postgres® AIに固有のリソースに関する同じ概要を提供します。
clusters
インスタンスマネージャーは、独自のCluster
リソースに対してのみ、読み取り専用権限、つまりget 、list
、およびwatch が必要です
clusters/status
インスタンスマネージャーは、自分自身のCluster
リソースのみのステータスをupdate およびpatch
する必要があります
backups
インスタンスマネージャーが名前空間内のBackup
リソースを読み取るには、 get およびlist
権限が必要です。さらに、オブジェクトストアに対応するものがないBackup
オブジェクトを削除することにより、Kubernetesクラスターをクリーンアップするには、
delete 権限が必要です。通常はリテンションポリシーのため
backups/status
インスタンスマネージャーは、名前空間内のBackup
リソースのステータスをupdate およびpatch
する必要があります。
ポッドセキュリティポリシー#
重要
Kubernetes v1.21から、PodSecurityPolicy の使用は非推奨になり、Kubernetes v1.25の時点で、完全に削除されました。この非推奨にもかかわらず、オペレーターが現在Kubernetesの古いサポートされていないバージョンでテストを受けていることを確認しています。したがって、このセクションはこれらの特定のシナリオのために保持されています。
これは、クラスターで実行するためにポッドが満たす必要があるセキュリティルールと仕様を定義するKubernetes方法です。 InfoSecの理由から、すべてのKubernetesプラットフォームはそれらを実装する必要があります。
CloudNativePG™クラスターのEDB Postgres® AIは、コンテナの実行に 特権
モードを必要としません。 PostgreSQLコンテナは、 postgres
システムユーザーとして実行されます。 root
として実行する必要があるコンポーネントはありません。
同様に、ボリュームへのアクセスには、 特権 モードまたはroot
特権も必要ありません。
Kubernetesプラットフォームおよび/または管理者は、適切な権限を適切に割り当てる必要があります。
PostgreSQLコンテナは、読み取り専用のルートファイルシステムつまり書き込み可能なレイヤーなしで実行されます。
オペレーターは、必要なセキュリティコンテキストを明示的に設定します。
Red Hat
OpenShiftでは、クラウドネイティブのPostgreSQLは、最も制限の厳しいrestricted
セキュリティコンテキスト制約で実行されます。目標は、ポッドの実行を名前空間に割り当てられたUIDとSELinuxコンテキストに制限することです。
参考
OpenShiftのセキュリティコンテキスト制約SCCの詳細については、
Managing SCC in OpenShift を参照してください。
記事。
SCCはデフォルトの名前空間default 、kube-system
、kube-public 、openshift-node 、openshift-infra
、openshift
には適用されません。これらはポッドの実行に使用しないでください。これらの名前空間に展開されたCNPクラスターは、SCCが欠落しているため起動できません。
AppArmorを使用してポッドアクセスを制限する#
container.apparmor.security.beta.kubernetes.io
アノテーションを介して、すべてのCluster ポッド内のpostgres
、initdb 、join 、full-recovery
、およびbootstrap-controller
コンテナに AppArmor プロファイルを割り当てることができます。
参考
edb_notranlate_3
AppArmor構成はKubernetesノードレベルである必要があります。つまり、基になるオペレーティングシステムでこのオプションを有効にし、適切に構成する必要があります。
これは状況ではなく、アノテーションがCluster
作成時に追加された場合、ポッドは作成されません。一方、Cluster
が作成された後にアノテーションを追加すると、クラスター内のポッドは起動できず、次のようなエラーが発生します。
metadata.annotations[container.apparmor.security.beta.kubernetes.io/postgres]: Forbidden: may not add AppArmor annotations]
このような場合、Kubernetes管理者に連絡し、使用する適切なAppArmorプロファイルを聞いてください。
ネットワークポリシー#
Cluster
リソースによって作成されたポッドは、Kubernetesによって制御できます
network policies
IPおよびTCPレベルでインバウンドおよびアウトバウンドのネットワークアクセスを有効/無効にします。詳細については、 networking document を参照してください。
重要
オペレーターは、TCPポート8000で各インスタンスと通信して、PostgreSQLサーバーのステータスに関する情報を取得する必要があります。ネットワークポリシーを追加する場合にこれを念頭に置いて、より詳細な制御のためにCloudNativePG™クラスターのEDB Postgres® AIが使用するポートのリストについては、以下の「公開ポート」セクションを参照してください。
ネットワークポリシーは、このドキュメントの範囲外です。 Network policies を参照してください。
詳細については、Kubernetesドキュメントのセクションを参照してください。
公開ポート#
CloudNativePG™クラスターのEDB Postgres® AIは、以下の表にリストされているように、オペレーター、インスタンスマネージャー、およびオペランドレベルでポートを公開します。
System |
Port number |
Exposing |
Name |
TLS |
Authentication |
|---|---|---|---|---|---|
operator |
9443 |
webhook server |
webhook-server |
Yes |
Yes |
operator |
8080 |
metrics |
metrics |
No |
No |
instance manager |
9187 |
metrics |
metrics |
Optional |
No |
instance manager |
8000 |
status |
status |
Yes |
No |
operand |
5432 |
PostgreSQL instance |
postgresql |
Optional |
Yes |
PostgreSQL#
CloudNativePG™クラスターのEDB Postgres®
AIの現在の実装は、データベース所有者と、 enableSuperuserAccess
をtrue に設定して要求された場合にのみ、 postgres
スーパーユーザーのパスワードと.pgpass
ファイルを自動的に作成します。
警告
enableSuperuserAccess は、オペレーターのセキュリティバイデフォルト姿勢を向上させるためにデフォルトで`false` に設定され、PostgreSQLへの変更が`Cluster` リソースの`spec` を介して宣言的な方法で実行されるマイクロサービスアプローチを促進しながら、開発者に内部のフルパワーを提供しますデータベース所有者ユーザーを介してデータベースにアクセスします。
パスワードの暗号化に関する限り、CloudNativePG™クラスターのEDB Postgres®
AIは、 PostgreSQLのデフォルト動作に従います。PostgreSQL
14以降、password_encryption はデフォルトでscram-sha-256
に設定されますが、以前のバージョンではmd5 に設定されています。
重要
Password authentication を参照してください。
詳細については、PostgreSQLドキュメントのセクションを参照してください。
注釈
オペレーターは、enableSuperuserAccess オプションのトグルをサポートしています。実行中のクラスターで無効にすると、オペレーターはシークレットの内容を無視し、削除し、オペレーターが以前に生成した場合、postgres ユーザーのパスワードを`NULL` に設定しますパスワード認証を介したリモートアクセスを事実上無効にします。
詳細は、 External Secrets を参照してください。
これらのファイルを使用して、データベースへのアプリケーションのアクセスを構成できます。
デフォルトでは、すべてのレプリカは、streaming_replica
と呼ばれる特別なユーザーを使用して、現在のプライマリインスタンスに
物理非同期ストリーミングレプリケーション
で接続するように自動的に構成されます。ノード間の接続は 暗号化
され、認証は TLSクライアント証明書 を介して行われます。[“Client
TLS/SSL Connections”](ssl_connections.md#“Client TLS/SSL
Connections”)ページを参照してください。詳細についてはこちらをご覧ください。デフォルトでは、オペレーターはTLS
v1.3接続を必要とします。
現在、オペレーターは、管理者がpostgresql 構成のpg_hba
セクションの一部としてマニフェストにpg_hba.conf
行を直接追加できます。マニフェストで定義された行は、デフォルトのpg_hba.conf
に追加されます。
オペレーターによるpg_hba.conf
の管理方法の詳細については、ドキュメントの PostgreSQL Configuration を参照してください。
管理者は、デフォルトでローカルのpostgresユーザーをデータベース内のpostgresユーザーにのみマップするpg_ident.conf
ファイルの内容をカスタマイズすることもできます。
オペレーターによるpg_ident.conf
の管理方法の詳細については、ドキュメントの PostgreSQL Configuration を参照してください。
重要
例では、Kubernetesクラスターがプライベートで安全なネットワークで実行されていることを前提としています。
ストレージ#
CloudNativePG™クラスターのEDB Postgres® AIは、保存時の暗号化を基になるストレージクラスに委任します。運用環境でのデータ保護のために、保存時の暗号化をサポートするストレージクラスを選択することを強くお勧めします。