49- 第12章：OpenShiftリソースへのアクセス制御-1：アクセス保護の説明

type

status

date

slug

summary

第12章

OpenShiftリソースへのアクセス制御

目標:

OpenShiftリソースへのアクセスを制御する。

目的:

OpenShiftのセキュリティ機能を使用してリソースを分離し、アクセスを制御する。

機密情報を管理するためにシークレットを作成し、適用する。

コマンドラインインターフェースを使用してセキュリティポリシーを管理する。

セクション:

OpenShiftリソースのセキュリティ確保（ガイド付き演習付き）

機密情報とシークレットの管理（ガイド付き演習付き）

セキュリティポリシーの管理（クイズ付き）

ラボ:

OpenShiftリソースへのアクセス制御

OpenShiftリソースのアクセス保護

目的

このセクションを修了すると、受講者は OpenShift のセキュリティ機能を使用してリソースを分離し、アクセスを制御できるようになります。

Kubernetes ネームスペース

Kubernetes のネームスペースは、関連するリソースのセットをグループ化するための仕組みを提供します。

Red Hat OpenShift Container Platform では、プロジェクトとは Kubernetes のネームスペースに追加のアノテーションを付与したものです。

ネームスペースには以下のような特徴があります：

リソースに名前を付けることで基本的な命名の衝突を防ぐ

信頼されたユーザーに管理権限を委譲できる

ユーザーのリソース消費量を制限できる

ユーザーやグループの分離が可能

プロジェクト

プロジェクトは、一般ユーザーがリソースにアクセスする方法を管理する仕組みです。

プロジェクトを使用すると、特定のグループのユーザーが自身のコンテンツを他のグループと分離して整理・管理できます。プロジェクトへのアクセスは管理者が付与する必要があります。もしユーザーがプロジェクトの作成を許可されている場合、自動的に自身のプロジェクトへのアクセス権を持つことになります。

プロジェクトには、以下の3つの名称を設定できます：

名前（必須）: CLI や API で最もよく使用される一意の識別子（最大63文字）。

表示名（任意）: Web コンソールで表示される名前（デフォルトでは「名前」と同じ）。

説明（任意）: プロジェクトの詳細な説明。Web コンソールで確認可能。

プロジェクトには以下のコンポーネントが適用されます：

オブジェクト：Pod、Service、Replication Controller など。

ポリシー：ユーザーがオブジェクトに対して実行できる操作を制御するルール。

制約：各オブジェクトの使用量を制限するクォータ設定。

クラスタ管理

クラスタ管理者はプロジェクトを作成し、特定のユーザーにそのプロジェクトの管理権限を委譲できます。

OpenShift Container Platform では、プロジェクトを使用して関連するオブジェクトをグループ化し、隔離することができます。管理者は、ユーザーに特定のプロジェクトへのアクセスを許可したり、プロジェクト作成を許可したり、個々のプロジェクト内での管理権限を付与できます。

管理者は、ユーザーやグループに対して ロール を適用することで、プロジェクト作成の可否を制御できます。ロールは、ユーザーが最初にログインする前に割り当てることが可能です。

ユーザーまたはグループのプロジェクト作成権限の制御

ユーザーやグループが新しいプロジェクトを作成できるかどうかを制御する方法は以下の通りです：

プロジェクト作成の制限

認証済みユーザーやグループから self-provisioner クラスタロールを削除すると、新規プロジェクトのセルフプロビジョニング権限が拒否されます。

プロジェクト作成の許可

self-provisioner ロールと self-provisioner クラスタロールバインディングを持つユーザーには、プロジェクト作成権限が付与されます。これらのロールは、デフォルトですべての認証済みユーザーに適用されます。

プロジェクトの作成

プロジェクト作成の権限がユーザーに付与されている場合、例えば以下のコマンドを使用して「demoproject」というプロジェクトを作成することができます：

Red Hat OpenShift Container Platform におけるロールの紹介

ロールは、クラスターおよびローカルポリシーの両方を含むさまざまなレベルのアクセスとポリシーを適用します。

ユーザーやグループは、複数のロールに同時に関連付けることができます。ロールとそのバインディングに関する詳細を確認するには、oc describe コマンドを実行します。

クラスターの cluster-admin デフォルトロールを持つユーザーは、クラスターのポリシーとすべてのローカルポリシーを表示できます。特定のローカルポリシーにおける admin デフォルトロールを持つユーザーは、プロジェクトごとにポリシーを表示できます。

現在のクラスターのバインディングセット（ユーザーやグループがさまざまなロールにバインドされている情報）を確認するには、以下のコマンドを実行します：

ローカルポリシーの読み取り

