11.2. デフォルトのサービスアカウント

OpenShift Container Platform クラスターには、クラスター管理用のデフォルトのサービスアカウントが含まれ、各プロジェクトのサービスアカウントは追加で生成されます。

11.2.1. デフォルトのクラスターサービスアカウント

一部のインフラストラクチャーコントローラーは、サービスアカウント認証情報を使用して実行されます。以下のサービスアカウントは、サーバーの起動時に OpenShift Container Platform インフラストラクチャープロジェクト (openshift-infra) に作成され、クラスター全体での以下のロールが付与されます。

サービスアカウント説明

replication-controller

system:replication-controller ロールが割り当てられます。

deployment-controller

system:deployment-controller ロールが割り当てられます。

build-controller

system:build-controller ロールが割り当てられます。さらに、build-controller サービスアカウントは、特権付きのビルド Pod を作成するために特権付きセキュリティーコンテキストに組み込まれます。

11.2.2. デフォルトのプロジェクトサービスアカウントおよびロール

3 つのサービスアカウントが各プロジェクトで自動的に作成されます。

サービスアカウント使用法

builder

ビルド Pod で使用されます。これには system:image-builder ロールが付与されます。 このロールは、内部 Docker レジストリーを使用してイメージをプロジェクトのイメージストリームにプッシュすることを可能にします。

deployer

デプロイメント Pod で使用され、system:deployer ロールが付与されます。 このロールは、プロジェクトでレプリケーションコントローラーや Pod を表示したり、変更したりすることを可能にします。

default

別のサービスアカウントが指定されていない限り、その他すべての Pod を実行するために使用されます。

プロジェクトのすべてのサービスアカウントには system:image-puller ロールが付与されます。 このロールは、内部コンテナーイメージレジストリーを使用してイメージをイメージストリームからプルすることを可能にします。

11.2.3. 自動生成されるサービスアカウントトークンシークレット

OpenShift Container Platform 4.12 では アップストリームの Kubernetes から拡張機能 を採用しており、デフォルトで LegacyServiceAccountTokenNoAutoGeneration 機能が有効になっています。その結果、新規サービスアカウント (SA) の作成時に、サービスアカウントのトークンシークレットは自動的に生成されなくなりました。以前のバージョンでは、OpenShift Container Platform は新規 SA ごとにサービスアカウントトークンをシークレットに自動的に追加していました。

ただし、一部の機能とワークロードでは、OpenShift Controller Manager などの Kubernetes API サーバーと通信するためにサービスアカウントトークンシークレットが必要です。この要件は今後のリリースで変更される予定ですが、OpenShift Container Platform 4.12 には残ります。その結果、サービスアカウントトークンシークレットが必要な場合は、TokenRequest API を使用してバインドされたサービスアカウントトークンを要求するか、またはサービスアカウントのトークンシークレットを作成する必要があります。

4.12 にアップグレードした後、既存のサービスアカウントのトークンシークレットは削除されず、予想通りに機能し続けます。

注記

4.12 では、サービスアカウントのトークンシークレットは引き続き自動的に生成されます。サービスアカウントごとに 2 つのシークレットを作成する代わりに、OpenShift Container Platform は 1 つのシークレットのみを作成するようになりました。今後のリリースでは、この数はさらに減らされ、0 になる予定です。dockercfg シークレットは引き続き生成され、アップグレード中にシークレットは削除されないことに注意してください。

関連情報