改めて Google Cloud (GCP) のサービスアカウントとVMのAPIアクセススコープを確認する。

記事タイトルとURLをコピーする

f:id:ggen-norry:20220202090123j:plain

こんにちは株式会社G-genの渡邉@norry です。

昨今ではパブリッククラウドでリソースを悪用され、そのリソースを暗号通貨の発掘 (マイニング) に利用されてしまう...という話も耳にするようになってきました。

Google Cloud (GCP) ではリソース、例えば Google Compute Engine (GCE) を作成する時にデフォルトで「サービスアカウント」がアタッチされます。

このサービスアカウントの権限 (ロール)とアクセススコープの範囲によって意図しないセキュリティホールとなる可能性があります、例えば悪意を持った第3者が前述のように仮想マシンから新たな仮想マシンを生成しマイニングを行う...などですね。

Google Cloud のリソースやIAMについてはこちらを一読ください。

blog.g-gen.co.jp

今回は改めてサービスアカウントと Compute Engine (VM) 、APIアクセススコープを確認してみます。

サービスアカウントの種類

3つのサービスアカウント

サービスアカウントは、アプリケーションやツールなど人間以外のシステムが利用するIDです。自動化のツールで VM を作成したり、 VM で稼働するアプリケーションから Google Cloud の他のサービス にアクセスするような場合に使用します。サービスアカウントの公式ドキュメントはこちら

サービスアカウントには以下の3種類あり、それぞれ作成者や管理責任者が異なります。

  • ユーザー管理サービスアカウント
  • デフォルトのサービスアカウント
  • Google が管理するサービスアカウント

この中で管理責任者がユーザーであるものが ユーザー管理サービスアカウント デフォルトのサービスアカウント になります。

特に注意しおくべきはデフォルトサービスアカウントです、デフォルトサービスアカウントはGoogle Cloud 上で自動的に生成される為、意識しておかないと見逃しがちになります。

サービスアカウントキー

サービスアカウントの認証には、サービスアカウントキーを利用します。これはGoogle の認証システムで利用される公開鍵と秘密鍵のペアで、それぞれのサービスアカウントには、特定のサービスアカウントキーを割り当てて使用します。

アクセススコープ

VM を別の ID として実行する場合や、必要な API を呼び出すためインスタンスに別のスコープセットが必要であると判断した場合は、アクセス スコープを変更できます。

たとえば、アクセス スコープを変更して新しい API へのアクセスを許可できます。サービス アカウントとAPI アクセス スコープを削除して、VM が Google Cloud サービスにアクセスできないようにすることもできます。

また、VM を Compute Engine のデフォルト サービス アカウントではなく、作成したサービス アカウントとして実行するように変更することも可能です。

ただし、Google 社はアクセス制御を APIアクセススコープに依存するのでは無く、きめ細かいIAMポリシーを設定する事を推奨しています。

検証

API アクセススコープ > デフォルトのアクセス権を許可

サービス アカウントはデフォルトの Compute Engine default service account を選択し、 VM を作成しデフォルトのアクセス権を許可を選択します。

f:id:ggen-norry:20220130192405p:plain
アクセス スコープ デフォルトのアクセス権を許可

SHOW DETAILS でデフォルトのアクセススコープの詳細を見てみると Compute Engine のアクセス許可は無効となっている事が分かります。

f:id:ggen-norry:20220130195705p:plain
Cloud API アクセス スコープ

この状態で VM に SSH 接続し、gcloud コマンドにて VM を作成してみます。

norry@instance-1:~$ gcloud compute instances create instance-2
Did you mean zone [asia-northeast2-a] for instance: [instance-2] (Y/n)?  Y

ERROR: (gcloud.compute.instances.create) Could not fetch resource:
 - Request had insufficient authentication scopes.

リクエストの認証スコープが不足しているとなり、 VM が作成出来ませんでした。

API アクセススコープ > すべての Cloud API に完全アクセス権を許可

次にスコープをすべての Cloud API に完全アクセス権を許可にします。API アクセススコープの変更は一度 VM を停止して変更します。

f:id:ggen-norry:20220130194118p:plain
アクセス スコープ 全ての Cloud API に完全アクセス権を許可

再度 VM に SSH 接続し、gcloud コマンドにて VM を作成してみます。

norry@instance-1:~$ gcloud compute instances create instance-2
Did you mean zone [asia-northeast2-a] for instance: [instance-2] (Y/n)?  Y

Created https://www.googleapis.com/compute/v1/projects/xxxxxx/zones/asia-northeast2-a/instances/instance-2.
NAME        ZONE               MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
instance-2  asia-northeast2-a  n1-standard-1                                                                                 RUNNING

となり既存の VM 上から新たな VM が作成される事が確認できました。

サービスアカウントの権限を変更

アクセス スコープは すべての Cloud API に完全アクセス権を許可のままで、今度はサービスアカウントの IAM 権限を編集から閲覧者へ変更します。

f:id:ggen-norry:20220201153939p:plain
編集権限から閲覧権限へ

再度 VM に SSH 接続し、gcloud コマンドにて VM を作成してみます。

norry@instance-1:~$ gcloud compute instances create instance-3
Did you mean zone [asia-northeast2-a] for instance: [instance-3] (Y/n)?  

ERROR: (gcloud.compute.instances.create) Could not fetch resource: 

となり、リソースへの権限が無い為新たな VM を作成する事が出来ません。

まとめ

IAM の権限とアクセススコープはより制約が厳しい方が適用される

今回は VM 上から API を叩き新しい VM を作成出来るかの確認を行いました。

デフォルト サービスアカウントの権限とアクセススコープの関係を表すと下記のようになります。

デフォルトAPIスコープ 全てのAPIを許可
サービスアカウント 編集者 権限 ✕ (スコープで止める)
サービスアカウント 閲覧者 権限 ✕(スコープで止める) ✕ ( IAM 権限で止める )

デフォルト APIスコープでは Compute Engine のAPI に対し操作をする事が出来ないので、サービスアカウントで編集権限があっても新たに VM を作成する事が出来ませんでした。

VM を作成するには、API スコープで Compute Engine を範囲に含めた上でサービス アカウントにも作成の権限が必要になります。

最小権限の原則を意識する

情報システムの権限管理において、それぞれのユーザーに対し必要最小限の権限を与えるという「最小権限の原則」が基本となります。

実は Google Cloud (GCP) ではデフォルトのサービスアカウントに対し 編集者 の権限が付与されています。

これは権限として強い部類に入ります、意図せずアクセススコープを全てのAPIを許可する、などに設定してしまうと今回の確認作業のように API 経由で新しく VM を作成する事が可能となってしまう為、十分に注意する必要があります。

そういった背景から組織のポリシーで以下を設定する事をおすすめします。

ポリシーID ポリシー概要 理由と説明
constraints/iam.automaticIamGrantsForDefaultServiceAccounts デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化 有効にすることで VM を最初に作成する時に作成されるデフォルトの Compute Engine サービスアカウントに 編集者 権限が付与されることを防ぐ

それではまたお会いしましょう〜。

渡邉 宣之 (記事一覧)

クラウドソリューション部

データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持

週末フォトグラファーで、観葉植物や塊根植物にハマってます。