VM に最適な認証タイプは？会話

※この投稿は米国時間 2022 年 4 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

「VM に懐疑的な人」と「VM ファン」の対談をまとめたシリーズの「VM エンドツーエンド」のエピソードを公開しました。毎回、Brian、Carter、そして特別ゲストとともに、VM が Google の最も信頼できるプロダクトである理由、そして VM がクラウドで大規模に事業を展開する会社にどのような利益をもたらすかを探ります。ここでは、そのエピソードを紹介します。

Carter Morgan: 「VM エンドツーエンド」のエピソードにようこそ。この番組では、VM に懐疑的な人と VM ファンが VM に関するあらゆることを語り合います。Brian、ご参加ありがとうございます。

Brian Dorsey: よろしくお願いします。今日のトピックは何ですか？

Carter: もちろん、ID についてです。それから、アクセスについても知りたいです。なぜ SSH ですべてに接続できないのでしょうか？それとも、接続できるのでしょうか？ぜひ教えてください。

Brian: わかりました。最初に私が質問に簡単に答えます。しかし、詳細をすべて把握しているわけではないので、ゲストを招待しています。まず、SSH 接続は可能です。VM はコンピュータです。SSH は鍵と連動しているので、鍵ペアを取得しており、そのトークンを所持していれば、公開鍵が設定されているマシンすべてに接続できます。そのためのシステムがある場合は、すべて自分で管理しても構いません。しかし、特に組織の規模が拡大すると数が増え、管理が非常に複雑になる可能性があります。そこで、Google の ID インフラストラクチャに鍵の作成を任せるという方法もあります。ここからは、Google の Identity and Access Management 担当、Emanuel に説明してもらいましょう。よろしくお願いします。

Emanuel Burgess: 非常にわかりやすい説明をありがとうございました。Carter、調子はどうですか？

Carter: 少し混乱しているので、私がつまずいている部分について Brian から説明してもらおうと思います。

Brian: では、Google Cloud の Identity and Access Management の概要について教えてください。

Emanuel: よい質問ですね。IAM とは何かという定義を復習しましょう。IAM は Identity and Access Management の略で、Google Cloud アカウントのどのリソースにアクセスできる人物を委任または制御するためのものです。

Carter: なるほど。リソースを所有する人や、リソースにアクセスできる人を制御できるということですね。それを設定するのは誰ですか？

Emanuel: まずはドメインを設定する必要があります。特権管理者という人がいて、その人が管理コンソールにアクセスしてドメインを設定します。ドメインが設定されると、組織が自動的に作成されます。この特権管理者というロールは、ユーザーの管理からグループの作成、多要素認証の設定まで、管理者ポータル内で何でも行うことができます。

Brian: 特権管理者とドメインについて理解しました。一番見慣れているのはプロジェクトなのですが、それらとどのようにつながっているのですか？

Emanuel: そうですね。ドメインは組織と 1 対 1 でマッピングされ、プロジェクトは組織の下にあるものです。組織は GCP アカウント内のルートノードと考えることができます。ルートノードを使うと、その下にプロジェクトやフォルダなどを持つことができ、プロジェクトにリソースを割り当てることもできます。

Carter: この階層構造を使ってさまざまなエリアにアクセスするのですね。

Emanuel: そのとおりです。

Carter: では、Google Cloud リソースにアクセスするためのスクリプトなどが必要な場合は、どうすればいいですか？

Emanuel: 外部のアプリケーションやワークロードを Google Cloud 内のリソースにアクセスさせたい場合、サービス アカウントというものを活用できます。

Carter: それは何ですか？

Emanuel: サービス アカウントは、Google Cloud 内で API を操作できる特別なアカウントだと思ってください。わかりやすく説明するために、ユーザー アカウントで考えてみましょう。私が Google Cloud にアクセスできるユーザーである場合、Chrome で Google Cloud ブラウザかウェブサイトにアクセスしてログインします。ユーザー名とパスワードを入力すると認証されます。認証が完了したら、割り当てられているグループに適用される権限またはロールを引き継ぎます。しかし、アプリケーションの場合はこれができません。アプリケーションは Google Chrome にアクセスしてログインすることができないため、Google Cloud 内の API とサービスを操作するためにサービス アカウントが必要になります。

Brian: なるほど、わかりました。だからリソースへのアクセスを付与する組織があるのですね。ユーザーの場合は、SSH で接続できる可能性があり、プログラムの場合は、サービス アカウントを介して他の API に接続できるのですね。プログラムにアクセスする方法は他にもありますか？

Emanuel: はい。サービス アカウントの他に、サービス アカウント キーがあります。はるか昔は、サービス アカウント キーを使って外部アプリケーションが Google Cloud のワークロードやリソースへアクセスできるようにしていました。しかし、サービス アカウント キーには問題がありました。Google Cloud のリソースを安全にビルドしようとするうえで、サービス アカウント キーが選択肢としてふさわしくない理由の一つは、有効期限がないことです。つまり、サービス アカウント キーが漏えいすると大問題につながるのです。理論上は、サービス アカウント キーにアクセスできる全員がサービス アカウントの権限を借用し、そのサービス アカウントに適用されるすべての API と機能にアクセスできます。それだけでなく、シークレット管理の問題も生じます。至るところに分散している鍵をどのように管理すればいいでしょうか？安全措置として、そしてサービス アカウント キーに関する不安を取り除くために、シークレット管理の戦略を組み立てる必要があります。

