GCP の IAM をおさらいしよう
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 6日目の記事です。
TL;DR
本記事ではGoogle Cloud Platform (GCP) での ユーザーや権限を管理する IAM について整理していきます。
はじめに
クラウドを使う上で、ユーザー管理や権限管理は重要ですよね。GCP を使う際に、どのようにユーザー管理できるのか、権限管理や認証を整理してみようと思います。GCP では権限管理を Identity and Access Management（ IAM ）というもので管理しています。IAMでは、誰が、どのような操作を、何に対して行えるかというものを定義・管理します。これによりアカウントの追加・削除や権限付与がシンプルになり、管理が容易になります。
IAMのユーザーと権限
GCP で利用できるアカウント
GCP で利用できるアカウントには、Google アカウントや、Google アカウントを束ねた Google グループ、またサービスアカウントといったものがあります。
１つ目が、個人利用の Google アカウント。こちらはいわゆる「gmail アカウント」となります。また知らない人も多いのですが、既存の会社ドメインのメールアドレスでも「個人利用の Google アカウント」が取得できます。この場合、gmail 機能は利用できません。
２つ目が、企業管理のユーザーアカウントです。こちらは会社で G Suite を導入している場合、そのユーザをそのまま利用することができます。取引先など、社外のユーザーがGCP環境にアクセスする場合もあるかもしれません。そのときはCloud Identity を利用して、ユーザーを管理することができます。
私は組織で GCP を利用する場合には、企業管理のユーザーを使うようにおすすめしているのですが、それは以下のようなメリットがあるためです。
- Active Directoryとの連携
- ２要素認証の有効化
- SAML対応
企業管理のユーザーを使う際に、ドメイン認証を行う必要があるのですが、ドメイン認証を行うことで、技術サポートに問い合わせができたり、組織ポリシーを適用したりといろいろなメリットがあります。
人以外が使うアカウントとして、サービスアカウントがあります。こちらは例えば GCP のAPI を VM instance などから利用する場合に必要になってきます。
付与できる操作の権限
GCP では権限は全て API で管理されており、サービス名、リソース、動詞という命名規則をもって定義されています。 基本的にはサービスの動作と API は一対一の関係にあります。
例えば、GCEであれば、
compute.instances.delete
compute.instances.get
compute.instances.list
compute.instances.setMachineType
compute.instances.start
compute.instances.stopといった形です。���かし、これらを一��一つ権限付与していくのは大変なので、特定の操作でまとめて付与できるのが、役割、となります。
役割は事前定義されたものや、カスタムで細かく設定したものを付与する事ができますが、あまり細かく設定すると、管理面で煩雑さが増してしまうので、事前定義されたものでまにあうのであれば、そちらの利用をおすすめします。
役割を付与する際に、おすすめしているのがGoogleグループに役割を付与する方法です。これにより、グループの管理をするだけでプロジェクトやリソースにアクセスできるユーザーを管理できます。
権限の対象
権限の対象は、組織 / フォルダ、プロジェクトに設定できます。一部のサービスリソース、請求先アカウントは個別に、さらに権限を設定していくことができます。
プロジェクト、もしくはフォルダに設定していくケースが多いかと思いますが、GCP のリソースを組織で利用する場合は、こちらの図のように、階層構造を作ることができるのですが、権限を継承するようになっています。
したがって上位で設定された権限は、下位のリソースで剥奪することができません。例えば、サンドボックスフォルダに対して、全デベロッパーがプロジェクト作成権限を持つことで自由に検証をする環境を整えておくことができます。また部署ごとのフォルダ配下し、管理者のみプロジェクトを作成することができる、といった運用にすることも可能です。
GCP の利用料は請求アカウントに請求がされるのですが、請求アカウントに関しても個別の権限の付与ができます。そのため経理の管理者とプロジェクトの管理者を切り分けることが可能です。こちらに例がまとまっていますので、参考にしてみてください。
組織利用の際のフォルダ戦略
組織で利用する際、「どのようにフォルダを構成するか」はよく悩む問題かと思います。組織の中で、権限を移譲できる単位で分けましょう、とご案内していますが、いくつかのパターンがありますので、それも紹介させてください。障害時の影���範囲を限定するため、基本的に本番環境と開発環境のプロジェクトは分けるようにしましょう。
環境で分ける
開発環境と本番環境などでフォルダを構成するパターンです。本番環境と開発環境は、利用する人・チームの権限が分かれることが多いと思いますので、権限管理がやりやすいメリットがあります。
機能ごとに分ける
組織や開発スタイルがマイクロサービスになっている場合は、機能ごとに構成するのが良いかも知れません。この場合、機能を開発するチームが開発環境・本番環境を利用できる方が、生産効率はあがりそうです。
チームで分ける
組織が大きくなってきてチームの中でも更に権限が分散する必要がある場合は、チーム単位で構成することもよいでしょう。この場合コストもフォルダごとに参照でき、わかりやすいです。その配下に上記のような環境ごと、機能ごと、の構成を追加していくことも可能です。
またフォルダには以下のような制限があります。リソース設計の際に参考にしてみてください。
- フォルダのネストレベルは 4 つまで。
- 親フォルダ内に作成できるフォルダは 100 個まで
- フォルダの表示名は、階層内の同じレベルでユニーク
ちなみに
現在 プライベートベータ の IAM Conditions を利用すると、どのような条件下で実行できるか、という更に細かい設定が可能になります。たとえば会社IPアドレスからのアクセスは管理者権限、それ以外からのアクセスの場合は閲覧者権限で操作を制限するといったことが可能です。
さいごに
本記事では IAM に関して概要を説明してきました。少しでも権限管理・フォルダ設計など、役に立ちましたら幸いです。今年の GCP 環境の権限整理は今年のうちに。
明日2019–12–07は Kazuu さんによる”Cloud Run が GA になったから改めて色々見てみる"です。乞うご期待を!!
