権限付与から見たAWSとGCPの違い
業務都合で GCP を使う機会が増えたけど、サービスアカウントってなんかわかりにくいなぁってずっと思ってた。でもそれは AWS の考え方を引きずっていたからだと気づいたので、両者の権限付与について違いをまとめる。ざっくりしたまとめなので、詳細な仕様は公式を参照。
権限そのものの考え方は大体同じ
Policy: 権限そのもの。基本的にサービスごとのAPIに対する権限と考える。細かいことを書き出すときりがないので割愛。
Role: 権限をグループ化したもの。細か(略
PolicyやRoleの付与対象
違いは一番下。人以外に対する権限付与のアプローチが違う。
AWS
- IAM User
- IAM Group
- Resource
GCP
違いは「何を抽象化したか」
AWS
リソース(=プログラム)を人に見立てて権限を付与している。 「〜に権限を持たせる」という擬人化を伴う表現をするけれども、AWSはそれと同じ考え方でサービスを表現している。○○くんと命名されたプログラムや bot が世の中にはたくさん存在するが、ニュアンスはあれと同じで、愛着が湧く効果が少しありそう。それにイベント駆動やサーバーレスという要素が加わると、プログラムが独立して動いているかのような印象となる。
API Gateway → AWS Lambda → Amazon S3 の例 1. API Gateway のリソースURLにリクエストを送信する 2. API Gateway が、Assume Role されている Lambda Function を起動する 3. Resource-based policy にしたがって、Lambda Function が S3 Bucket にアクセスする
GCP
サービスアカウントは、ユーザーを抽象化している。 プログラムを実行するのはユーザーであるということを出発点として、サービスアカウントという仮想的なユーザーによって実行する。定期バッチ専用ユーザーを作って本番運用します〜があるあるだけど、雑に言うと考え方は同じ。
Cloud Functions(HTTP Trigger) → Google Cloud Storage の例 1. HTTP Trigger URL にリクエストを送信する 2. Service Account が Cloud Functions を起動する 3. Service Account のもつ権限が Cloud Functions へ移譲されて、Cloud Storage にアクセスする
権限の切り替え
本番リリースや限定的な環境開放など、特定の場面に合わせて権限を切り替える機能の違い。
AWS
Switch Role / Assume Role によって切り替えを行う。特定の Role に切り替える権限が付与されている IAM User は、STS の助けを借りて任意のタイミングで特定の Role に 成り代わることができる。これによって本番環境と開発環境でアカウントが分かれている場合、同じ IAM User で両環境をまたいだ操作ができるようになる。
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
GCP
切り替えという操作はなさそうで、権限があるかないかはっきりさせるというスタンス。そもそも GCP は、ひとつのGoogleアカウントで複数のプロジェクトに属することができる。プロジェクトを切り替えればいいだけなので、権限の切り替えという需要がないような気がする。
サービスアカウントはユーザーでもありリソースでもある、という特徴があるので、Roleの上位概念を兼ねていたりもする。 特定のアカウントに「サービスアカウントの権限を借用する」という権限を付与すると、そのアカウントはサービスアカウントと同じ権限をもつことができる。
目的は異なるが、条件付きロールバインディング
という機能があるので、一定期間だけの限定的権限付与が可能となっている。
IAM Conditions の概要 | Cloud IAM のドキュメント | Google Cloud
おわり
AWS と GCP を比較するというのは、双方とも理解が深まってとてもよかった。これからもお世話になります!
あと、AWS のサーバーレスアプリケーション開発は楽しいな〜と思ってたけど、なぜなのかはうまく言語化できていなかった。「プログラムを動かす」ではなく「動いてもらう」感覚があったり、愛着を持ちやすい構造になっていることが、開発者体験として新しいからなのかもしれない。