Open in app

Sign in

Write

Sign in

あなたが知らない（かもしれない）Google Cloud アクセス管理

Yutty Kawahara
google-cloud-jp
Published in
18 min readOct 30, 2020

--

はじめに

こんにちは、Google Cloud Customer Engineer の Yutty です。久しぶりの投稿です。今回の投稿は、kwjp@との共著です。

2019年の Advent calendar で「 GCP の IAM をおさらいしよう」という記事を書きました。未だに多くの方に読んでいただいており、IAM まわりで情報を探している方も多いのだろうと推測しています。

今回は、比較的新しい機能や、こういうときどうするの？といったプラクティスを紹介していきたいと思います。

Cloud Identity Groups

もしかしたら、このトピックは「サービスアカウント Google グループ」といったキーワードで検索された方にはピッタリかもしれません。

10 new security and management controls for GCP and G Suite でも紹介されていますが、まず Cloud Identity の Groups API を紹介したいと思います。

Google Cloud のアイデンティティ（権限を付与できる対象）として、今まで Google アカウント、複数の Google アカウントが所属する Google Group、そして Service Account がありました。

Service Account は人間以外（アプリケーション）が API を利用する時に利用されますが、アプリケーションが Google Workspace 系の API を利用するには、全体委任をするか OAuth2.0 で利用する Client ID の Scope を明示的に指定して Admin コンソールから指定する必要がありました。

一方で、Google Sheets でマスターを管理しており、GCP上のアプリケーションと連携させたいが、「全体委任は権限が広すぎる」「Google Workspace は情報システム部門が管理しており、Scope 許可の手続きが面倒くさい」といった理由から、うまく活用できてなかった方も多いかと思います。

これらの問題を解決するのが、Cloud Identity Groups です。

Cloud Identity Groups を利用すると、組織のドメイン(example.com) の Alias が発行され、そこにメンバーを追加することが出来ます。従来も、IAM 管理のプラクティスとして「権限付与は Group で管理する」というものがありましたが、そこに Service Account も追加し、管理することが可能です。

まず Service Account を作成します。

ローカルで実行するために、Service Account Key をダウンロードしておきましょう。

次に、Group を作成します。IAM > Groups > Create から作成画面に遷移します。Service Account を作成したGroups にメンバーとして参加させます。

Group を作成すると、作成者は自動的にグループのオーナーとなります。

IAM で作成した Group は、Admin コンソールからも見えるようになっています。

逆に、Admin コンソールから作成した Group も、GCP コンソールからも参照できます。

作成した Group を、Google Sheets の共有から追加して権限を付与します。

初めに開発環境を準備しましょう。

npm init
npm install googleapis
GOOGLE_APPLICATION_CREDENTIALS=/path/to/the/file/<service-account-key>.json

サンプルコードは以下のとおりです。

const { googleClient } = require('googleapis');(async () => {
    const auth = await googleClient.auth.getClient({
        scopes: ['https://www.googleapis.com/auth/spreadsheets']
    });
    const sheets = googleClient.sheets({version: 'v4', auth});const request = {
        spreadsheetId: '<Spreadsheet ID>',
        range: 'A1',
        valueInputOption: 'RAW',
        insertDataOption: 'INSERT_ROWS',
        resource: {
            values: [
                ['Cloud', 'Identity', 'Groups'],
            ],
        },
    };await sheets.spreadsheets.values.append(request);
})();

実行してみると、Google Sheets にレコードが追加されているのがわかります。

このように簡単に Group を使って、Service Account を利用した Google Sheets のアクセス管理が可能です。

2021/04/16追記
組織で Drive の外部許可が制限されている場合は、現時点では Block されてしまうので、ご注意ください（また gserviceaccount.com はAllowlist Domain に追加することは不可）

Dynamic Groups (Beta)

Dynamic Group はその名の通り、動的に Group を生成する機能になります。メンバークエリ（組織内で特定の役割をもつすべてのユーザー、など）や、役職や勤務地などの従業員属性の情報を使用して自動的に管理される Google グループです。メンバークエリは、Google Cloud API の式の作成に使用される標準言語である Common Expression Language（CEL） を使用して記述する必要があります。

新しく従業員が増え新たなアカウントが生成されると、必要な権限を付与するために関連する Group に追加する作業がありました。この Dynamic Groups によってそういったワークロードが低減出来るのではないでしょうか？

