こんにちは、ちいさくもかわいくもでかくもつよくもないモモンガです。嘘です。
会社組織のGoogle CloudアカウントでVPC SCの内容がどうなってるか確認しようとしたら、権限がなくて読めないと言われました。
そこで権限追加してほしいということで、担当者の人にこんな権限をもらいました。
- 対象：プロジェクト
- プリンシパル：私(のメールアドレス)
- ロール：Access Context Managerの読み取りロール
↓イメージはこんな感じ。
ただ、これだとVPC SCは確認することができませんでした。さっさと検証できなくて都合が悪いんだよォーーーーー
ということでこれの原因と対処法的なところを調査してみました。
VPC SC(VPC Service Controls)
そもそもこれなんぞ？という話ですが、まず大事なことはVPC(Virtual Private Cloud)のことを忘れてください。
これはVPC関係ないです。SCと読んで差し支えないです。しらんけど。
VPC Service Controls は、外部エンティティや内部エンティティによる意図しない操作や標的型攻撃を阻止します。これにより、Cloud Storage や BigQuery などの Google Cloud サービスでデータ漏洩が発生するリスクを最小限に抑えることができます。
VPC Service Controls を使用すると、明示的に指定したサービスのリソースとデータを保護する境界を作成できます。
ということで、外部からGoogle Cloudリソースへのアクセスを制御するためのものです。外部というのはインターネットはもちろん、このVPC SCが設定する境界(ペリメーター)の外全部を指します。
境界内では自由に通信できますが、境界を越えるGoogle Cloudサービスとの通信はデフォルトでブロックされます。
つまり、仮に1つのOrganization内にプロジェクトA, B, Cが存在し、AとBが同じ境界内にある場合、CからA, Bにはアクセスできないようです。
そしてこのVPC SCはOrganizationで設定するものです。前述の通り、プロジェクトとかも含めて管理できるみたいなので、ある程度上位レイヤーのところで管理するという感じなんでしょうね。
参考までに、Organizationがない状態でコンソールを開くとこうなります。やはりOrganization必須ですね。
ちなみにAWSで全く同じことができるサービスは無いですね。なのでAWSユーザーからすると若干概念理解が難しいサービスでした。
原因調査
ということで私の組織の話に戻りますが、当然予めVPC SCが設定されているのですが、その制約がどうなっているかを確認したく、権限をもらって調査しようとしたのですが…
<principal> does not have permission to access accessPolicies instance
というレスポンスが帰ってきて読めませんでした。
一応改めて権限をおさらいしておきますが、↓の感じ。
IAMロールの権限的には問題ないんですが、対象がプロジェクトになっています。どうやらこれがどうやら良くないらしい。
Google Cloudの権限付与方式はAWSとちょっと違う
Google Cloudでは権限をリソース側に持たせるようです。プリンシパルとロールの紐づけを許可ポリシーというもので設定し、それを各リソース(Organization、プロジェクト、バケット、VM、コンテナ、アクセスポリシーなど)に紐づけます。
イメージ、AWSのリソースベースポリシーといったところでしょうか。
ちなみに許可ポリシーというのは以前まではIAMポリシーと呼ばれていたそうです。リネームしたんですね。
プリンシパルがリソースにアクセスしようとすると、IAMはリソース側の許可ポリシーをチェックします。そこでプリンシパルに必要な権限があるかどうかを確認します。
そしてプリンシパルが、リソースアクセスに必要な権限を持つロールに紐づいている(=ロールバインディングに属している)場合、リソースへのアクセスが許可される、という仕組みだそうです。
シンプルな例だとこんな感じだそうです。
{
"bindings": [
{
"members": [
"user:momonga@example.com"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
これだと、momongaさんに条件なしでオーナーの基本ロールが付与されています。これがリソース側についているため、このリソースに対しては、ほぼ無制限のアクセス権がmomongaさんに付与されるという感じです。
裏を返すと、他のリソースに対するアクセス権限は、そのリソースの許可ポリシーにおいてmomongaさんに紐づいているロールによります。
ちなみにプロジェクトにロールを付けることも可能で、プロジェクトAの許可ポリシー設定項目でプリンシパルとロールがありました。これで先程のロールバインディングが行われるんだと思います。
そしてこれらの許可リストは下に継承されます。以前のブログでも書いたのですが、Google Cloudは階層構造で管理されており、上位層の権限は下位層にも自動的に継承されるそうです。
ではどうするか
一応解決策は2つあるらしいです。
- 対象をプロジェクトからOrganizationにする
- アクセスポリシーそのものに権限付与
1. 対象をプロジェクトからOrganizationにする
対象をOrganizationにする必要があるようです。↓こんな感じ。
先ほど少し話したことを踏まえ、Organizationにおける権限付与は、Organizationの許可ポリシーにおいて誰をどのロールで紐づけるか、を考えます。
ここでは私にAccess Context Managerの閲覧ロールを紐づけます。
そして私がVPC SCを確認しようとすると、Organizationの許可リストを確認し、その中に私が掲載されていれば許可が下ります。
AWSのリソースベースポリシーを拡張した感じで、それをGoogle Cloudではデフォルトで使っているようなイメージを持っていただければよいのかなと。
S3バケットポリシーに「momongaさんはGetObject して良い」と書くのがデフォルトの権限設定、と捉えて良さそうです。アクセスする側の人やロールが権限を持っている形ではないようです。この辺が若干ややこしい。
2. アクセスポリシーそのものに権限付与
先ほどはOrganizationに直接権限設定しましたが、VPC SCのアクセスポリシーというやつに設定してもOKみたいです。
アクセスポリシーは組織直下にあるリソースで、許可ポリシーを設定できます。Organizationコンソールからのみ確認できます。
例によって、プロジェクトを選択していると見れません。
まとめ
Google Cloudの権限付与はリソースベースポリシーみたいなもんだと思おう。
VPC SCを読みたいならOrganizationのレイヤーで権限をもらおう。
どのレイヤーの何にどのプリンシパルとポリシーを結びつければ良いのか、理解するのも人に説明するのなんか大変で嫌になっちゃうんだよォーーーーーー