GCPを使い始めて気づいたAWSとの違いをメモしていく その1
今までAWSを使ってきたけど、GCPも使うことになった。
公式ドキュメント AWS プロフェッショナルのための Google Cloud Platform
https://cloud.google.com/docs/compare/aws/?hl=ja
もあるけど、やっぱり使うと色々と気づきがあるので、使い始めて気になったことをメモしていく
IAM
用語・概念がAWSとぜんぜん違う
- エンドユーザー : ユーザーアカウント。Googleアカウントを使う
- システムユーザー : サービス アカウント。いわゆるアクセスキーが発行できる（GCP内利用なら不要）
- Role : 権限セット。基本的に用意されているものを使う
- Policy : リソースに対して、UserとRoleの紐づけをおこなう
リソースに対して、このユーザーはこの権限セット(role)をもつ、を指定する。
階層の概念がある
ポイントは、親は神ってこと https://cloud.google.com/iam/docs/overview?hl=ja#policy_hierarchy
親のポリシーで付与されたアクセス権を子のポリシーで制限することはできません。たとえば、プロジェクトで編集者の役割をユーザーに付与し、その子リソースで閲覧者の役割を同じユーザーに付与した場合、そのユーザーは子リソースでも編集者の役割を持つことになります。
監査ログ
AWSのCloudTrailに相当
はじめから、操作系はロギングされていて無効にできない。閲覧系・データー読み書きも対象にできる（要設定）
Stackdriver Loggingに出力される。保管期間は固定 https://cloud.google.com/logging/quotas?hl=ja#logs_retention_periods
CloudTrailの証跡機能(S3に保管したり、そのhashつくったり)は見当たらない（Stackdriver LoggingからCloud Storageへエクスポートし続ける、は簡単にできる）
ネットワーク
VPC
グローバルでネットワークが構成される
サブネット名はリージョン内で一意である必要あり（VPC違ってもかぶっちゃだめ）
Firewall Rule
AWSのSecurityGroupとは全く違う作り
ACLの作り
- AWSの、SecurityGroupは、deny->allowで穴を開けていく方式だが、
- GCPのFirewall Ruleは優先度順にマッチしたところで決まる方式（ネットワークのACLで一般的な方式）
アタッチ
- AWSのSecurityGroupはインスタンス(厳密にはENI)にアタッチする
- GCPのFirewall RuleはVPC固有（VPCに一つ）
- 個別のルールでターゲット（適用されるインスタンス）を限定したルールが作れる。タグとか、サービス アカウントとかで指定できる
VPCフローログ
- AWSとだいたい同じ、Stackdriver loggingに吐いてくれる。
- Firewall RuleでDenyされた通信は出力されないっぽい
Log
- Stackdriver Loggingが、CloudWatch Logsに相当
- CloudWatch Logsと違って概念的にログは一つでフィルターで全部絞る
- Exportは、設定すればずっとシンクし続けてくれるので、CloudWatchLogsみたいに自力で定期実行したり、Kinesisとか用意しなくてもExportし続けてくれる。
- Agentはfluentd base https://cloud.google.com/logging/docs/agent/?hl=ja
- 保管期間は固定 https://cloud.google.com/logging/quotas?hl=ja#logs_retention_periods
Compute インスタンス
SSHログイン
-
gcloud compute sshすると、自動で自分のユーザーアカウントと、SSH鍵を生成して、SSHログインできる - ec2-userみたいな共有アカウントにならないし、共有鍵管理もしなくてOK
-
roles/compute.instanceAdmin.v1Roleをもっていれば、↑のSSHログインができる - https://cloud.google.com/compute/docs/access/iam?hl=ja#connectinginstanceadmin
おしまい
- とりあえず今日はここまで
- Deployment Managerがどんなものなのか気になるので、はやめに試してみる