次の方法で共有


Azure Arc 対応 Kubernetes クラスターでの Azure RBAC

Kubernetes の ClusterRoleBinding および RoleBinding オブジェクト型は、Kubernetes でネイティブに承認を定義するのに役立ちます。 Azure ロールベースのアクセス制御 (Azure RBAC) では、Microsoft Entra ID と Azure でのロールの割り当てを使って、クラスターでの認可のチェックを制御できます。 これにより、Azure でのロールの割り当てのすべてのベネフィット (Azure リソースに対する Azure RBAC のすべての変更を示すアクティビティ ログなど) を、Azure Arc 対応 Kubernetes クラスターで使用できるようになります。

Architecture

Azure RBAC のアーキテクチャを示す図。

すべてのアクセス承認チェックを Azure の承認サービスにルーティングするために、Webhook サーバー (ガード) がクラスターにデプロイされます。

クラスターの apiserverWebhook トークン認証Webhook 承認を使用するように構成されています。これにより、TokenAccessReview および SubjectAccessReview 要求がガード Webhook サーバーにルーティングされます。 TokenAccessReview および SubjectAccessReview 要求は、apiserver に送信される Kubernetes リソースに対する要求によってトリガーされます。

ガードは、Azure の認可サービスに対して checkAccess 呼び出しを行い、要求元の Microsoft Entra エンティティが、目的のリソースにアクセスできるかどうかを確認します。

このアクセスを許可するロールをそのエンティティが持っている場合は、承認サービスからガードに allowed 応答が送信されます。 次に、ガードは apiserverallowed 応答を送信し、呼び出し元のエンティティが、要求された Kubernetes リソースにアクセスできるようにします。

このアクセスを許可するロールをエンティティが持っていない場合は、承認サービスからガードに denied 応答が送信されます。 ガードは apiserverdenied 応答を送信し、呼び出し元のエンティティに対し、要求されたリソースへの 403 (許可されていません) エラーを発出します。

次のステップ