「GCPのIAMをよろしく」と伝えられた話

はじめに

こんにちはー
5月末からクラウドCoEユニットになった植垣です。

いやいやー。ゲームが熱いですね。
「ファイアーエムブレム風花雪月」がまだまだ終わらず、「ドラクエ11S」、「ペルソナ5 ザ・ロイヤル」が発売され、今後も面白そうな新作がでる予定です(個人的にです)。
色んな意味で「つんで」るなーと思う今日この頃です。
あ、あと最近アニメも個人的に熱いです。
転◯シリーズとか、あひるの◯のコミック読んでたなーとか、魔法科高校の◯◯◯の2期楽しみだなーとか、とある。。。。。。。

(おっと、そろそろお仕事の話をしないと)

異動前はAWSを活用してデータをごにょごにょするお仕事をしていたのですが、異動後はGCPに関して主に動いています。
GCPを主に動いている理由はチームリーダーの方からの「よろしくー」の一言だったと思います。信頼してくれていますねー (まだ人数が少ないため全員で同じものを学ぶよりも、別々に尖った方が良い的なことを言っていた気もしますね)

本題

さて、今回のお話はクラウドCoEのミッションとしてあげている「クラウド管理」に関連する内容で「GCPのIAM管理と運用」がテーマです。
AWSに関しては少し前に紹介があったと思いますが、そのGCP版みたいな感じです

blog.engineer.adways.net

課題と結果と実現したこと

課題

自分が異動する前からGCPは利用されていましたが、異動後に自分が運用的な事をやっている間に抱えた課題を少し紹介します。

  • 権限付与先がバラバラでよくわからない!

    • GCPでは「組織」、「フォルダ」、「プロジェクト」、「リソース」に対して権限を付与することができる
      • 付与する対象の混在
      • 「誰が、何に、どのような権限」を持っているかわかりづらい
    • ルールを定めたい
      • 棚卸ししやすい
      • 自動化しやすい
  • 1人1人への権限付与が手間!

    • 権限付与は1人1人に対して行うが、開発はチームで行っている
      • チームには複数の役割がある
      • 役割によって担うべき業務(権限)が異なる
    • 役割で権限管理したい
      • 権限の統一化と効率化
  • なんかアカウントが残ってる!

    • GSuite側のアカウントを削除しても、GCP側では残ってしまう
      • アカウント削除の度に確認
    • 人の出入り時の作業を無くしたい
      • 棚卸しが必要ない

上記の課題を解決するために公式ドキュメントの読み漁り、ベストプラクティスの調査、セミナーに行ってヒアリングとかをしてたのですが、中々「これだ!」と思えるものがありませんでした。いつも思ったのは 「アドウェイズに合うかな?」 ってことでした。

なので今回のIAM管理・運用の構成等は 「収集した情報」 を元に、 「アドウェイズにとっていい感じに組み合わせたもの」 にしました(したつもりです)。

結果と実現したこと

f:id:AdwaysEngineerBlog:20191111225351p:plain

構成の大きなポイントは2つです

  • IAMユーザ管理にはGoogleGroups(以下、グループ)を用いる
  • サービス毎にフォルダを作成し、関連するプロジェクトを配下に置いた(階層化)

IAMユーザ管理にはGoogleGroups(以下、グループ)を用いる

  • ユーザ管理にグループを用いることはベストプラクティスの一つ
  • アドウェイズではサービス別に administrator, developer, operator, viewer のグループを作成
    • グループは「サービスに携わる上の役割」と位置付け、必要な権限を付与
  • グループ毎に権限方針を抽象的に策定
    • administrator: 管理に必要な権限を持つ(緊急時除く)
    • developer: 開発に必要な権限を持つ(一部のぞく)
    • operator: 日々のオペレーションに必要な権限を持つ
    • viewer: 閲覧するのに必要な権限を持つ

※権限方針はベストプラクティスに沿っていません。最小権限とするのがベストプラクティスとされています

グループ利用によって

  • 個別での権限付与の必要がなくなり作業の効率化につながる
  • 人の出入りにおいてGCP側での作業がなくなる

サービス毎にフォルダを作成し、関連するプロジェクトを配下に置いた(階層化)

  • 階層構造を持たせ、権限の継承を利用
    • プロジェクトが一つの場合であっても必ずフォルダを作成(最初は本番環境のみだが増える可能性がある)
  • 階層に付与する権限方針を策定
    • グループを用いてフォルダレベルで権限付与を行う
    • 原則プロジェクトレベルで権限付与を行うのはサービスアカウントのみとする

階層構造の切り方について

案としては下記の3つがありました

  • 環境(本番やテスト)
  • 部署名
  • サービス

アドウェイズのパブリッククラウドにおける権限の方針として、「権限は大きく与える」(自由と責任という考え方)というものがありました。
そのため環境によって権限を変更する必要がないと思ったので、最終的にサービスで階層を切る選択肢を選びました(GCPにブラックリスト方式での権限付与があれば、もしかすると別の案があったかもしれませんね)

階層化によって

  • 関連プロジェクトにおいて権限が統一できる
  • 権限の継承により作業の効率化につながる

まとめ

GSuiteを使っていたためか、AWSほどユーザ管理が複雑になっていたりはありませんでした。
ただ圧倒的に参考事例が少なかったので情報収集が大変だったなーとか、現状の構成を新しい構成にするためにすごいサポートに問い合わせしたなーってことを今書きながら思い出しています。
今回の件により、より開発に集中できる環境を整えることができていればいいなと思っています。

ではまた機会があれば