Security

EDB Postgres Distributed for Kubernetesのセキュリティは、コード、コンテナ、クラスターの3つのレイヤーで分析されます。

警告

ここで説明するセキュリティ対策に加えて、Kubernetesクラスターで通常のInfoSec業務を実行する必要があります。 Overview of Cloud Native Security を理解する

Kubernetesドキュメント

参考

The 4C's Security Model in Kubernetes を参照

KubernetesのEDB Postgres Distributedのセキュリティに対してEDBが採用するアプローチのより良い理解とコンテキストに関するブログ記事。

コード

Kubernetes用EDB Postgres分散のソースコードは、セキュリティ問題を含む静的分析のために体系的にスキャンされています。 EDBは、 GolangCI-Lint と呼ばれるGoの人気のオープンソースリンターをCI / CDパイプラインで直接使用します。 GolangCI-Lintは、同じソースコードで複数のリンターを実行できます。

これらの1つが Golang Security Checker または gosec です。 gosec は、コードに隠された既知の脆弱性、脅威、および弱点を検出することを目的としたルールセットと比較して、ソースの抽象構文ツリーをスキャンするリンターです。これらのスレッドには、ハードコーディングされた資格情報、整数オーバーフロー、 SQLインジェクションなどが含まれます。

重要

CI / CDパイプラインの静的コード分析フェーズの障害は、Kubernetes用に配布されたEDB Postgresの配信全体のブロッカーです。つまり、各コミットはGolangCI-Lintで定義されたすべてのリンターに対して検証されます。

コンテナ

EDB Postgres Distributed for Kubernetesの一部であるすべてのコンテナイメージは、すべてのコミットに続いてCI / CDパイプラインを介してビルドされます。このようなイメージには、演算子だけでなくオペランド、特にサポートされているすべてのPostgreSQLバージョンのイメージが含まれます。パイプラインでは、画像は次の方法でスキャンされます。

• Dockle コンテナビルドプロセスに関するベストプラクティス

• Clair 基になるオペレーティングシステムと、それらが実行するライブラリとアプリケーションの両方で見つかった脆弱性

重要

すべてのオペランドイメージは、ベースイメージとパッケージレベルでセキュリティ更新が必要な場合、パイプラインによって1日1回再ビルドされ、EDBが配布するコンテナイメージのパッチレベルの更新を提供します。

コンテナレベルのセキュリティでは、次のガイドラインとフレームワークが考慮されました。

• Container Image Creation and Deployment Guide 、米国国防総省DoDの防衛情報システム庁DISAによって開発されました

• CIS Benchmark for Docker 、インターネットセキュリティセンターCISによって開発されました

参考

Security and Containers in EDB Postgres Distributed for Kubernetes を参照してください

EDB Postgres Distributed for Kubernetesのコンテナレベルでセキュリティに対してEDBが採用するアプローチの詳細については、ブログ記事を参照してください。

クラスター

クラスターレベルのセキュリティでは、コントロールプレーンとノードの両方を形成するすべてのKubernetesコンポーネント、およびPostgreSQLを含むクラスターで実行されるアプリケーションを考慮します。

ロールベースのアクセス制御RBAC

オペレーターは、 pgd-operator-controller-managerと呼ばれる専用のサービスアカウントを使用してKubernetes APIサーバーと対話します。 Kubernetesでは、このアカウントはデフォルトでpgd-operator-system 名前空間にインストールされます。クラスターロールは、このサービスアカウントと、オペレーターに付与されるルール、リソース、および動詞のセットを定義するpgd-operator-controller-managerクラスターロールの間をバインドします。

RedHat OpenShiftは、 OperatorLifecycleManager (OLM) を介してオペレーターRBACエンティティを直接管理します。 OLMでは、最小特権の原則を実装して、必要な場合にのみ権限を付与できます。

重要

これらの権限は、Kubernetes APIサーバーと対話するためにオペレーターのサービスアカウント専用に予約されています。 PGDGroup および`PGDGroupCleanup` リソースとのみ対話するオペレーターのユーザーは、これらに直接アクセスできません。

以下は、いくつかの例と、最も重要な理由です。KubernetesのEDB Postgres Distributedは、標準のKubernetes名前空間リソースの完全または部分的な管理を必要とする理由です。

jobs オペレーターは、ジョブを処理して、さまざまなPGDGroup フェーズを管理する必要があります。

poddisruptionbudgets オペレーターはポッド中断バジェットを使用して、メンテナンス操作中に十分なPGDノードがアクティブに保たれるようにします。

pods オペレーターは、PGDノードをCluster リソースとして管理する必要があります。

