53- 第12章：OpenShiftリソースへのアクセス制御-6：セキュリティポリシーの管理の説明

type

status

date

slug

summary

セキュリティポリシーの管理

目標

このセクションを終了した後、学生はコマンドラインインターフェースを使用してセキュリティポリシーを管理できるようになります。

Red Hat OpenShift Container Platformの認証

Red Hat OpenShift Container Platformでは、ユーザーが実行できる操作は2つの主要なグループに分類されます：

プロジェクト関連の操作（ローカルポリシーとも呼ばれます）

管理関連の操作（クラスターポリシーとも呼ばれます）

両方のポリシーに対して実行可能な操作の数が多いため、いくつかの操作はグループ化され、役割として定義されています。

デフォルトの役割（ロール）の説明

役割（Role）	説明
cluster-admin	この役割のユーザーはOpenShiftクラスタの管理ができます。
cluster-status	この役割のユーザーはクラスタに関する情報を読み取り専用でアクセスできます。

クラスターロールのユーザーへの追加

ユーザーにクラスターロールを追加するには、add-cluster-role-to-user サブコマンドを使用します：

例えば、通常のユーザーをクラスタ管理者に変更するには、以下のコマンドを使用します：

クラスターロールをユーザーから削除するには、remove-cluster-role-from-user サブコマンドを使用します：

例えば、クラスタ管理者を通常のユーザーに変更するには、以下のコマンドを使用します：

OpenShiftは一連のルールをロールとして整理します。ルールは動詞とリソースで定義されます。例えば、create user はOpenShiftのルールの1つで、cluster-admin というロールに含まれています。

oc adm policy who-can コマンドを使用して、特定のロールを実行できるユーザーやロールを特定できます。例えば：

ローカルポリシーの管理

ローカルポリシーを管理するために、以下の役割が提供されています：

役割（Role）	説明
edit	この役割のユーザーは、サービスやデプロイメント設定などのプロジェクト内の一般的なアプリケーションリソースを作成、変更、削除できます。ただし、制限範囲やクォータ、プロジェクトへのアクセス権限の管理はできません。
basic-user	この役割のユーザーは、プロジェクトへの読み取りアクセス権限を持ちます。
selfprovisioner	この役割のユーザーは、新しいプロジェクトを作成できます。これはクラスターロールであり、プロジェクトロールではありません。
admin	この役割のユーザーは、プロジェクト内のすべてのリソースを管理できます。これには、プロジェクトに他のユーザーへのアクセスを付与することも含まれます。

admin ロールは、ユーザーにプロジェクトリソース（クォータや制限範囲など）へのアクセスを提供し、さらに新しいアプリケーションを作成する能力を与えます。一方、edit ロールは、プロジェクト内で開発者として機能するのに十分なアクセス権限を提供しますが、プロジェクト管理者が設定した制約内で作業することになります。

指定されたユーザーをプロジェクト内のロールに追加するには、add-role-to-user サブコマンドを使用します：

例えば、wordpress プロジェクト内で dev ユーザーを basic-user ロールに追加するには、以下のコマンドを使用します：

ユーザータイプ

OpenShift Container Platformとのインタラクションは、ユーザーと関連付けられています。OpenShift Container Platformのユーザーオブジェクトは、システムでロールを追加することによって、そのユーザーまたはユーザーグループに権限を付与できるユーザーを表します。

通常のユーザー: これはほとんどのインタラクティブなOpenShift Container Platformのユーザーを表します。通常のユーザーはUserオブジェクトで表されます。例えば、user1やuser2が該当します。

システムユーザー: これらのユーザーの多くは、インフラストラクチャが定義される際に自動的に作成され、主にインフラストラクチャがAPIと安全にやり取りできるようにするために使用されます。システムユーザーには、クラスタ管理者（すべてにアクセスできるユーザー）、各ノードのユーザー、ルーターやレジストリのためのユーザー、その他さまざまなユーザーが含まれます。また、認証されていないリクエストにデフォルトで使用される匿名のシステムユーザーも存在します。システムユーザーの例には、system:admin、system:openshift-registry、system:node:node1.example.comなどがあります。

