Google CloudComputeでContainerOptimized OS(COS)を使用して、Dockerコンテナ内からVMプロジェクトのデフォルトのサービスアカウントの認証情報にアクセスするための最良の方法は何ですか?
$ 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
ます。そのような資格情報がContainerOSで利用できるかどうか、どこで利用できるかは明らかではありませんgcloud
。
VM上にあり、マウント可能な資格情報がない場合、オプションには次のものが含まれるように見えます。
.json
サービスアカウントの資格情報ファイルを作成してから、
.json
コンテナに追加します。gcloud auth activate-service-account
DockerコンテナーにVMのプロジェクトのサービスアカウント資格情報を提供するための標準的な方法またはベストプラクティスの方法はありますか?
Google Cloudにはすでにセキュリティポリシーモデルがあり、望ましいモデルです。プロジェクト内のVMは、サービスアカウントによって提供されるアクセス権を持っている必要があります。複雑さや設定ミスや事故の可能性を回避するために、正しいソリューションでは、この既存のセキュリティモデルを採用します。つまり、資格情報ファイルの作成、ダウンロード、配布、および保守を行いません。
これはCOS、Docker、Kubernetesで解決する必要のある日常的な問題のように思われるので、簡単なことを見逃したと思いますが、ドキュメントからは解決策がわかりませんでした。
編集— set-service-account APIに注意—この質問は「ContainerOSでset-service-account APIをどのように使用しますか?」に減らすことができます。(コンテナOSが欠けているので、それが不可能な場合gcloud
とgsutil
)、私はVMのユーザーがそれに応じて計画することができますので、これは注意すべきであると考えます。
編集次の人々がこれを越えるために:
問題を再現するために、私は以下を使用しました。
[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 Dockerreadmeに表示される方法です。
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 authactivate-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].
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加