GCP IAM
リソースは階層構造(組織、フォルダ、プロジェクト、リソース)
リソースの親は一つだけ
リソースのポリシーは子供に推移的に継承される
リソースの操作権限はurlぽくなってる
操作権限がまとまった物がロール
ロールは案の定便利なのが提供されとるよ
メンバーとロールを紐付けた物がポリシーで、これによってメンバーのできることが分かるね
ポリシーはリソースに紐づくよ(下位に継承されるやつ)
色々とスッキリしている印象ではある
公式も凄い分かりやすかった
用語
メンバー
Googleアカウント、サービスアカウントなど
AllUsersなども指定できたりする
ロール
権限のコレクション
hiroki.iconawsはpolicyが権限のコレクションだからここらへんが異なる
ポリシー
メンバーをロールにバインディングする
①どのリソースに対して
②ロール
③誰に(メンバー)
サービスアカウント
サービスアカウントはメンバーであり、リソースでもある
GCPサービス、アプリケーションから使う
パスワードがないのでブラウザからログインできない
gcpのcliからは利用できる→gcloud auth activate-serviceaccount
GOOGLE_APPLICATION_CREDENTIALSに認証ファイルのパスを設定する
hiroki.iconAWSのIAMみたいにアクセスキー とシークレットキーを文字で渡すというやり方が取れないのは微妙だなぁ
サービスアカウントは作成さればプロジェクトにあり、移動させることはできない
クロスプロジェクトアクセスなどする場合は各プロジェクトにサービスアカウントを作成しているとサイロ化して追跡できなくなる。
サービスアカウントをIdentityとして扱う時
サービスアカウントに付与したロールでリソースを操作できる
サービスアカウントをリソースとして扱う時
サービスアカウントにアクセスするための権限をユーザーに与えることができる
GCEにサービスアカウントを付与して、インスタンスにosログインする場合はログインする側のサービスアカウントがGCEサービスアカウント(リソースとして扱われている)にアクセスできる必要がある
code:json
{
"type": "service_account",
"project_id": "projectid",
"private_key_id": "...",
"private_key": "...",
"client_email": "hoge@projectname.iam.gserviceaccount.com",
"client_id": "...",
"auth_uri": "...",
"token_uri": "...",
"auth_provider_x509_cert_url": "...",
"client_x509_cert_url": "..."
}
サービスアカウントの分類
ユーザー管理サービスアカウント
table:違い
ユーザー管理sa デフォルトsa Googleマネージドsa
作成 ユーザーが必要な時 サービスを有効化した時に自動で Googleが自動で
削除 可能 可能 不可能
管理 ユーザー ユーザー Google
Wordload Identity
インスタンスメタデータ