Cloud IAM の新機能で Compute Engine リソースをきめ細かく管理
Google Cloud Japan Team
※この投稿は米国時間 2018 年 10 月 16 日に Google Cloud blog に投稿されたものの抄訳です。
私たち Google は先ごろ、Google Compute Engine のセキュリティとアクセス制御をきめ細かく管理できるようにすることを目的に、resource-level IAM と IAM Conditions の 2 つの Cloud IAM 機能を導入しました。resource-level IAM は、VM インスタンスやディスクといった個々のリソースに IAM ポリシーを設定できるようにします。また IAM Conditions は、リソース名プレフィックス、リクエストの属性（IP、デバイスなど）、時間帯など事前に定義された条件に基づいてアクセスを制御する機能です。
Compute Engine におけるリソース レベルのアクセス管理
Google Cloud Next '18 で発表された Compute Engine resource-level IAM は、VM やディスク、イメージ、その他の Compute Engine リソースのそれぞれに IAM ポリシーを適用し、環境をきめ細かく柔軟に管理できるようにするものです。次の図は、Google Cloud Platform（GCP）内の階層化されたリソース モデルを示しています。
お客様は、組織（上図の Organization）、フォルダ（同 Folders）、プロジェクト（同 Projects）のレベルで IAM ポリシーを指定でき、それらのポリシーは下位の階層に継承されるため、効果的かつ効率的にアクセス権を付与できます。上図を例にとると、「Dept X」に属する Elizabeth にインスタンス管理者の役割を与える場合は、フォルダ（Dept X）レベルで IAM ポリシーを指定します。すると、Elizabeth は、Dept X フォルダに属するすべてのプロジェクトのインスタンスを管理できるようになります。また、「Dev/test project」で共同作業を行っているデベロッパーのグループを対象に、同プロジェクトへの強力な権限を認めつつ、左隣の「Production project」へのアクセス権を制限することも可能です。
では、もっときめ細かく IAM ポリシーを指定したいときはどうすればよいのでしょうか。たとえば、テスターのグループを対象に、「Project A」のベータ イメージをテストできるようにしつつ、同じプロジェクトに属する機密性の高いイメージやリソースへのアクセスを制限するといった場合です。プロジェクト以上のレベルでしかアクセス権限を設定できなければ、テスター グループに対しては、プロジェクト内のすべてのイメージへのアクセスを認めるか、あるいは禁止するかの一択になります。この例のように機密性の高いイメージへのアクセスを制限するには、従来はベータ イメージだけを集めた別のプロジェクトを作り、そのプロジェクトの compute.imageUser ロールをテスター グループに付与する必要がありました。これではいかにも不便です。
Compute Engine resource-level IAM は、こうした課題を解決します。これを導入すれば、過剰な共有や不自然な回避策をとることなく、特定のベータ イメージに compute.imageUser ロールを簡単に付与できます。権限の設定例を見てみましょう。
gcloud beta images set-iam-policy betaTestImage1 betaImagePolicy.json
ここで使われている betaImagePolicy.json ファイルは次のように定義されています。
こうした新しい resource-level IAM ポリシーで実現できるユース ケースは他にもたくさんあります。たとえば、トラブルシューティングのために同僚や共同作業者に対してプロジェクト内の特定 VM へのアクセス権を与えたり、社内のすべての承認ユーザーとディスク イメージを共有して全員が同じバージョンのイメージにアクセスできるようにしたりすることが可能です。
Compute Engine resource-level IAM は、API、CLI、Developer Console を通じてベータ版を利用できます。詳細はドキュメントをご覧ください。
IAM Conditions によるアクセス管理
resource-level IAM ポリシーを設定するだけでなく、アクセスできる条件を定義して適用したい場合もあります。たとえば、電話サポート チームのメンバーにインスタンス管理者の役割を与えたいときに、最小権限の原則に従ってアクセスを電話の受付時間だけに制限し、不慮の事故を防ぐような場合です。IAM Conditions の導入により、アクセス権の範囲をきめ細かい条件のもとで制御できるようになります。このときのポリシーは、条件 Z が満たされれば Y に役割 X を与えるという形で指定できます。Google Cloud Next '18 で紹介したように、現在はベースとなるポリシーに加えて、リソース名プレフィックス、アクセス レベル、日時という 3 種類の条件属性を使ってアクセス権限を強力に管理できます。以下、これら 3 つについて見ていきましょう。
1. リソース名プレフィックス属性
この属性を使用すると、リソース名のプレフィックス（接頭辞）が条件を満たすときに限り、IAM ポリシーが適用されるようになります。よく見られるユース ケースとしては、デベロッパー向けのサンドボックスがあります。管理上のオーバーヘッドを減らしてネットワークのパフォーマンスを最適化するため、デベロッパーが同じプロジェクトでプロトタイプを構築できるようにするわけです。compute.instanceAdmin.v1 ロールを個々のデベロッパーに付与する IAM ポリシーに対し、接頭辞にデベロッパー名が含まれている名前のリソースだけにアクセスを制限するという条件を挿入することで、このようなサンドボックスを作成します。次に示すのは、接頭辞が dev1 になっている VM とディスクを操作するときに限り、リード デベロッパーの dev1 に instanceAdmin ロールを与えるポリシーの例です。*注意 : compute.instances, などのリソース タイプの形式は、Cloud IAM Conditions の将来のリリースで変更される可能性があります。
リソース名プレフィックス属性を使ってアクセス範囲を限定することで、デベロッパーは他のリソースに影響を与えることなく、自分の担当リソースの範囲で開発を進めることができます。
2. アクセス レベル属性
アクセス レベル属性を使用すれば、IP アドレスやデバイス ステータスなどのリクエストの属性に基づいて、そのリクエストにアクセスを認めるかどうかを判断できます。
アクセス レベル属性で定義できる条件は、たとえば「ソース VM インスタンスが、会社が許可した最新の OS イメージを実行している場合のみ、サービス アカウントからのリクエストを認める」とか、「社内 VPN 経由のリクエストに限り、インスタンス状態を操作するためのリモート リクエストを認める」などです。
なお現時点では、アクセス レベル属性は Compute Engine のアルファ API でのみ使用可能です。
3. 日時属性
日時属性には、IAM ポリシーの開始日と終了日、および時間帯を指定します。たとえば、「Jane が電話対応している間に限り、彼女に Stackdriver ログ閲覧の役割を許可する」とか、「ジョンは、緊急時の場合のみ、この本番プロジェクトで使用する計算リソースの管理者になる」といった指定が可能です。IAM Conditions により、組織のクラウド コンピューティング環境をきめ細かく柔軟に保護できます。なお、IAM Conditions ではプライベート ベータ テスターを募集していますので、関心のある方はこちらからサインアップしてください。新しい IAM Conditions の機能をぜひお試しください。
- By Sophia Yang, Product Manager, Google Compute Engine and Meiyuan Zhao, Staff Software Engineer, Cloud IAM