ローカルポリシー内では、ロールのリストや関連するルールセットは表示できませんが、すべてのデフォルトロールは依然として適用され、ユーザーやグループに追加することができます。ただし、cluster-admin ロールは除外されます。ローカルポリシーのバインディングは表示可能です。

現在のローカルバインディングセット（ユーザーやグループがさまざまなロールにバインドされている情報）を確認するには、以下のコマンドを実行します：

注意

デフォルトでは、ローカルポリシー内では admin ロールのバインディングのみが即座にリスト表示されます。

ただし、他のデフォルトロールがローカルポリシー内のユーザーやグループに追加されると、それらもリストに表示されます。

ロールバインディングの管理

ユーザーやグループにロールを追加（またはバインド）することで、そのユーザーやグループにロールによって付与されたアクセス権限が与えられます。oc adm policy コマンドを使用して、ユーザーやグループに対してロールを追加または削除できます。

ローカルポリシーのユーザーおよびグループロールを管理する場合、-n オプションを使用してプロジェクトを指定できます。指定しない場合、現在のプロジェクトが使用されます。

以下の表は、ローカルポリシーの管理に使用される操作の一部を示しています：

コマンド	説明
`oc adm policy who-can verb resource`	特定のリソースに対してどのユーザーがアクションを実行できるかを表示
`oc adm policy add-role-to-user role username`	特定のユーザーに指定されたロールをバインド
`oc adm policy remove-role-from-user role username`	特定のユーザーから指定されたロールを削除
`oc adm policy remove-user username`	特定のユーザーおよびそのユーザーのロールを削除
`oc adm policy add-role-to-group role groupname`	特定のグループに指定されたロールをバインド
`oc adm policy remove-role-from-group role groupname`	特定のグループから指定されたロールを削除
`oc adm policy remove-group groupname`	特定のグループおよびそのグループのロールを削除

クラスタポリシーの管理

クラスタポリシーに関しては、ローカルポリシーと異なり、-n オプションは使用されません。クラスタポリシーはネームスペースレベルでは動作しないためです。

以下の表は、クラスタポリシーの管理に使用される操作の一部を示しています：

コマンド	説明
`oc adm policy add-cluster-role-to-user role username`	クラスター内のすべてのプロジェクトに対して、指定されたユーザーにロールをバインド
`oc adm policy remove-cluster-role-from-user role username`	クラスター内のすべてのプロジェクトに対して、指定されたユーザーからロールを削除
`oc adm policy add-cluster-role-to-group role groupname`	クラスター内のすべてのプロジェクトに対して、指定されたグループにロールをバインド
`oc adm policy remove-cluster-role-from-group role groupname`	クラスター内のすべてのプロジェクトに対して、指定されたグループからロールを削除

注意

oc policy コマンドは現在のプロジェクトに適用されますが、oc adm policy コマンドはクラスタ全体の操作に適用されます（重複する部分もあります）。

例えば、example プロジェクトで developer ユーザーに admin ロールを与えるには、次のコマンドを実行します：

バインディングの詳細を確認するには、次のコマンドを実行します：

出力例：

この例では、developer ユーザーが admin ロールを持っていることが確認できます。

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

OpenShift では、セキュリティコンテキスト制約（SCC）を使用して、Pod が実行できるアクションやアクセスできるリソースを制御します。デフォルトでは、任意のコンテナの実行には restricted SCC が適用され、限定された権限が付与されます。

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

SCC（セキュリティコンテキスト制約）は、後のセクションで詳細に説明されます。

利用可能なSCCを一覧表示するには、次のコマンドを使用します：

選択したSCCの詳細な説明を表示するには、次のコマンド構文を使用します：

特定のユーザーやグループにSCCを付与するには、次のコマンド構文を使用します：

ユーザーやグループを特定のSCCから削除するには、次のコマンド構文を使用します：

サービスアカウントの使用例

サービスアカウントは、通常のユーザーの資格情報を共有することなくAPIアクセスを制御する柔軟な方法を提供します。制限されたSCCでは付与されていない機能を必要とするアプリケーションがある場合、新しい特定のサービスアカウントを作成して適切なSCCに追加することができます。

例えば、特権を必要とするアプリケーションのデプロイは、デフォルトではOpenShiftでサポートされていません。ただし、このアプリケーションを制限を超えてデプロイする必要がある場合、次のような方法で解決できます：

新しいサービスアカウント（useroot）を作成します：

アプリケーションのデプロイメント設定を変更します：

useroot サービスアカウントを anyuid SCC に追加して、コンテナ内でrootユーザーとして実行できるようにします：

ユーザーのメンバーシップ管理

