Google Cloud Computeで Container Optimized OS (COS)を使用して、Dockerコンテナ内からVMプロジェクトの default service account の認証情報にアクセスするための最良の方法は何ですか?
$ gcloud compute instances create test-instance \
--image=cos-stable --image-project=cos-cloud
$ ssh (ip of the above)
# gcloud ...
Command not found
# docker run -ti google/cloud-sdk:Alpine /bin/sh
# gcloud auth activate-service-account
... --key-file: Must be specified.
資格情報がVM上にある場合、Dockerはそれらをマウントするだけで済みます。通常、資格情報は.config/gcloud/
、およびdocker run -v ~/.config/gcloud:~/.config/gcloud image
。特にgcloud
がないため、Container OSでそのような認証情報を利用できるかどうか、どこで利用できるかは明らかではありません。
資格情報がVMでマウント可能であると失敗する場合、オプションには次のものが含まれるようです。
.json
サービスアカウントの認証情報ファイル、次に.json
コンテナに。gcloud auth activate-service-account
VMのプロジェクトのサービスアカウント認証情報をDockerコンテナーに提供するための正規の方法またはベストプラクティスの方法はありますか?
Google Cloudにはすでにセキュリティポリシーモデルがあり、望ましいモデルは次のとおりです。プロジェクト内のVMは、サービスアカウントによって提供されるアクセス権を持っている必要があります。複雑さと誤設定や事故の可能性を回避するには、正しい解決策は、この既存のセキュリティモデルを使用することです。つまり、資格情報ファイルの作成、ダウンロード、配布、および維持を含みません。
これはCOS、Docker、Kubernetesで解決する必要のある日常的な問題のように思われるので、簡単なことは見逃していたと思いますが、ドキュメントからは解決策がわかりませんでした。
[〜#〜] edit [〜#〜]— set-service-account APIに注目—この質問は「コンテナOSでset-service-account APIをどのように使用しますか?」に縮小それが不可能な場合(Container OSにはgcloud
とgsutil
がないため)、これに注意する必要があると思います。VMユーザーはそれに応じて計画を立てることができます。
[〜#〜] edit [〜#〜]次の人々がこれを越えるために:
問題を再現するために、私は以下を使用しました:
[local] $ ssh test-instance-ip
[test-instance] $ docker run -it gcr.io/google-appengine/python /bin/bash
[test-instance] $ pip install --upgrade google-cloud-datastore
[test-instance] $ python
>>> from google.cloud import datastore
>>> datastore_client = datastore.Client()
>>> q = datastore.query.Query(datastore_client, kind='MODEL-KIND')
>>> list(q.fetch())
[... results]
問題は確かにVMインスタンスのAPIで設定されたスコープであり、特にdatastore
APIはデフォルトアカウント(見出しの下VMのCloud APIアクセススコープ)次のように、スコープと必要なdatastore
行を見つけることができます:
> gcloud compute instances describe test-instance
...
serviceAccounts:
- email: *****[email protected]
scopes:
- https://www.googleapis.com/auth/datastore
...
...
サービスアカウント自体がデータストアへのアクセス許可を持っていることに注意してください(通常、データストアには、サービスキーのjson認証情報キーを使用してアクセスできます)。サービスアカウントの権限は、VMのスコープによって制限されていました。
通常の認証方法は、 Google cloud SDK Docker readme に表示される方法です。
COSインスタンス内からこれを1回実行します。
_docker run -ti --name gcloud-config google/cloud-sdk gcloud auth login
_
これにより、_gcloud-config
_コンテナーボリュームに資格情報が保存されます。
このボリュームは、資格情報へのアクセスを許可するコンテナーでのみマウントする必要があります。これは、おそらく_cloud-sdk
_ではないものではありません。
_docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:Alpine gcloud compute instances create test-docker --project [PROJECT]
Created [https://www.googleapis.com/compute/v1/projects/project/zones/us-east1-b/instances/test-docker].
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
test-docker us-east1-b n1-standard-1 10.142.0.8 X.X.X.X RUNNING
_
サービスアカウントは通常、どこかから取得する必要がある独自の認証情報のセットを使用することを目的としており、キーファイルであり、環境変数またはトークンです。
gcloud auth activate-service-account
Gcloud(およびCloud SDKの他のツール)がサービスアカウントの認証情報を使用してリクエストを行うようにしたい場合は、このコマンドを使用して秘密認証キーを含むファイルからこれらの認証情報をインポートし、gcloudで使用できるようにアクティブ化します。このコマンドはgcloud auth loginと同じ機能を果たしますが、Googleユーザーの認証情報ではなくサービスアカウントを使用します。
また、 ベストプラクティス は、デフォルトのサービスアカウントのキーを取得して使用するのではなく、インスタンスごとに異なるサービスアカウントを作成することです。
一般に、Googleは、Google APIを呼び出す必要がある各インスタンスを、そのインスタンスがジョブを実行するために必要な最小限の権限を持つサービスアカウントとして実行することをお勧めします。実際には、これは次のプロセスでインスタンスのサービスアカウントを構成する必要があることを意味します。
1-Compute Engineのデフォルトのサービスアカウントを使用するのではなく、新しいサービスアカウントを作成します。
2-必要なリソースのみのサービスアカウントにIAMロールを付与します。
3-インスタンスをそのサービスアカウントとして実行するように構成します。
4-インスタンスに https://www.googleapis.com/auth/cloud-platform スコープを付与します。
5-必要以上のアクセス権を付与することは避け、サービスアカウントの権限を定期的にチェックして、それらが最新であることを確認してください。
[〜#〜]更新[〜#〜]
Set-service-accountが必要な機能を果たしているかどうかはわかりません。これにより、インスタンスが使用するサービスアカウントを変更できます(ただし、インスタンスを停止する必要があるため、サービスアカウントを変更して、変更中のインスタンスを停止することはできません)。ただし、他のインスタンスには通常使用できます。以下を参照してください。
_jordim@cos ~ $ docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:Alpine gcloud compute instances set-service-account instance-1 --service-account [email protected]
Did you mean zone [us-east1-b] for instance: [instance-1] (Y/n)?
Updated [https://www.googleapis.com/compute/v1/projects/XX/zones/us-east1-b/instances/instance-1].
_