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.第7章 サービスアカウントの設定
7.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーが OpenShift Container Platform CLI または web コンソールを使用する場合、API トークンはユーザーを OpenShift Container Platform API に対して認証します。ただし、一般ユーザーの認証情報を利用できない場合、以下のようにコンポーネントが API 呼び出しを行うのが通例になります。
- レプリケーションコントローラーが Pod を作成するか、または削除するために API 呼び出しを実行する。
 - コンテナー内のアプリケーションが検出目的で API 呼び出しを実行する。
 - 外部アプリケーションがモニターまたは統合目的で API 呼び出しを実行する。
 
サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。
7.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
7.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 トークンとレジストリーの認証情報は期限切れになることはありませんが、シークレットを削除することで取り消すことができます。シークレットが削除されると、新規のシークレットが自動生成され、これに置き換わります。
7.4. サービスアカウント認証の有効化 リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントは、プライベート RSA キーで署名されるトークンを使用して API に対して認証されます。認証層では一致するパブリック RSA キーを使用して署名を検証します。
				サービスアカウントトークンの生成を有効にするには、マスターで /etc/origin/master/master-config.yml ファイルの serviceAccountConfig スタンザを更新し、(署名 用に) privateKeyFile と publicKeyFiles 一覧の一致するパブリックキーファイルを指定します。
			
7.5. 管理サービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
				サービスアカウントは、ビルド、デプロイメントおよびその他の Pod を実行するために各プロジェクトで必要になります。マスターの /etc/origin/master/master-config.yml ファイルの managedNames 設定は、すべてのプロジェクトに自動作成されるサービスアカウントを制御します。
			
- 1
 - すべてのプロジェクトで自動作成するサービスアカウントの一覧。
 - 2
 - A builder service account in each project is required by build pods, and is given the system:image-builder role, which allows pushing images to any image stream in the project using the internal container registry.
 - 3
 - 各プロジェクトの deployer サービスアカウントはデプロイメント Pod で必要になり、レプリケーションコントローラーおよびプロジェクトの Pod の表示および変更を可能にする system:deployer ロールが付与されます。
 - 4
 - デフォルトのサービスアカウントは、別のサービスアカウントが指定されない限り、他のすべての Pod で使用されます。
 
All service accounts in a project are given the system:image-puller role, which allows pulling images from any image stream in the project using the internal container registry.
7.6. インフラストラクチャーサービスアカウント リンクのコピーリンクがクリップボードにコピーされました!
一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に OpenShift Container Platform インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体で以下のロールが付与されます。
| サービスアカウント | 説明 | 
|---|---|
| 
							 replication-controller  | 
							 system:replication-controller ロールの割り当て  | 
| 
							 deployment-controller  | 
							 system:deployment-controller ロールの割り当て  | 
| 
							 build-controller  | 
							 system:build-controller ロールの割り当て。さらに、build-controller サービスアカウントは、特権付きの ビルド Pod を作成するために特権付きセキュリティーコンテキストに組み込まれます。  | 
				これらのサービスアカウントが作成されるプロジェクトを設定するには、マスターで /etc/origin/master/master-config.yml ファイルの openshiftInfrastructureNamespace フィールドを設定します。
			
policyConfig: ... openshiftInfrastructureNamespace: openshift-infra
policyConfig:
  ...
  openshiftInfrastructureNamespace: openshift-infra
7.7. サービスアカウントおよびシークレット リンクのコピーリンクがクリップボードにコピーされました!
				マスターで /etc/origin/master/master-config.yml ファイルの limitSecretReferences フィールドを true に設定し、Pod のシークレット参照をサービスアカウントでホワイトリストに入れることが必要になるようにします。この値を false に設定すると、Pod がプロジェクトのすべてのシークレットを参照できるようになります。
			
serviceAccountConfig: ... limitSecretReferences: false
serviceAccountConfig:
  ...
  limitSecretReferences: false