こちらの機能は Rest API もしくは Python のサンプルがございます。

Creating a dynamic group | Cloud Identity

リソース管理における権限の継承

GCP のリソース管理のコンポーネントとして、組織、フォルダ、そしてプロジェクトがあります。これらはツリー構造を持って、上位の権限を下位に継承するようになっています。継承される権限は組織ポリシーと IAM ポリシーになります。ベストプラクティスはこちらを参照ください。

今回は GCP プロジェクトに継承される組織ポリシーと IAM を確認する Tips をご紹介したいと思います。

権限が継承される仕組みは、組織内のリソース制限や権限委譲を集中管理するうえで大変便利な機能ですが、一方で GCP プロジェクトをあるフォルダから他のフォルダに移動するようなケースでは、移動前後で GCP プロジェクトに継承される権限が変わる可能性があるということになります。従って、安全にフォルダ移動を進める上では、組織ポリシー、IAM 双方で継承される権限を確認しておく必要があります。

まず、組織ポリシーからです。

上のリソース構成図において、プロジェクト 1 を、フォルダ 1 からフォルダ 3 配下に移動したいケースを考えます。

この場合、当然ながら、プロジェクト 1 に継承されるポリシーは
組織 > フォルダ 1、から
組織 > フォルダ２ > フォルダ３
という形に変更されます。

実験的に、フォルダ 1、 2、 3 とプロジェクト 1、 3 を作成し以下のようなポリシー設定を行いました。

組織：Disable service account creation を有効
フォルダ 1：Disable service account key creation を有効
フォルダ 2：Disable Cloud Logging を有効
フォルダ 3：Disable Internet Network Endpoint Groups を有効

つまり

プロジェクト 1 は
Disable service account creation
Disable service account key creation

プロジェクト 3 は
Disable service account creation
Disable Cloud Logging
Disable Internet Network Endpoint Groups

が適用されていることになります。

さて、それではプロジェクト 1 のフォルダ間移動を行なう前に、それぞれの組織、フォルダに設定されている権限を確認しておきましょう。（これからの操作は、対象の組織、フォルダやプロジェクトに対するリソースの読み取り権限が必要となりますので、カスタムの役割が付与されたユーザーで行なう場合は権限が足りているかご留意ください。詳細はこちらをご参照）

まず組織内のフォルダーの ID を確認します。以下の gcloud コマンド、または GCP コンソールの「IAM > リソースの管理」から確認することができます。

$ gcloud resource-manager folders list --organization=1122334455
DISPLAY_NAME  PARENT_NAME               ID
folder1       organizations/1122334455  111111111111
folder2       organizations/1122334455  222222222222$ gcloud resource-manager folders list --folder=222222222222
DISPLAY_NAME  PARENT_NAME           ID
folder3       folders/222222222222  33333333333

続いて、各階層に対する組織ポリシーを確認します。

組織

$ gcloud resource-manager org-policies list --organization=1122334455
CONSTRAINT                                     LIST_POLICY  BOOLEAN_POLICY  ETAG
constraints/iam.disableServiceAccountCreation  -            SET             BwWyEsO8_Uo=

フォルダ 1

$ gcloud resource-manager org-policies list --folder=111111111111
CONSTRAINT                                        LIST_POLICY  BOOLEAN_POLICY  ETAG
constraints/iam.disableServiceAccountKeyCreation  -            SET             BwWyEsyVF2M=

フォルダ 2

$ gcloud resource-manager org-policies list --folder=222222222222
CONSTRAINT                           LIST_POLICY  BOOLEAN_POLICY  ETAG
constraints/gcp.disableCloudLogging  -            SET             BwWyEs8ajGQ=

フォルダ 3

$ gcloud resource-manager org-policies list --folder=33333333333
CONSTRAINT                                               LIST_POLICY  BOOLEAN_POLICY  ETAG
constraints/compute.disableInternetNetworkEndpointGroup  -            SET             BwWyEtLjfW4=

前述の組織ポリシーが設定されていることが確認できましたので、現在フォルダ 1 配下に所属しているプロジェクト 1 にて適用状況を確認します。

$ gcloud resource-manager org-policies describe constraints/iam.disableServiceAccountCreation --project=project1 --effective
booleanPolicy:
  enforced: true
constraint: constraints/iam.disableServiceAccountCreation$ gcloud resource-manager org-policies describe constraints/iam.disableServiceAccountKeyCreation --project=project1 --effective
booleanPolicy:
  enforced: true
