Google Cloud：アクセス権の設定方法を解説（IAMの設定）
内容
今回の内容はGoogle Cloudを組織で運用していく上でどのようにアクセス権を管理していくのか、について下記公式ドキュメントの内容に沿って解説していきます。
初めに
まずは、Google CloudのIAM周りの整理から始めてみましょう。
Google Cloudの組織階層の中身については、組織,フォルダ,プロジェクト,リソースといった形式で形作られていますが、主にIAMポリシーを割り当てて、権限を管理する単位はプロジェクトまでになる事が多いです（リソースによっては個別に割り当てることは可能です）。
また、フォルダはプロジェクトを束ねるグループというイメージになりますので、例えば財務部門と称したフォルダを作成し、その下に請求専用のプロジェクトを配置して、フォルダには請求関連のIAMポリシーをグループ単位で与えるという事ができます（グループはユーザーを束ねた集合体です）。
もしピンとこない場合、この辺りの基礎知識は過去の記事でも解説しているので、ちらっと拝見頂ければ幸いです。
Google Cloud：IAMのイメージについてざっくりまとめてみた
Google Cloud：IdPとアカウント周りについてまとめた
# AKIBA.SaaS「Google Cloud：組織作成の基礎」というテーマで登壇しました
必要なロール
今回の操作を行うにはスコープごとに特定の権限が必要になります（権限については下記黄色の枠内を参照）。
例えば、Aプロジェクトのみで権限の管理を行う場合には、Aプロジェクトに権限を含んだポリシーを与えなければなりません。
さらに、フォルダや組織単位で権限の管理を行う場合には、権限を含んだポリシーをフォルダや組織単位で適応させます。
必要なロールは、そのスコープ（組織,フォルダ,プロジェクト）でポリシーとして設定してください。
→プロジェクトIAM管理者（roles/resourcemanager.projectIamAdmin）
【フォルダへのアクセスを管理】
→フォルダ管理者（roles/resourcemanager.folderAdmin）
【プロジェクト,フォルダ,組織へのアクセスを管理する】
→組織管理者（roles/resourcemanager.organizationAdmin）
【ほぼすべてのリソースへのアクセスを管理する】
→セキュリティ管理者（roles/iam.securityAdmin）
プロジェクトのアクセス権を取得
まず、単一のプロジェクトにアクセスできるユーザーを確認するために、リソースの許可ポリシーを取得します。
そして今回はgcloudコマンドを用いてCloudShellで実行していきます。
【コマンド解説】
それぞれ[ ]内が個別のコマンドにあたりますので、選択して、スコープ（組織,フォルダ,プロジェクト,ユーザー,IAMロール）やファイル形式を絞ります。
①gcloud [projects]
②get-iam-policy [プロジェクトID→（文字列ID）]
③--format=[json]
④＞ [~/policy.json]
※考慮事項
①projectsをresource-manager folders や organizationsに置き換えてスコープを変更します。
②フォルダIDや組織IDの場合、数字IDを記述します。
③json以外に、yamlも指定できます。
④ファイルの出力先のディレクトリを指定します。（今回はルート直下のユーザーのホームディレクトリを指定しました）
実際に上記のget-iam-policyコマンドを実行したところ、CloudShellのホームディレクトリにpolicy.jsonが出来上がっていました。
policy.json README-cloudshell.txt
ちなみにプロジェクトのID（文字列）、フォルダと組織のID（数字）の違いについては、下記画像のようにコンソールの上部のプロジェクトの名前が表示されている横にある▼を押下すると確認できます。
（組織IDもあるため、中身のIDの画像は貼っておりません。）
ロールの操作
ロールの操作についても、gcloudコマンドで行います。
また、ポリシーの変更は2分以内に有効になり、システム全体に変更が反映されるまでに7分以上かかることがあります。
プロジェクトのオーナーロール（roles/owner）を組織外のユーザーに付与するには、gcloud CLIではなく、Google Cloud コンソールを使用する必要があります。プロジェクトが組織の一部でない場合は、Google Cloudコンソールを使用してオーナーのロールを付与する必要があります。
ロールの付与
add-iam-policy-bindingを使います。
プロジェクト[muroi-＊＊＊＊＊]のユーザー[muroi-＊＊＊＊＊@gmail.com]に[プロジェクトIAM管理者ロール]を付与する場合。
add-iam-policy-binding muroi-＊＊＊＊＊ \
--member=user:muroi.＊＊＊＊＊@gmail.com
--role=roles/resourcemanager.projectIamAdmin
【コマンド解説】
それぞれ[ ]内が個別のコマンドにあたりますので、選択して、スコープ（組織,フォルダ,プロジェクト,ユーザー,IAMロール）を絞ります。
先程のプロジェクトのアクセス権を取得にて組織やフォルダの場合の説明を入れているので、今回はプロジェクトの場合のみの解説にします。
・gcloud [projects→（スコープを指定）]
・add-iam-policy-binding [muroi-＊＊＊＊＊→（プロジェクトIDを指定）] \
・--member=user:[muroi.＊＊＊＊＊@gmail.com→（メールアドレスを指定）]
・--role=roles/[resourcemanager.projectIamAdmin→（今回はプロジェクトのみのIAM管理者を指定）]
ロールの取り消し
remove-iam-policy-bindingを使います。
プロジェクト[muroi-＊＊＊＊＊]のユーザー[muroi＊＊＊＊＊@gmail.com]に[プロジェクトIAM管理者ロール]を取り消す場合。
remove-iam-policy-binding muroi-＊＊＊＊＊ \
--member=user:muroi.＊＊＊＊＊@gmail.com
--role=roles/resourcemanager.projectIamAdmin
【コマンド解説】
こちらについては解説不要かと思います。先程のロールの付与の、add-iam-policy-bindingのコマンドをremove-iam-policy-bindingに変更しただけです。
コマンドのいい所は、この様に異なる操作でも一箇所を変えるだけでコマンドの使い回しが可能であることです。
GUIのコンソール操作では、毎回同じ段取りを手作業で行わなければならないため、工数がより多くなります。
複数ロールの付与
複数の場合は少し手順が異なります。
・許可ポリシーをテキストエディタまたはプログラムで編集し、ロールとユーザーの追加/削除を行います。
・setIamPolicy()を呼び出して、更新された許可ポリシーを作成します。
上記の様に、1番最初に行ったプロジェクトのアクセス権を取得をして、ホームディレクトリに作成されたjsonファイルを書き換えて、再度アップロードをするといった形になります。
複数ユーザーへのロール付与
先程取得した、policy.jsonファイルに次の様な操作をします。
（jsonファイル内の行を一部抜粋しました）
{
"members": [
"user:muroi.*****@gamil.com"
"user:tanaka.*****@gamil.com"
"user:nakata.*****@gamil.com"
],
"role": "projects/muroi-yasunari/roles/customcudroles"
},
【コマンド解説】
"members": [ ]の中にある元々ロールが付与されている"user:muroi.@gamil.com"の下に、"user:tanaka.@gamil.com"と"user:nakata.@gamil.com"を追加しました。
"role": "projects/muroi-＊＊＊＊＊/roles/customcudroles"←こちらはmuroi-＊＊＊＊＊というプロジェクト内でcustomcudrolesを付与しましたよ、ということになります。
この要領で複数のユーザーを既存のロールへ追加できますし、さらに新しいロールを記述して作成することもできます。⇒（"role": "roles/compute.storageAdmin",の部分も新しく追加する）
複数ロールの削除
【コマンド解説】
削除についても付与とは逆に、取得したファイルの"members"または"role"を削除することで実施できます。
付与よりも、消せばいいだけなので操作自体は簡単かもしれません。
ポリシーを設定
これまでは、ユーザーにロールを割り当てることにより、ポリシーを作成してきました。
ポリシーを作成しただけでは権限を割り当てて実際にGoogle Cloudを操作することができません。
リソース階層にポリシーを設定して行きましょう。
setIamPolicy()を使います。
policy.jsonに保存されている許可ポリシーをプロジェクトであるmuroi-＊＊＊＊＊の許可ポリシーとして設定します。
【コマンド解説】
こちらについての解説は、冒頭のプロジェクトのアクセス権を取得を参考にしてください。
get-iam-policyをset-iam-policyに変更するだけです。
まとめ
今回はgcloudコマンドとjsonファイルを使用して、ユーザーにロールを割り当てて、さらにプロジェクトに作成したポリシーを設定して行きました。
各コマンドの説明については何回か読み込むと理解が進むと思います。
また、AWSやAzureとはユーザーの管理方法やロール、ポリシーといった同じ言葉でも意味や概念が異なるため、随時そのクラウドにあった知識に切り替えて理解をしなければなりません。
最後に
前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。
【筋トレを継続させるメンタルの考え方】
ズバリ、筋トレをするメリットを考えるだけです。
私の場合はもはや癖で、毎日やってしまいますが、根本は筋トレによるメリットが大きいのを知っているため継続できています。
おそらく続かない方は本当に存在する筋トレによるメリットを十分に理解していないからだと、強く思います。
でなければ、スポーツ選手でもないし、体育の先生でもないし、ボディビルダーでもないのだから、続ける意味などどこにもありません。
何回も言います。まずは、筋トレによる自分へのメリットを考えてください。それは人それぞれ違いますし、やっていくうちに変化したりもします。
私が筋トレをやることで得られるメリットを答えるとしたら、身体に関わること全てが良くなると言います（有酸素運動も含む場合）。
この意味はまたどこかで、詳細に根拠に基づいて説明できればなと思います。
