G-gen の渡邉@norry です。Compute Engine (GCE) にアタッチする サービスアカウント と VM の アクセススコープ の概念について整理してみました。

はじめに
前提知識
- サービスアカウントとアクセススコープ
- Cloud IAM
検証
- アクセススコープ = デフォルトのアクセス権を許可
- アクセススコープ = すべての Cloud API に完全アクセス権を許可
  - サービスアカウントの権限を変更
まとめと補足
- IAM の権限とアクセススコープはより制約が厳しい方が適用される
- 最小権限の原則を意識する

はじめに

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

Google Cloud (旧称 GCP) の Compute Engine (GCE) では、VM を作成する時にデフォルトで サービスアカウント がアタッチされます。

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

今回の記事では、改めて Compute Engine における サービスアカウント と アクセススコープ の概念を整理してみます。

前提知識

サービスアカウントとアクセススコープ

Compute Engine における サービスアカウント と アクセススコープ の基礎知識については、以下の記事の サービスアカウントとアクセススコープ の項をご参照ください。

blog.g-gen.co.jp

アクセススコープは、サービスアカウントの権限に「フタをする」ような挙動をすると考えれば分かりやすくなります。

という点について、当記事では検証していきます。

Cloud IAM

Google Cloud のリソースと IAM の関係性についてはこちらをご一読ください。

blog.g-gen.co.jp

検証

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

VM を新規作成します。アタッチするサービスアカウントとしてデフォルトの Compute Engine default service account を選択します。アクセススコープ設定は デフォルトのアクセス権を許可 を選択します。

VM 作成後に詳細画面の SHOW DETAILS を押下すると、アクセススコープによって許可されている範囲を見ることができます。

デフォルトのアクセス権を許可 だと Compute Engine API や BigQuery API へのアクセス許可は無効となっている事が分かります。反対に、許可されているのは Cloud Logging (旧称である Stackdriver Logging と表記) や Cloud Monitoring (旧称である Stackdriver Monitoring と表記) への書き込み (ログやメトリクスの送出) です。また Cloud Storage バケットへの読取りも許可されています。

この状態で 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.

リクエストの認証スコープが不足している (Request had insufficient authentication scopes.) と表示され、VM が作成出来ませんでした。アクセススコープで制限されているため、このようなエラーとなります。

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

次にアクセススコープを すべての Cloud API に完全アクセス権を許可 にします。この設定では、アクセススコープではアクセス先 API を絞らない状態になります (とはいえサービスアカウントが権限を持っていない操作もできるようになるわけではありません)。

VM のアクセススコープを変更するには一度 VM を停止する必要があります。

変更したら、再度 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 の作成が成功しました。アクセススコープではアクセス先 API が絞られていないためです。サービスアカウントが VM 作成権限を持っているので、操作が成功しました。

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

次に、アクセススコープが すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントが権限を持っていない操作は行えないことを念のために確認します。

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

再度 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 を作成できるかどうか、検証しました。

サービスアカウントの持つ権限と、VM のアクセススコープ設定の状態ごとの、操作実行可否を表に表すと以下のとおりです。

	アクセススコープ : デフォルト	アクセススコープ : すべての Cloud API
サービスアカウント : 編集者	✕ (アクセススコープで拒否)	◯ (両方で許可)
サービスアカウント : 閲覧者	✕ (アクセススコープで拒否)	✕ (IAM で拒否)

VM のアクセススコープ設定が デフォルトのアクセス権を許可 では Compute Engine API への操作が無効なので、サービスアカウントに十分な権限があっても新たに VM を作成する事が出来ませんでした。

反対に VM のアクセススコープ設定が すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントに権限がなければ VM を作ることはできません。

VM のアクセススコープ設定は、サービスアカウントの権限に「フタをする」ような挙動をすると考えればよいでしょう。

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

情報システムの権限管理においては、アカウントに対しては必要最小限の権限だけ与えるべきだという 最小権限の原則 が基本となります。

しかしながら、Compute Engine デフォルトのサービスアカウントが自動的に作成される際に、プロジェクトレベルで 編集者 ロールが付与されてしまいます。

編集者は、強力なロールです。何も意識しなければ、VM のアクセススコープは デフォルトのアクセス権を許可 のはずなので、操作可能範囲はある程度制限されていますが、意図せずアクセススコープを すべての Cloud API に完全アクセス権を許可 などに設定してしまうと、かなり広い範囲の操作が可能になってしまいますため、十分注意が必要です。

この仕様への対処として、組織のポリシー で以下を設定することができます。

制約名	ID	説明
デフォルトのサービスアカウントに対する IAM ロールの自動付与の無効化	constraints/iam.automaticIamGrantsForDefaultServiceAccounts	有効化することでデフォルト Compute Engine サービスアカウント作成時に編集者権限が付与されなくなる

組織のポリシーについては、以下の記事も参照してください。

blog.g-gen.co.jp