This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第9章 サービスアカウントの設定
9.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが OpenShift Container Platform CLI または web コンソールを使用する場合、API トークンはユーザーを OpenShift Container Platform API に対して認証します。ただし、一般ユーザーの認証情報を利用できない場合、以下のようにコンポーネントが API 呼び出しを行うのが通例になります。
- レプリケーションコントローラーが Pod を作成するか、または削除するために API 呼び出しを実行する。
- コンテナー内のアプリケーションが検出目的で API 呼び出しを実行する。
- 外部アプリケーションがモニターまたは統合目的で API 呼び出しを実行する。
サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。
9.2. ユーザー名およびグループ リンクのコピーリンクがクリップボードにコピーされました!
すべてのサービスアカウントには、一般ユーザーのように、ロールを付与できるユーザー名が関連付けられています。ユーザー名はそのプロジェクトおよび名前から派生します。
system:serviceaccount:<project>:<name>
system:serviceaccount:<project>:<name>
たとえば、view (表示) ロールを top-secret プロジェクトの robot サービスアカウントに追加するには、以下を実行します。
oc policy add-role-to-user view system:serviceaccount:top-secret:robot
$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
プロジェクトの特定のサービスアカウントにアクセスを付与する必要がある場合は、-z
フラグを使用できます。サービスアカウントが属するプロジェクトから、-z
フラグを使用し、<serviceaccount_name>
を指定します。これにより誤字を防ぎ、アクセスを指定したサービスアカウントのみに付与できるため、この方法を使用することを強くお勧めします。以下は例になります。
oc policy add-role-to-user <role_name> -z <serviceaccount_name>
$ oc policy add-role-to-user <role_name> -z <serviceaccount_name>
プロジェクトにいない場合は、以下の例に示すように -n
オプションを使用してこれを適用するプロジェクトの namespace を示します。
すべてのサービスアカウントは以下の 2 つのグループのメンバーです。
- system:serviceaccount
- システムのすべてのサービスアカウントが含まれます。
- system:serviceaccount:<project>
- 指定されたプロジェクトのすべてのサービスアカウントが含まれます。
たとえば、すべてのプロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを表示できるようにするには、以下を実行します。
oc policy add-role-to-group view system:serviceaccount -n top-secret
$ oc policy add-role-to-group view system:serviceaccount -n top-secret
managers プロジェクトのすべてのサービスアカウントが top-secret プロジェクトのリソースを編集できるようにするには、以下を実行します。
oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret
$ oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret
9.3. サービスアカウントの管理 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、各プロジェクトに存在する API オブジェクトです。サービスアカウントを管理するには、sa
または serviceaccount
オブジェクトタイプと共に oc
コマンドを使用するか、または web コンソールを使用することができます。
現在のプロジェクトで既存のサービスアカウントの一覧を取得するには、以下を実行します。
oc get sa
$ oc get sa
NAME SECRETS AGE
builder 2 2d
default 2 2d
deployer 2 2d
新規のサービスアカウントを作成するには、以下を実行します。
oc create sa robot
$ oc create sa robot
serviceaccount "robot" created
サービスアカウントの作成後すぐに、以下の 2 つのシークレットがこれに自動的に追加されます。
- API トークン
- OpenShift Container レジストリーの認証情報
これらは、サービスアカウントの記述で表示できます。
システムはサービスアカウントに API トークンとレジストリーの認証情報が常にあることを確認します。
生成される API トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。
9.4. サービスアカウント認証の有効化 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、プライベート RSA キーで署名されるトークンを使用して API に対して認証されます。認証層では一致するパブリック RSA キーを使用して署名を検証します。
サービスアカウントトークンの生成を有効にするには、マスターで /etc/origin/master/master-config.yml ファイルの serviceAccountConfig
スタンザを更新し、(署名 用に) privateKeyFile
と publicKeyFiles
一覧の一致するパブリックキーファイルを指定します。
9.5. 管理サービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、ビルド、デプロイメントおよびその他の Pod を実行するために各プロジェクトで必要になります。マスターの /etc/origin/master/master-config.yml ファイルの managedNames
設定は、すべてのプロジェクトに自動作成されるサービスアカウントを制御します。
- 1
- すべてのプロジェクトで自動作成するサービスアカウントの一覧。
- 2
- 各プロジェクトの builder サービスは、ビルド Pod で必要になり、内部コンテナーレジストリーを使用してプロジェクトのイメージストリームにイメージをプッシュする system:image-builder ロールが付与されます。
- 3
- 各プロジェクトの deployer サービスアカウントはデプロイメント Pod で必要になり、レプリケーションコントローラーおよびプロジェクトの Pod の表示および変更を可能にする system:deployer ロールが付与されます。
- 4
- デフォルトのサービスアカウントは、別のサービスアカウントが指定されない限り、他のすべての Pod で使用されます。
プロジェクトのすべてのサービスアカウントには、内部コンテナーレジストリーを使用してイメージストリームからイメージのプルを可能にする system:image-puller ロールが付与されます。
9.6. インフラストラクチャーサービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に OpenShift Container Platform インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体で以下のロールが付与されます。
サービスアカウント | 説明 |
---|---|
replication-controller |
system:replication-controller ロールの割り当て |
deployment-controller |
system:deployment-controller ロールの割り当て |
build-controller |
system:build-controller ロールの割り当て。さらに、build-controller サービスアカウントは、特権付きの ビルド Pod を作成するために特権付き SCC (Secutiry Context Constraint) に組み込まれます。 |
これらのサービスアカウントが作成されるプロジェクトを設定するには、マスターで /etc/origin/master/master-config.yml ファイルの openshiftInfrastructureNamespace
フィールドを設定します。
policyConfig: ... openshiftInfrastructureNamespace: openshift-infra
policyConfig:
...
openshiftInfrastructureNamespace: openshift-infra
9.7. サービスアカウントおよびシークレット リンクのコピーリンクがクリップボードにコピーされました!
マスターで /etc/origin/master/master-config.yml ファイルの limitSecretReferences
フィールドを true
に設定し、Pod のシークレット参照をサービスアカウントでホワイトリストに入れることが必要になるようにします。この値を false
に設定すると、Pod がプロジェクトのすべてのシークレットを参照できるようになります。
serviceAccountConfig: ... limitSecretReferences: false
serviceAccountConfig:
...
limitSecretReferences: false