サービスアカウント: これらはプロジェクトに関連付けられた特別なシステムユーザーです。プロジェクトが最初に作成されるときに自動的に作成されることもありますし、プロジェクト管理者がプロジェクト内のコンテンツへのアクセスを定義するために追加で作成することもあります。サービスアカウントはServiceAccountオブジェクトで表されます。サービスアカウントユーザーの例には、system:serviceaccount:default:deployerやsystem:serviceaccount:foo:builderなどがあります。

すべてのユーザーは、OpenShift Container Platformにアクセスする前に認証を行う必要があります。認証なしまたは無効な認証を持つAPIリクエストは、匿名のシステムユーザーとして認証されます。認証が成功した後、ポリシーに基づいてユーザーが実行できる操作が決まります。

セキュリティコンテキスト制約（SCC）

OpenShiftには、リソースへのアクセスを制限するセキュリティメカニズムであるセキュリティコンテキスト制約（SCC）がありますが、これはOpenShift内での操作には制限を加えません。

SCCは、OpenShift内の実行中のポッドがホスト環境にアクセスする方法を制限します。具体的には以下を制御します：

特権コンテナの実行

コンテナに追加機能を要求すること

ホストディレクトリをボリュームとして使用すること

コンテナのSELinuxコンテキストを変更すること

ユーザーIDの変更

コミュニティによって開発された一部のコンテナは、デフォルトで禁止されているリソース（例えばファイルシステムやソケット、SELinuxコンテキストへのアクセス）にアクセスする必要があるため、セキュリティコンテキスト制約を緩和する必要がある場合があります。

OpenShiftによって定義されたセキュリティコンテキスト制約（SCC）は、クラスタ管理者として以下のコマンドで一覧表示できます：

OpenShiftには7つのSCCが存在します：

anyuid

hostaccess

hostmount-anyuid

nonroot

privileged

restricted

SCCに関する追加情報を得るには、describeコマンドを使用します：

例：

OpenShiftで作成されたすべてのコンテナは、restrictedというSCCを使用し、これによりOpenShift外部のリソースへのアクセスが制限されます。

anyuidセキュリティコンテキストの場合、run as user戦略はRunAsAnyとして定義されています。これにより、ポッドはコンテナ内で利用可能な任意のユーザーIDとして実行できます。これにより、特定のユーザーIDでコマンドを実行する必要があるコンテナが許可されます。

コンテナを異なるSCCで実行するように変更するには、サービスアカウントを作成してポッドにバインドする必要があります。サービスアカウントを作成するには、以下のコマンドを使用します：

サービスアカウントとSCCを関連付けるには、次のコマンドを使用します：

セキュリティ要件を満たすポッドを作成できるアカウントを識別するには、scc-subject-reviewサブコマンドを使用します。これにより、コンテナの制限を克服するために使用できるすべてのセキュリティ制約コンテキストが返されます：

OpenShiftとSELinux

OpenShiftでは、各ホストでSELinuxを有効にする必要があります。これにより、必須アクセス制御（Mandatory Access Control）を使用してリソースへの安全なアクセスが提供されます。同様に、OpenShiftが管理するDockerコンテナは、互換性の問題を避けるためにSELinuxコンテキストを管理する必要があります。コンテナがSELinuxサポートなしで実行されるリスクを最小限に抑えるため、SELinuxコンテキスト戦略を作成することができます。

SELinuxコンテキストの更新

SELinuxコンテキストを更新するためには、既存のSCCを出発点として新しいSCCを作成できます。次のコマンドを使用して、restrictedというSCCをエクスポートします：

次に、YAMLファイルを編集してSCCの名前とSELinuxコンテキストを変更します。具体的な変更内容は以下の通りです：

SCC名とSELinuxコンテキストタイプを変更します。seLinuxContextのtypeをMustRunAsからRunAsAnyに変更して、SELinuxを無効にします。

新しいSCCを作成するには、次のコマンドを実行します：

特権コンテナ

一部のコンテナはホストの実行環境にアクセスする必要があります。例えば、S2Iビルダーコンテナはコンテナをビルドして実行するためにホストのDockerデーモンにアクセスする必要があります。S2Iビルダーコンテナは、特権コンテナの一種で、独自のコンテナの制限を超えてアクセスが必要です。これらのコンテナは、OpenShiftノード上の任意のリソースを使用できるため、セキュリティリスクを伴う可能性があります。

特権コンテナへのアクセスを有効にするためには、サービスアカウントを作成して特権アクセスを付与することで、SCCを使用してアクセスを制御することができます。