constraint: constraints/iam.disableServiceAccountKeyCreation$ gcloud resource-manager org-policies describe constraints/gcp.disableCloudLogging --project=project1 --effective
booleanPolicy: {}
constraint: constraints/gcp.disableCloudLogging$ gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project=project1 --effective
booleanPolicy: {}
constraint: constraints/compute.disableInternetNetworkEndpointGroup

組織及びフォルダ 1 で enforce されている Disable service account creation と Disable service account key creation が有効になっていて、逆にプロジェクト 1 の継承ツリー上にはないフォルダ 2 とフォルダ 3 の組織ポリシーが適用されていないことが分かります。(GCP コンソールの「IAM > 組織のポリシー」からも同じ内容を確認することが可能です)

それでは、プロジェクト 1 をフォルダ 3 の配下に移動してみましょう。（プロジェクトのフォルダへの移動権限についてはこちらをご参照ください。）

$ gcloud beta projects move project1 --folder 33333333333

フォルダ 3 配下に移動完了したので、先程と同じようにプロジェクト 1 の組織ポリシーの適用状況を確認します。

$ gcloud resource-manager org-policies describe constraints/iam.disableServiceAccountCreation --project=project1 --effective
booleanPolicy:
  enforced: true
constraint: constraints/iam.disableServiceAccountCreation$ gcloud resource-manager org-policies describe constraints/iam.disableServiceAccountKeyCreation --project=project1 --effective
booleanPolicy: {}
constraint: constraints/iam.disableServiceAccountKeyCreation$ gcloud resource-manager org-policies describe constraints/gcp.disableCloudLogging --project=project1 --effective
booleanPolicy:
  enforced: true
constraint: constraints/gcp.disableCloudLogging$ gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project=project1 --effective
booleanPolicy:
  enforced: true
constraint: constraints/compute.disableInternetNetworkEndpointGroup

上記の通り、組織及びフォルダ 2 とフォルダ 3 で enforce されている Disable service account creation、Disable Cloud Logging と Disable Internet Network Endpoint Groups が有効となり、移動元のフォルダ 1 の組織ポリシーは適用されていないことが分かりました。

最後に、GCP プロジェクトに継承されている IAM ポリシーの確認方法をご紹介します。

これには gcloud projects get-ancestors-iam-policy という便利なコマンドがあります。このコマンドは、対象の GCP プロジェクトが属する組織ツリー上の IAM ポリシーの設定情報を一覧で取得できるため、GCP プロジェクトに継承されている IAM ポリシーを一括で把握したい際に活用することができます。

$ gcloud projects get-ancestors-iam-policy project1
---
id: project1
policy:
  bindings:
  - members:
    - user:user1@example.com
    role: roles/owner
  etag: BwWygHFGHo0=
  version: 1
type: project
---
id: '33333333333'
policy:
  bindings:
  - members:
    - user:admin@example.com
    role: roles/resourcemanager.folderAdmin
  etag: BwWygHDK2P4=
  version: 1
type: folder
---
id: '222222222222'
policy:
  bindings:
  - members:
    - user:admin@example.com
    role: roles/resourcemanager.folderAdmin
  etag: BwWyEqSZ5W0=
  version: 1
type: folder
---
id: '1122334455'
policy:
  bindings:
  - members:
    - domain:example.com
    role: roles/orgpolicy.policyAdmin
  etag: BwWyFfE_wAU=
  version: 1
type: organization

さいごに

IAM は、GCP を利用していくうえで欠かせない基本機能であるとともに、継続的に機能アップデートや便利コマンドがリリースされています。また興味深いアップデートなどがあればご紹介したいと思います。

2021/03/19 更新

ご指摘いただきまして、Google Drive の設定で組織外への共有が制限されている場合、組織で管理しているService Accountであってもアクセスできません。そのため以下の文言をさくじょ

また直接 Google Sheets に Service Account を追加しようとしても、サービスアカウントのドメインが、自社の組織 (example.com) と異なるために、追加出来ずに悩まれた方もいたのではないでしょうか？

Google Cloud Platform
Iam
Cloud Identity

--

--

Yutty Kawahara
google-cloud-jp

Written by Yutty Kawahara

30 Followers
Editor for

Customer Engineer in Google Cloud. All views and opinions are my own.

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams