buchizoそんなわけでAKSのTipsその2です。今回はRBACメインで。Control(ロールベースのアクセス制御)の略ですね。Azureには各リソースに対してRBACの仕組みがあります。同様にk8sにもRBACの仕組みがあります。概念的にはだいたい同じでk8sのAPIを使用する際にユーザーのロールに応じてアクセス可否を判断することができます。Connect)との認証連携とk8sでのRBACについてのメモになります。k8sで利用可能な他の認証方式(証明書認証とか)や認可の仕組みについては割愛します。以下のドキュメント参照で。Authorizationk8s側は上述のドキュメントに詳しく記載されています。RBAC基本的には以下のドキュメントをなぞる形になります。ADにアプリケーションを2つ登録しておく必要があります。(MSのドキュメント通り)1つはAKSサーバーが使用するアプリケーション、もう1つはkubectlなどクライアントで使用するアプリケーションになります。Permissionsをちゃんとしておきましょう。利用するAPIに管理者の承認が必要なものがあるので、管理者側で許可を与えて置く必要があります。Consent使ってもいいのですが大変なのでポータルのボタンぽちーで済むのでいいですね。この操作はテナント管理者でないとダメなので注意しましょう。Permissionsが成功することを確認しておいてください。クライアント側のほうはユーザー側で対話操作で承諾できる(はず)のでしなくてもいいですが、しておくと面倒がないかもしれません。CLIに渡してAKSを作成すればRBACが有効になります。作成後、k8sに対して利用するユーザーやグループに許可を与えていくことになります。引数を付けて接続情報を取得します。applyなどしましょう。ID(GUID)を指定するようにします。get-credentialsして(admin引数なしで)kubectlでk8sに接続するとデバイス認証のURLが表示されるので認証します。問題なければ正しく結果が返ってきます。PermissionsやYamlを確認してください。MS公式のドキュメントのYamlだとcluster-adminロールなので、本番適用したい場合は適切なロールを割り当ててください。(この辺は完全にk8sの世界)仕組みとか認証・認可周りの説明が面倒くさい(うさんくさい)ですが、ざっくりまとめるとこんな感じかと。※あくまでイメージ最初にAKSにアクセスしてkubectlなどで使用する接続情報を取得する必要があります。この時はAzure側のRBACの仕組みが入るので適切な権限を持っているユーザーのみ取得できます。Server)にアクセスする際ですが、k8sのRBACが有効だとこの時点で認証が必要となります。get-credentialsで取得した中身はマスターノードの情報など最低限のものなので、ユーザーに関する情報は含まれていないのでk8s側は認証されてないものとして扱います。認証プロバイダーがAzureに設定されてるようなので、kubectlはデバイスログインに必要なURLとコードを返してくれます。.kube/configファイルにアクセストークンなどが追加されます。ADのアプリケーションはk8sのサーバー用アプリケーションへのアクセス権を持っています。k8sはこのクライアント用アプリケーションへのアクセスがIdPより許可(認可)されればOK(許可されたトークンが来ればOK)という感じですね。AD)からグループ情報などを取得してグループに割り当てられたロールのチェックとかしてると思われます(推測)。字ばっかりですが、この辺のフローはOAuth2.0と一緒なので察してください。k8s側で対象操作に権限がない場合などは以下のようなエラーになります。get-credentialsだけ許可するようなことをしたいと考えるはずです。今時点でAzure上に適切なロールがなく、AKSにReaderなどのロールで割り当てても以下のように権限不足でエラーになります。'/subscriptions/xxxxxxx/resourceGroups/xxxx/providers/Microsoft.ContainerService/managedClusters/xxxx/accessProfiles/clusterUser'.今時点での解決策はカスタムロールを定義して必要な権限を付与してあげる方法があります。カスタムロールの例はこんな感じ。カスタムロールを追加後、AKSのIAMでロールを割り当てると問題なくget-credentialsできるようになります。※ただget-credentialsで取得できる中身は大したことがない(誰でも同じような情報になる)のと、後述するadmin権限も取れてしまうので今時点のロール定義だとこの方法での運用は危ないでしょう。ファイルを共有するなりする方法がベターな気がします。した後の初期状態は以下のようになります。ADのテナントID)がわかれば生成できます。引数を付けた場合、管理者権限となります。configに追加されます。ちなみにRBAC無しk8sだとget-credentialsで取得できる情報はadmin引数の有無に関係なく同じ(管理者権限の情報)になります。get-credentialsした後、kubectlなどで実際にアクセス/認証するとconfigにアクセストークンなどが追加されます。JWTなトークンなので、そのままBearerトークンとして使えますしデコードするとちゃんと中身が見れます。CLI経由かARMテンプレート経由で作成時のみRBACを有効化できます(つまり後から有効化できません)。AzureポータルからAKS作成する際にRBAC有効にするかどうかのフラグがありますが、有効にしてもプロパティのenableRBACがtrueにセットされるだけでaadProfileなどは作成されません。Explorerなどで追加しようとしてもエラーになります。(既存AKSに対しての更新に対応してくれることを期待したい)ARMテンプレートでAKS作成する際は上図のようにaadProfileを構成すれば大丈夫と思います。browse)やマスターノードのk8sダッシュボードへアクセスすると、権限がなくてエラーが表示されます。サービスアカウント権限で何でも誰でも見れてもいいので回避したい場合はClusterRoleBindingを使ってkube-system:kubernetes-dashboardサービスアカウントにcluster-adminを割り当てます。アクセスすればダッシュボードが見えると思います。表示されるログインフォームに取得した(.kube/configなどに記載されている)アクセストークンを使ってログインすれば権限に応じて見れると思います。Edgeだとダメだった。その他注意点k8sのRBACは今のところ対象テナントのユーザー・グループのみとなります。B2Cなどにも対応してほしいところですが...k8sのAuthorizationモジュールでRBACを使う際の連携先はAzureなどだと簡単ですが独自OIDCだと面倒くさそうです。1.8のアクセス制御について。あとDashboard。update字ばっかりで疲れましたね。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。免責事項このBlogおよびコミュニティにおける発言やコメントは、当方の所属する会社・団体の正式な見解またはコメントではありません。Blog.%d人のブロガーが「いいね」をつけました。