2.10. コンテナープラットフォームのセキュリティー保護
OpenShift Container Platform および Kubernetes API は、スケーリング時にコンテナー管理を自動化する鍵となります。API は以下の目的で使用されます。
- Pod、サービス、およびレプリケーションコントローラーのデータの検証および設定。
- 受信要求におけるプロジェクト検証の実施と、他の主要なシステムコンポーネントでのトリガーの呼び出し。
Kubernetes をベースとする OpenShift Container Platform のセキュリティー関連機能には、以下が含まれます。
- マルチテナンシー: ロールベースのアクセス制御とネットワークポリシーを統合し、複数のレベルでコンテナーを分離します。
- API と API の要求側との間の境界を形成する受付プラグイン。
OpenShift Container Platform は Operator を使用して Kubernetes レベルのセキュリティー機能の管理を自動化し、単純化します。
2.10.1. マルチテナンシーによるコンテナーの分離
マルチテナンシーは、複数のユーザーによって所有され、複数のホストおよび namespace で実行される OpenShift Container Platform クラスターの複数アプリケーションが、相互に分離された状態のままにし、外部の攻撃から隔離された状態にすることができます。ロールベースアクセス制御 (RBAC) を Kubernetes namespace に適用して、マルチテナンシーを取得します。
Kubernetes では、namespace はアプリケーションを他のアプリケーションと分離した状態で実行できるエリアです。OpenShift Container Platform は、SELinux の MCS ラベルを含む追加のアノテーションを追加して namespace を使用し、これを拡張し、これらの拡張された namespace を プロジェクト として特定します。プロジェクトの範囲内で、ユーザーは、サービスアカウント、ポリシー、制約、およびその他のオブジェクトなど、独自のクラスターリソースを維持できます。
RBAC オブジェクトはプロジェクトに割り当てられ、選択されたユーザーのそれらのプロジェクトへのアクセスを認可します。この認可には、ルール、ロール、およびバインディングの形式が使用されます。
- ルールは、ユーザーがプロジェクト内で作成またはアクセスできるものを定義します。
- ロールは、選択されたユーザーまたはグループにバインドできるルールのコレクションです。
- バインディングは、ユーザーまたはグループとロール間の関連付けを定義します。
ローカル RBAC ロールおよびバインディングは、ユーザーまたはグループを特定のプロジェクトに割り当てます。クラスター RBAC では、クラスター全体のロールおよびバインディングをクラスターのすべてのプロジェクトに割り当てることができます。admin、basic-user、 cluster-admin、および cluster-status アクセスを提供するために割り当てることのできるデフォルトのクラスターロールがあります。
2.10.2. 受付プラグインでのコントロールプレーンの保護
RBAC はユーザーおよびグループと利用可能なプロジェクト間のアクセスルールを制御しますが、受付プラグイン は OpenShift Container Platform マスター API へのアクセスを定義します。受付プラグインは、以下で設定されるルールのチェーンを形成します。
- デフォルトの受付プラグイン: これは、OpenShift Container Platform コントロールプレーンのコンポーネントに適用されるポリシーおよびリソース制限のデフォルトセットを実装します。
- 変更用の受付プラグイン: これらのプラグインは受付チェーンを動的に拡張します。これらは Webhook サーバーに対する呼び出しを実行し、要求の認証および選択されたリソースの変更の両方を実行します。
- 検証用の受付プラグイン: 選択されたリソースの要求を検証し、要求を検証すると共にリソースが再度変更されないようにすることができます。
API 要求はチェーン内の受付プラグインを通過し、途中で失敗した場合には要求が拒否されます。それぞれの受付プラグインは特定のリソースに関連付けられ、それらのリソースの要求にのみ応答します。
2.10.2.1. SCC (Security Context Constraints)
Security Context Constraints (SCC) を使用して、Pod のシステムでの受け入れを可能にするために Pod の実行時に必要となる一連の条件を定義することができます。
以下は、SCC で管理できる分野の一部です。
- 特権付きコンテナーの実行
- コンテナーが要求できる機能の追加
- ホストディレクトリーのボリュームとしての使用
- コンテナーの SELinux コンテキスト
- コンテナーのユーザー ID
必要なパーミッションがある場合は、必要に応じてデフォルトの SCC ポリシーの許容度を上げるように調整することができます。
2.10.2.2. ロールのサービスアカウントへの付与
ロールは、ユーザーにロールベースのアクセスを割り当てるのと同じ方法で、サービスアカウントに割り当てることができます。各プロジェクトに 3 つのデフォルトサービスアカウントが作成されます。サービスアカウント:
- スコープが特定プロジェクトに制限される
- その名前はそのプロジェクトから派生している。
- OpenShift Container レジストリーにアクセスするために API トークンおよび認証情報が自動的に割り当てられる。
プラットフォームのコンポーネントに関連付けられたサービスアカウントでは、キーが自動的にローテーションされます。
2.10.3. 認証および認可
2.10.3.1. OAuth を使用したアクセスの制御
コンテナープラットフォームのセキュリティーを保護にするために、認証および承認で API アクセス制御を使用することができます。OpenShift Container Platform マスターには、ビルトインの OAuth サーバーが含まれます。ユーザーは、OAuth アクセストークンを取得して API に対して認証することができます。
管理者として、LDAP、GitHub、または Google などの アイデンティティープロバイダー を使用して認証できるように OAuth を設定できます。新規の OpenShift Container Platform デプロイメントには、デフォルトでアイデンティティープロバイダーが使用されますが、これを初期インストール時またはインストール後に設定できます。
2.10.3.2. API アクセス制御および管理
アプリケーションには、管理を必要とする各種のエンドポイントを持つ複数の独立した API サービスを設定できます。OpenShift Container Platform には 3scale API ゲートウェイのコンテナー化されたバージョンが含まれており、これにより API を管理し、アクセスを制御することができます。
3scale は、API の認証およびセキュリティーについての様々な標準オプションを提供します。 これらは、認証情報を発行し、アクセスを制御するために単独で使用することも、他と組み合わせて使用することもできます (例: 標準 API キー、アプリケーション ID とキーペア、OAuth 2.0 など)。
アクセスについては、特定のエンドポイント、メソッド、およびサービスに制限することができ、アクセスポリシーをユーザーグループに適用することができます。アプリケーションの計画に基づいて、API の使用にレート制限を設定したり、開発者グループのトラフィックフローを制御したりすることが可能です。
APIcast v2 (コンテナー化された 3scale API ゲートウェイ) の使用についてのチュートリアルは、3scale ドキュメントの Running APIcast on Red Hat OpenShift を参照してください。
2.10.3.3. Red Hat Single Sign-On
Red Hat Single Sign-On サーバーを使用すると、SAML 2.0、OpenID Connect、および OAuth 2.0 などの標準に基づく Web サインオン機能を提供し、アプリケーションのセキュリティーを保護することができます。このサーバーは、SAML または OpenID Connect ベースのアイデンティティープロバイダー (IdP) として機能します。つまり、標準ベースのトークンを使用して、アイデンティティー情報およびアプリケーションについてエンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの仲介を行います。Red Hat Single Sign-On を Microsoft Active Directory および Red Hat Enterprise Linux Identity Management を含む LDAP ベースのディレクトリーサービスと統合することが可能です。
2.10.3.4. セルフサービス Web コンソールのセキュリティー保護
OpenShift Container Platform はセルフサービスの Web コンソールを提供して、チームが認証なしに他の環境にアクセスできないようにします。OpenShift Container Platform は以下の条件に基づいてセキュアなマルチテナントマスターを提供します。
- マスターへのアクセスは Transport Layer Security (TLS) を使用する。
- API サーバーへのアクセスは X.509 証明書または OAuth アクセストークンを使用する。
- プロジェクトのクォータは不正トークンによるダメージを制限する。
- etcd サービスはクラスターに直接公開されない。
2.10.4. プラットフォームの証明書の管理
OpenShift Container Platform には、そのフレームワーク内に、TLS 証明書による暗号化を利用した REST ベースの HTTPS 通信を使用する複数のコンポーネントがあります。OpenShift Container Platform のインストーラーは、これらの認証をインストール時に設定します。以下は、このトラフィックを生成するいくつかの主要コンポーネントです。
- マスター (API サーバーとコントローラー)
- etcd
- ノード
- レジストリー
- ルーター
2.10.4.1. カスタム証明書の設定
API サーバーおよび Web コンソールのパブリックホスト名のカスタム提供証明書は、初回のインストール時または証明書の再デプロイ時に設定できます。カスタム CA を使用することも可能です。