Carter: サービス アカウント キーのデメリットについて考えたことはありませんでした。はるか昔のもの、という言い方が良いですね。とても気に入りました。今の説明を聞いて少し疑問に思ったことがあります。サービス アカウントは Google Cloud 内のリソースに対して使われるようですが、Google Cloud の外部のサービスに対して認証したい場合はどうでしょう？Google で管理する方法はありますか？

Emanuel: はい。Google で管理できます。Terraform を使って Google Cloud 内にインフラストラクチャをビルドしている場合を考えましょう。はるか昔は、サービス アカウント キーを付与する必要がありました。Terraform を設定して、provider ブロックを作成し、サービス アカウント キーを付与します。そのサービス アカウント キーは Google Cloud 内のサービス アカウントの権限を借用します。これで機能しますが、この鍵を管理する必要があります。そこで、有効時間が短い認証情報を使うと、サービス アカウント キーの管理について悩む必要がなくなります。このように Terraform を使って Google Cloud でインフラストラクチャをビルドしたい場合、有効時間が短い認証情報を使って Google Cloud で Terraform を認証できます。

Carter: 有効時間が短いトークンに対する熱意が伝わってきます。

Emanuel: はい、大好きですから。

Carter: 非常に便利ですからね。ありがとうございました。では、先ほどの質問に戻ります。外部ワークロードに対してこうしたセキュリティを確保したり、アクセスしたりすることはできますか？

Emanuel: はい、できます。Workload Identity 連携という機能があります。独自の ID プロバイダを持つ Google Cloud 外部のワークロードがある場合、有効期間の短いトークンを使用して認証できます。アプリケーションが独自の ID プロバイダから認証情報を取得し、この認証情報が Google のトークン サービスに渡されます。Google のトークン サービスがこの認証情報を取得し、有効期限の短い外部トークンを作成して外部アプリケーションに渡します。すると、外部アプリケーションが Google Cloud 内のサービス アカウントにアクセスし、権限を借用できるようになります。

Brian: なるほど。さまざまな種類のアクセスがありますね。ユーザー アカウント、サービス アカウント、有効期限の短いトークン、ワークロードなど、特定の状況でどれを使用するべきか、判断方法を教えてください。

Emanuel: よい質問ですね。状況によって異なります。もう一度 Terraform で説明しましょう。私はユーザーで、ID プロバイダを持たない外部アプリケーションがあるとします。この場合、有効期限の短い認証情報を使ってこの外部アプリケーションを認証し、Google Cloud 内のサービス アカウントの権限を借用できます。ID プロバイダを持つワークロードの場合はどうでしょう。たとえば、AWS を ID プロバイダとして使用している、オンプレミスの Active Directory または Azure Active Directory を使用している、Okta を使用している場合です。この場合は、Workload Identity 連携を使うのが最適です。なぜなら、鍵を動的に生成できるため、gcloud コマンドラインなどの方法で手動で鍵を生成する必要がないからです。

Brian: これらすべてが IAM を活用しているのですね。すばらしい。一貫した方法で管理できるなんて、最高ですね。IAM についてもっと知りたい場合は、どこから始めればいいですか？

Emanuel: IAM、セキュリティのベスト プラクティス、Workload Identity 連携、有効期限の短い認証情報についての詳細は、cloud.google.com/iam/docs で確認できます。

Carter: わかりました。Emanuel、ご参加ありがとうございました。今日まで有効期限の短いトークンと Workload Identity 連携を聞いたことはありませんでしたし、サービス アカウントや有効期限の長い静的な鍵のデメリットについて考えたのも初めてでした。話をまとめると、IAM を使うのがベスト プラクティスだということになりますか？

Emanuel: そのとおりです。大規模な組織で働いている場合、組織を利用して IAM を設定するのが最適です。Google Cloud を試してみたい場合は個人の Gmail アカウントでもサインアップできますが、組織のメリットすべてを活用することはできません。そのため、組織の規模が大きい場合は Google Cloud アカウントで IAM を呼び出すのが最良の方法です。

Carter: なるほど。今回は以上になります。今日はワークロード、連携、有効期限の短いトークンなどについて、たくさんのことを学びました。Brian、Emanuel を招待してくれてありがとうございました。とても助かりました。

Brian: Emanuel、ありがとうございました。素晴らしい内容でした。

Emanuel: お二人に感謝します。こちらこそ機会をいただきありがとうございました。

Carter: いいえ。今回は、有効期限の短いトークンと Workload 連携について理解を深めました。ご自宅で視聴している方は、学んだことをコメントに書いて教えてください。ありがとうございました。VM エンドツーエンドの本エピソードは以上です。

今回のゲスト、Google デベロッパー リレーション エンジニアの Emanuel Burgess に感謝します。