IAM 役割とアクション

IBM Cloud Kubernetes Service は、 IBM Cloud® Identity and Access Management 役割を使用して、ユーザーが IBM Cloud Kubernetes Service クラスター、ワーカー・ノードに対して実行できるアクションを決定するように構成されます。

プラットフォーム役割とサービス役割、およびそれらに関連するアクションのリストについては、以下の表を参照してください。

すべての IBM サービスとそれらに関連する役割およびアクションのリストについては、 IAM 役割およびアクションを参照してください。アカウントとリソースのセットアップについて詳しくは、ユーザー、チーム、およびアプリケーションを編成するためのベスト・プラクティスを参照してください。

プラットフォーム・アクセス役割: プラットフォーム・アクセス役割を使用すると、ユーザーはクラスター、ワーカー・プール、ワーカー・ノード、アドオンのようなリソースを管理できます。プラットフォーム・アクセス役割によって許可される操作には、例えば、クラスターの作成/削除、クラスターへのサービスのバインディング、ネットワーキング・リソースやストレージ・リソースの管理、ワーカー・ノードの追加などがあります。これらの役割のポリシーは、リソース・グループ、リージョン、またはクラスター・インスタンスごとに設定できます。クラスター内の名前空間によってプラットフォーム・アクセス役割のスコープを設定することはできません。プラットフォーム・アクセス役割では、Kubernetes ポッド、名前空間、サービスなど、クラスター内のリソースを管理するための Kubernetes API へのアクセス権限は付与されません。
サービス・アクセス役割: サービス・アクセス役割を使用して、 IBM Cloud Kubernetes Service クラスター内の Kubernetes リソースを管理するためのアクセス権限をユーザーに付与します。サービスアクセス権限は、クラスタ内の対応する Kubernetes RBACポリシーと同期されます。そのため、サービスアクセスロールは、 Kubernetes API、ダッシュボード、CLI（kubectl ）へのアクセスを許可します。サービスアクセスロールによって許可される操作の例としては、アプリのデプロイメントの作成、ネームスペースの追加、コンフィグマップの設定などがあります。サービス・アクセス役割のポリシーは、リソース・グループ、リージョン、またはクラスター・インスタンスごとに設定できます。さらに、サービス・アクセス役割の範囲を、すべてのクラスター、個々のクラスター、または特定のリージョン内のクラスターにある Kubernetes 名前空間に設定することもできます。

クラスターを作成するための許可

使用する可能性のある他の統合およびサービスに必要な権限を含め、クラスターを作成するために必要な以下の権限を確認してください。

クラスターを作成するために必要な IAM 役割。
サービスまたはリソース・グループ	ロール	有効範囲	必須ですか?
Kubernetes Service	管理者のプラットフォーム・アクセス役割ライターまたは管理者のサービス・アクセス役割	クラスターを作成するリソース・グループを指定します。	ある
Container Registry	管理者プラットフォームへのアクセス権限。	個々のインスタンスまたはすべてのインスタンス。 IBM Cloud Container Registry のポリシーを、リソース・グループ・レベルに制限しないでください。	ある
Secrets Manager	管理者またはエディターのプラットフォーム・アクセス役割管理者のサービス・アクセス役割	すべてのリソース・グループ	暗号化に Secrets Manager を使用する予定の場合は必須です。
リソース・グループ権限	ビューアープラットフォームへのアクセス権限	クラスターを作成するリソース・グループを指定します。	ある
IAM Identity Service	サービス ID 作成者ユーザー API キー作成者役割ビューアー・プラットフォーム・アクセス役割	クラスターを作成するリソース・グループを指定します。	ある
Key Protect	管理者プラットフォームへのアクセス権限。	すべてのインスタンス、または使用する特定のインスタンス。	暗号化に Key Protect を使用する予定の場合は必須です。
Hyper Protect Crypto Services	管理者プラットフォームへのアクセス権限。	すべてのインスタンス、または使用する特定のインスタンス。	暗号化に Hyper Protect Crypto Services を使用する予定の場合は必須です。
クラシック・インフラストラクチャー	スーパーユーザー役割。詳しくは、クラシック・インフラストラクチャーの役割を参照してください。	該当なし	ある
VPC インフラストラクチャー	VPCインフラストラクチャの管理者プラットフォームアクセス権限。	すべてのインスタンス、または使用する特定のインスタンス。	ある

前の表で概説した権限をカスタム IAM 役割として保存することを検討してください。このようにして、個々のサービスを割り当てる代わりに、ユーザーをカスタム役割に割り当てることができます。詳しくは、以下のカスタム役割の例、またはカスタム役割の作成に関する IAM 資料を参照してください。

カスタム IAM 役割の例

以下の表に、ユース・ケースの例と、それらのケースに対応する IAM 役割を示します。これらの例を使用することも、独自のカスタム役割を作成することもできます。アクセス権限について詳しくは、カスタム役割の作成を参照してください。