Red Hat OpenShift Container Platform のデフォルト設定では、ユーザーが初めてログインした際に自動的に新しいユーザーが作成されます。ユーザーの資格情報がアイデンティティプロバイダーによって受け入れられると、OpenShift はユーザーオブジェクトを作成します。

Webコンソールを使用したメンバーシップ管理

プロジェクトへのアクセスを許可されたユーザーを管理するには、プロジェクト管理者またはクラスタ管理者としてWebコンソールにログインし、管理するプロジェクトを選択します。左側のペインで「リソース」→「メンバーシップ」をクリックして、プロジェクトのメンバーシップページに入ります。

ユーザーの名前を強調表示されたテキストボックスに入力し、「もう一つのロールを追加」列でそのユーザーと同じ行にあるロールを選択して「追加」をクリックします。

CLIを使用したメンバーシップ管理

ユーザーの自動作成が無効にされている場合、クラスタ管理者は oc create user コマンドを使用して新しいユーザーを作成します：

各ユーザーはアイデンティティプロバイダーにも作成される必要があります。HTPasswdIdentityProvider モジュールの場合、htpasswd コマンドを使用します：

プロジェクトロールをユーザーに追加するには、まず oc project コマンドでプロジェクトに入ってから、oc policy add-role-to-user コマンドを使用します：

プロジェクトロールをユーザーから削除するには、oc policy remove-role-from-user コマンドを使用します：

すべてのOpenShiftロールはプロジェクトスコープで定義されているわけではありません。これらのルールを適用するためには、oc adm policy コマンドを使用します。以下の例は、ユーザーにクラスタ管理者の権限を付与する方法です：

認証と認可レイヤー

認証レイヤーは、OpenShift Container Platform APIへのリクエストに関連するユーザーを識別します。その後、認可レイヤーは、リクエストが許可されるべきかどうかを判断するために、リクエストを送信したユーザーに関する情報を使用します。

ユーザーとグループ

Red Hat OpenShift Container Platformにおけるユーザーは、OpenShift APIへのリクエストを行うエンティティです。通常、これはOpenShiftとやり取りを行う開発者や管理者のアカウントを表します。

ユーザーは1つ以上のグループに割り当てられることができ、各グループは特定のロール（または権限）のセットを表します。グループは、複数のユーザーに同時に権限を付与する際に便利です。たとえば、個別に権限を付与するのではなく、プロジェクト内のオブジェクトへのアクセスを許可するために使用されます。

認証トークン

API呼び出しは、アクセストークンまたはX.509証明書で認証する必要があります。セッショントークンはユーザーを表し、デフォルトで24時間以内に期限が切れます。

認証されたユーザーは、oc whoami コマンドを実行して確認できます：

認証タイプ

このコースでは、認証は HTPasswdIdentityProvider モジュールによって提供されており、htpasswd コマンドを使用して生成された平文ファイルに対してユーザー名とパスワードが検証されます。

OpenShift Container Platform でサポートされているその他の認証タイプ

基本認証（リモート）

ユーザーは、リモートアイデンティティプロバイダーに対して検証された資格情報を使用して、OpenShift Container Platformにログインします。ユーザー名とパスワードは、OpenShift Container Platform に送信され、その後、サーバー間リクエストを行い、基本認証ヘッダーを通じてリモートサーバーで資格情報が検証されます。ユーザーはログインプロセス中に資格情報を入力する必要があります。

リクエストヘッダー認証

ユーザーは、リクエストヘッダー値（例えば、X-RemoteUser）を使用してOpenShift Container Platformにログインします。これは、ユーザーが認証を行い、その後、リクエストヘッダーを介してOpenShiftにユーザーのIDが渡される認証プロキシと組み合わせて使用されることが一般的です。

Keystone認証

Keystone は、OpenStackプロジェクトで、アイデンティティ、トークン、カタログ、およびポリシーサービスを提供します。OpenShift Container PlatformはKeystoneと統合されており、内部データベースにユーザーを格納するように設定されたOpenStack Keystone v3サーバーと共有認証を有効にします。この設定により、ユーザーはKeystoneの資格情報を使用してOpenShift Container Platformにログインできます。

LDAP認証

ユーザーはLDAP資格情報を使用してOpenShift Container Platformにログインします。認証中、LDAPディレクトリは提供されたユーザー名に一致するエントリを検索します。一致するものが見つかると、提供されたパスワードを使用して簡単なバインドが試みられます。

GitHub認証

GitHubはOAuthを使用しており、これによりOpenShift Container Platformとの統合が可能になります。このOAuth認証を使用してトークン交換フローを促進し、GitHubの資格情報を使用してOpenShift Container Platformにログインできます。また、特定のGitHub組織に属しているユーザーのみにアクセスを制限することで、GitHubユーザーIDを持つ不正なユーザーのログインを防止できます。