GCPにて本番作業時の権限の切り替え方法について
業務でIAMの権限周りの管理を見直すことになったのですが、とりわけ掲題についてよくわかりませんでした。
結論だけ言うとGoogleグループの切り替えで行うのが主流のようでした。
ただそれにしても懸念点は残るので、以下の視点で調べたことや知っておいた方が良さそうなことをまとめます。
- 本番、開発環境など複数環境でGCPを使用している
- チームやIAMを作成する人数が少なく、最小限の権限を意識しつつもある程度の裁量も与えられることが可能
IAMを割り当てられるものの対象
ドキュメントではmemberと呼ばれています。これは以下の四つになります。
下二つのサービスは初めて聞きました。 AWSはAWSだけで管理できますが、GCPはGCP以外のサービスの知識も求められるので学習コストが高くなりますね。 下二つは料金が発生してしまうので一旦対象外としました。
気になるのが、本番環境にて参照時と作業時で権限を切り替える時の運用方法です。 ドキュメントだけだといまいちよくわからなかったのでコミュニティに聞いてみたところ、Googleグループを使った以下のような使われ方が主流みたいでした。
- プロジェクトにはGoogleグループに対してIAMロールを設定するようにする
- 開発者は普段は参照のみ権限が割り当てられたグループに所属している
- 本番作業時、開発者は実行権限のあるGoogleグループに入り直す
- 作業終了後、開発者は実行権限のあるグループを抜ける
グループの入り抜けに関しては、設定によって許可制にする(「組織内の誰でも参加をリクエストできる」)こともしない(「組織内の誰でも参加できる」)こともできるようでした。自チームの場合人数の関係で、承認を設けてしまうと承認者がボトルネックになって緊急時に対応が行えなくなってしまうようなことがあったらよくないなと危惧していたのですが、誰でも自由に参加退出できるようにすればその心配はなさそうです。
IAMロールには3種類ある
- 基本ロール
- オーナー(roles/owner)、編集者(roles/editor)、閲覧者(roles/viewer)
- 事前定義ロール
- 他のリソースへの望ましくないアクセスを防ぐGCP管理のrole
- カスタムロール
- ユーザーが設定できるもの
使い方としては、権限が大きい基本のロールは本番権限には付与しません。本番環境のメンバーには、事前定義ロールでできることを必要なものだけに制限したロールを付与するようにし、やりたいことが事前定義ロールでできない場合カスタムロールで自作するといった使い方が想定されています。 なるべく事前定義ロールを使うようにするのは、カスタムロールだと必要に応じて自分達でアップデートしていかないといけないので管理コストが多少できてしまうためです。
また閲覧権限に関して、閲覧のみと言いつつBQやGCSのデータにアクセスできてしまうなど権限が大きいものになっています。不要なデータへのアクセスも防ぎたい時はより制限されたrole/browerという参照権限を付与するのが望ましいです。
フォルダ
複数のプロジェクトをフォルダでまとめて管理することができます。フォルダを利用することにより、Googleグループを各プロジェクトではなくそのフォルダに割り当てることができるようになり、ユーザーの管理をより楽にできます。
?必要な時限定に絞るにはどうしたらいいか
Googleグループの切り替えによって必要な時だけ実行権限を持つようにできることはわかりました。ただ作業終了時に自分から抜けるか、誰かに除外してもらうかしないとずっと実行権限が持ったままになってしまいますよね。
一番望ましいやり方が、1時間など指定した時間が経過したらsession outになるようにすることですが、そういったものをどうやって実現させることができるのでしょうか。
?IAM Conditionsを使えばできる
IAM Conditionsとは特定の条件下でのみ権限を得るように設定できる項目のことです。条件は時間やアクセス元のリソース、IPなど色々ありました。
この機能を使えば実現できそうな気もします。がしかし、ドキュメントの例だと営業時間のみなど固定の日時の設定しかできないみたいです。本番作業は深夜メンテナンスや障害など営業時間以外にも起こりうるのでそれだとちょっと合いません。
この部分に関してはもう少し検証できたらと思うので、実現できそうなやり方があれば追記しようと思います。
おわりに
IAM Conditionsでなんとかやれないものだろうか...
参考資料
公式ドキュメント
- 概要 | Cloud IAM のドキュメント | Google Cloud
- IAM の安全な使用 | Cloud IAM のドキュメント | Google Cloud
- リソース階層を使用したアクセス制御 | Cloud IAM のドキュメント | Google Cloud
- IAM のカスタムロールについて | Cloud IAM のドキュメント | Google Cloud
- カスタムロールはロールを作成したプロジェクトor組織にのみ付与できる(フォルダレベルでは作れない)
- カスタムロールidは変えられなく、削除しても37日間は同じ名前で作れないので注意すること
- カスタムロールにはリリースステージがあり、使用期間中ですよ、といったものを示すことができる
- カスタムロールの作成と管理 | Cloud IAM のドキュメント | Google Cloud
- Policy | Cloud IAM のドキュメント | Google Cloud
- IAM Conditions の概要 | Cloud IAM のドキュメント | Google Cloud
- IAM Conditions では、構成された条件が満たされる場合にのみ、ID(メンバー)にリソース アクセス権を付与できます
- 日時属性で期間限定のアクセスを実現できる
- 基本ロールに対しては条件指定を行えない
- IAM Conditions では、構成された条件が満たされる場合にのみ、ID(メンバー)にリソース アクセス権を付与できます
- 条件付きポリシーの管理 | Cloud IAM のドキュメント | Google Cloud
- 条件付きロール バインディングの管理 | Cloud IAM のドキュメント | Google Cloud
- エンタープライズ組織の基本 - IAM Conditions の使用
非公式だけどとても参考になったドキュメント