さまざまなユース・ケースを満たすために割り当てることができる役割のタイプ
カスタム役割の例	権限
アプリ監査員	クラスタ、リージョン、またはリソースグループに対するビューアープラットフォームのアクセス権限。クラスタ、リージョン、またはリソースグループに対するリーダーサービスへのアクセス権限。
アプリ開発者	-クラスターに対するエディター・プラットフォーム・アクセス役割。 -名前空間にスコープ設定されたライター・サービス・アクセス役割。
課金	クラスタ、リージョン、またはリソースグループに対するビューアープラットフォームへのアクセス権限。
クラスター管理者	-クラスターに対する管理者のプラットフォーム・アクセス役割。 -クラスター全体に対する管理者のサービス・アクセス役割 (有効範囲は名前空間ではありません)。
DevOps オペレーター	-クラスターに対するオペレーター・プラットフォーム・アクセス役割。 -クラスター全体に対するライター・サービス・アクセス役割 (有効範囲は名前空間ではありません)。
オペレーターまたはサイト信頼性エンジニア	クラスタ、リージョン、またはリソースグループの管理プラットフォームアクセス権限。クラスタまたはリージョンのリーダーサービスアクセス権限。すべてのクラスタのネームスペースで `kubectl top nodes,pods` コマンドを使用できるマネージャーサービスアクセス権限。

クラシック・インフラストラクチャーの役割

スーパーユーザー インフラストラクチャアクセスロールを持つユーザーは、インフラストラクチャアクションを実行できるように、リージョンとリソースグループの API キーを設定します。

アカウント内の他のユーザーが実行できるインフラストラクチャのアクションは、 IBM Cloud のIAMプラットフォームのアクセス権限によって承認されます。

APIキーを設定するユーザーにスーパーユーザーを割り当てることができない場合に限り、以下の表を使用してクラシックインフラストラクチャの権限をカスタマイズしてください。許可の割り当てについて詳しくは、インフラストラクチャー許可のカスタマイズを参照してください。

必須のクラシック・インフラストラクチャー許可

表 1: 必要なクラシック・インフラストラクチャー許可
権限	説明
IPMI リモート管理	ワーカー・ノードを管理します。
サーバーの追加	ワーカー・ノードを追加します。注: パブリック IP アドレスを持つワーカー・ノードの場合は、「ネットワーク」カテゴリーの「パブリック・ネットワーク・ポートでのコンピュートの追加」の許可も必要です。
サーバーのキャンセル	ワーカー・ノードを削除します。
OS の再ロードとカーネルのレスキュー	ワーカー・ノードを更新、リブート、および再ロードします。
仮想サーバーの詳細の表示	クラスターに VM ワーカー・ノードがある場合は必須です。 VM ワーカー・ノードの詳細をリストおよび取得します。
ハードウェアの詳細の表示	クラスターにベアメタル・ワーカー・ノードがある場合は必須です。ベアメタル・ワーカー・ノードの詳細をリストおよび取得します。
サポート Caseの追加	クラスター作成自動化の一環として、クラスター・インフラストラクチャーをプロビジョンするためにサポート Case が開かれます。
サポート Case の編集	クラスター作成自動化の一環として、クラスター・インフラストラクチャーをプロビジョンするためにサポート Case が更新されます。
サポート Case の表示	クラスター作成自動化の一環として、クラスター・インフラストラクチャーをプロビジョンするためにサポート Case が使用されます。

推奨されているクラシック・インフラストラクチャー許可

表 2: 推奨されるクラシック・インフラストラクチャー許可
権限	説明
仮想サーバーへの自動アクセス	すべてのワーカー・ノードにアクセスします。
ベアメタル・サーバーへの自動アクセス	すべてのベアメタル・ワーカー・ノードへのアクセスを指定します。この許可がないと、1 つのクラスターを作成するユーザーは、そのクラスターと別のクラスターの両方に対する IAM アクセス権限を持っていても、別のクラスターのベアメタル・ワーカー・ノードを表示できない場合があります。
パブリック・ネットワーク・ポートのコンピュートを追加	ワーカー・ノードがパブリック・ネットワーク上でアクセス可能なポートを持つようにします。
DNS の管理	アプリを公開するためにパブリック・ロード・バランサーまたは Ingress ネットワーキングをセットアップする。
ホスト名/ドメインの編集	アプリを公開するためにパブリック・ロード・バランサーまたは Ingress ネットワーキングをセットアップする。
IP アドレスの追加	クラスター・ロード・バランシングに使用するパブリック・サブネットまたはプライベート・サブネットに IP アドレスを追加します。
ネットワーク・サブネット経路の管理	クラスター・ロード・バランシングに使用するパブリックまたはプライベートの VLAN およびサブネットを管理します。
ポート・コントロールの管理	アプリのロード・バランシングに使用するポートを管理します。
証明書 (SSL) の管理	クラスター・ロード・バランシングに使用する証明書をセットアップします。
証明書 (SSL) の表示	クラスター・ロード・バランシングに使用する証明書をセットアップします。
ストレージの追加/アップグレード (ストレージ層)	データを永続的に保管するためのボリュームとしてアプリに接続する IBM Cloud ファイル・ストレージ・インスタンスまたはブロック・ストレージ・インスタンスを作成します。
ストレージ管理	データを永続的に保管するためのボリュームとしてアプリに接続された IBM Cloud ファイル・ストレージ・インスタンスまたはブロック・ストレージ・インスタンスを管理します。