secrets 証明書とパスワードをデータノードに提供しない限り、オペレーターは、ランダムに生成されたパスワードとTLS証明書を自己プロビジョニングし、シークレットに保存することにより、「構成より規約」パラダイムを採用します。

serviceaccounts オペレーターはサービスアカウントを作成して、 PGDGroup リカバリジョブが存在するオブジェクトストアからバックアップオブジェクトを取得できるようにする必要があります。

services オペレーターは、アプリケーションからPGDクラスターへのネットワークアクセスを制御し、自動化された方法でフェイルオーバー/スイッチオーバー操作を適切に管理する必要があります。

statefulsets オペレーターはPGDプロキシを管理する必要があります。

validatingwebhookconfigurations およびmutatingwebhookconfigurations オペレーターは、管理するすべてのリソースを検証および変更するために必要な両方のWebhook構成に、自己署名Webhook CAを注入します。詳細については、 Kubernetes documentation を参照してください。

オペレーターに必要なすべての権限を表示するには、kubectl describe clusterrole pgd-operator-manager-role を実行できます。

EDB Postgres Distributed for Kubernetesは、 EDB Postgres for Kubernetesで定義されたCluster リソースを使用してPGDノードを内部管理します。 'Security' を参照してください

KubernetesオペレーターサービスアカウントのEDB Postgresが使用する権限のリストは。

インスタンスマネージャーによるAPIサーバーへの呼び出し

オペランドコンテナのエントリポイントであるインスタンスマネージャーは、Kubernetes APIサーバーへのいくつかの呼び出しを行って、一部のリソースのステータスが正しく更新されることを確認し、そのPostgresクラスターに関連付けられている構成マップとシークレットにアクセスする必要があります。 。このような呼び出しは、同じPostgreSQL Cluster リソース名を共有するオペレーターによって作成された専用のServiceAccount を介して実行されます。

重要

このオペランドは、APIサーバーを介してリソースの特定の限定されたサブセットにのみアクセスできます。サービスアカウントは、ポッド内からAPIサーバーにアクセスするための推奨される方法です。詳細は、 Kubernetes documentation を参照してください。

'Security' を参照してください

インスタンスマネージャーの詳細については、

ポッドセキュリティポリシー

pod security policy

これは、クラスターで実行するためにポッドが満たす必要があるセキュリティルールと仕様を定義するKubernetes方法です。 InfoSecの理由から、すべてのKubernetesプラットフォームはそれらを実装する必要があります。

EDB Postgres Distributed for Kubernetesは、コンテナの実行に特権モードを必要としません。 PostgreSQLコンテナは、postgresシステムユーザーとして実行されます。 rootとして実行する必要があるコンポーネントはありません。

同様に、ボリュームへのアクセスには特権モードまたはroot権限は必要ありません。 Kubernetesプラットフォームまたは管理者が適切な権限を割り当てる必要があります。 PostgreSQLコンテナは、読み取り専用のルートファイルシステム、つまり書き込み可能なレイヤーなしで実行されます。

オペレーターは、必要なセキュリティコンテキストを明示的に設定します。

Red Hat OpenShiftでは、クラウドネイティブPostgreSQLは、最も制限の厳しいrestricted セキュリティコンテキスト制約で実行されます。目標は、ポッドの実行を名前空間に割り当てられたUIDとSELinuxコンテキストに制限することです。

参考

OpenShiftのセキュリティコンテキスト制約SCCの詳細については、 Managing SCC in OpenShift を参照してください。

記事。

公開ポート

EDB Postgres Distributed for Kubernetesは、表に示すように、オペレーター、インスタンスマネージャー、およびオペランドレベルでポートを公開します。

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

PGD

KubernetesのEDB Postgres Distributedの現在の実装は、 postgresスーパーユーザーとデータベース所有者のパスワードを作成します。

パスワードの暗号化に関する限り、KubernetesのEDB Postgres DistributedはPostgreSQLのデフォルト動作に従います。PostgreSQL 14以降、password_encryption はデフォルトでscram-sha-256 に設定されます。以前のバージョンでは、md5 に設定されています。

重要

Connection DSNs and SSL を参照

詳細については、 PGDドキュメントを参照してください。

EDB Postgres Distributed for Kubernetesは、 postgres ロールを使用してPGDノードを維持します。このため、仕様のcnp セクションでenableSuperuserAccess からfalse を設定することにより、postgres ユーザーアクセスを無効にすることはできません。

ストレージ

EDB Postgres Distributed for Kubernetesは、保存時の暗号化を基になるストレージクラスに委任します。運用環境でのデータ保護のために、保存時の暗号化をサポートするストレージクラスを選択することを強くお勧めします。