本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「グロ管？所有者？Azureの権限回りをざっくり理解する」を再編集したものです。
Azureの権限回り、もう少し具体的に言うと「認可」の領域は、慣れないうちはよく分からないと思います。
そこで、初めてAzureを触る人向けに、ざっくりとした認識の共有をしたいと思います。この資料だけで納得せずに、深く調べるための手がかりくらいに使っていただけると幸いです。
基礎知識：認証と認可
「認証」とは、「その人が誰なのか？」を確認することです。
「認可」とは、「何らかの操作の権限」を与えることです。
Azureにおけるテナントとサブスクリプション
テナントとは、誤解を恐れず書けば、「お客様を管理する単位」です。
技術者視点では、Azure Active Directory＝テナント、みたいな認識でも良いのかもしれません。テナントでは主に、「認証」に関わる設定を行ないます。例えば下記です。
・ユーザーの追加削除等の管理
・サービスプリンシパルの追加削除等の管理
サブスクリプションはこちらも誤解を恐れず書けば、「Azureの課金の単位」です。サブスクリプションの中にAzureリソースを作成し、課金情報が集約されます。権限の観点では主に「認可」に関わる設定を行ないます。例えば下記です。
・Azureリソースの作成削除を実施する権限の管理
・Azureリソースのアクセス権限を設定する権限の管理
テナントにおける認可
テナントでも「認可」の概念が存在します。
何も権限を持たないユーザーは「テナントに所属している」という状態以外に意味を持たないと思って大丈夫です。
つまり、テナントにほかのユーザーを追加したり、サービスプリンシパルを作成したりすることができません。
テナントで一番強い権限は「グローバル管理者」です。
これを持つと、Azure ADに対する全ての操作をする権限が与えられると思ってください。この「全て」が、正直分からないです、怖いです。
どうしても「サービスプリンシパルが作成できる」とか、「ほかのメンバーをテナントに招待できる」とかいう便利な側面だけ見てしまいがちですが、「ユーザーを削除する」「サービスプリンシパルを削除する」といった慎重な作業を要する権限でもあります。なので、できるだけ私はグローバル管理者にはなりたくありません。そうはいかないんですけどね。。
このほかに「アプリケーション管理者」という権限も良く使います。こちらはざっくりいうと、サービスプリンシパルの作成に必要な権限です。ユーザーの管理はできないので、ちょっとだけ安全ですね。
ここでちょっと注意ですが、テナントの権限を持っているだけでは、サブスクリプションの権限は持てません。
テナントでグローバル管理者になっていても、サブスクリプションの権限を持っていなければAzureリソースの作成はできません。テナントとサブスクリプションは階層構造になっているように感じますが、そういうわけでもないんです。ここは要注意です。
サブスクリプションにおける認可
サブスクリプションの認可は、下記の単位で設定可能です。
・サブスクリプション単位
・リソースグループ単位
・リソース単位
それぞれの画面で「アクセス制御（IAM）」のビューで設定可能です。以降はIAM設定と呼びましょうか。もちろんコマンドライン等でもできます。
サブスクリプションの認可は、主に下記のあたりをよく使います。
| 権限名 （日本語） |
権限名 （英語） |
やれること |
|---|---|---|
| 所有者 | Owner | すべての操作（リソース作成削除とリソースへのIAM設定） |
| 共同作成者 | Contributor | リソース作成削除できるが、IAM設定は不可 |
| 閲覧者 | Reader | リソースの設定値等の参照は可能だが、作成削除は不可 |
あとよくあるパターンとして「ストレージ BLOB データ共同作成者」も共同作成者と組み合わせて使いますね。
サブスクリプションに設定してしまえば楽ですが、複雑な構成の場合はリソースグループ単位での権限設定なども検討すると良いです。
複数テナントの権限を付与されているときの恐怖
上記でざっくり理解して、「じゃあ理解したんで、全部AADのグローバル管理者と所有者権限くださいよ、たぶんミスしないので」と思った方もいらっしゃるかもしれませんが、もうちょっと読んでほしいです。
例えば、az cliを使ってリソース操作する場合、az cliの認証情報はPC再起動等しても保持されています。このため、az loginやaz account setをやり忘れると、想定していないサブスクリプションの環境を操作してしまう可能性があります。
リソースを作成して余計な課金を発生させたり、リソースを削除して復旧不可能な状態に陥らせたり、とっても怖いです。
上記はAzureリソース命名をサブスクリプションごとに変えていれば多少回避できますが、特にヤバいのはAKS操作です。こちらもaz aks get-credentials してしまえばKubernetesクラスタにアクセスする情報がずっと保持されます。
kubectlの操作対象はAzureリソース名にほぼ関係ないので、同じアプリを乗せていれば同じコマンドが通ってしまう可能性が高いです。相当慎重な操作が必要になってきます。
まとめ
非常に大雑把にAzure権限についてご説明しました。私は日々恐怖と闘いながら仕事をしている状態です。
とはいえ、az loginをサボるなどの「手を抜かない」ことが基本的な対策になってきます。この緊張感を分かち合える人には権限を渡していきたいな、と思いながら仕事をしています。
松枝 宏樹／FIXER
名古屋事業所所属。
得意分野はC#、ASP.NET、terraformなど。
最近はdocker、K8s関連を勉強中。
