AWSのCloudShellからGCPのWorkload Identity連携しようとしたけどダメだった話

はじめに

GCPのサービスを外部から使う際、サービスアカウントキーを使って動かしていました。
しかし先日のGCPのイベントでWorkload Identityという機能を使えば、AWSとセキュアに連携が取れると知りました。

AWSのClooudShellから出来ないか試してみましたが、うまくいかなかったので、その旨記載しておこうと思います。

(2022.06.01追記)AWSのCloudShellがサポートされていない旨、GCPの公式に記載ありました。

公式はちゃんと読みましょう…

結論

• AWSのCloudShellからは、GCPのWorkload Identity連携はうまくいかない
  • Cloud9からはできました。
    • インスタンスにIAMロールを紐づける必要あり

参考

知ったのはGCPイベントのアカツキさんのセッションでしたが、ブログのほうに詳しくありました。

Cloud9で動かす際の参考は以下

やったこと

GCP側

「AWSのアカウントと連携します」という設定のWorkload Identityプールというのを作ります。また、そこで使わせるサービスアカウントを指定します。

サービスアカウント作成

コンソールから「IAMと管理」-「サービスアカウント」-「サービスアカウントの作成」と遷移します。

サービスアカウント名に任意の名前を入力。（IDは自動で入力されます）

権限はオーナーにしましたが、本運用では必要十分にしておくのがよいです。

これで完了を押して作成します。

Workload Identity設定

コンソール上でサービスアカウントの下で、Workload Identityの設定が行えます。

説明を読んで「使ってみる」。

プールの名前を決めます。

プロバイダの設定で、「AWSの、特定のアカウントと連携」の設定を行います。

次の属性は、特に変更せず保存しました。詳細は参考のアカツキさんのページにあります。

サービスアカウント紐づけ

作ったプールに、サービスアカウントを紐づけます。

先程作成したサービスアカウントを指定します。
IDに制限をかけることもできますが、今回はすべてのIDを設定しています。設定例はアカツキさんのページにて。

以下の画面で「構成をダウンロード」を押します。ダウンロードされるファイルを、AWS側で使用します。

AWS側

gcloudを展開

CloudShell上にあまりモノは入れたくないので、公式を参考にインストールしない形でgcloudを動かすようにしました。

# ダウンロード
$ curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-385.0.0-linux-x86_64.tar.gz

# 展開して移動
$ tar -xf google-cloud-cli-385.0.0-linux-x86_64.tar.gz
$ cd google-cloud-sdk/bin/

（事前確認）認証情報保存場所の、現時点の確認

この後セットする認証情報が保存される場所を、あらかじめチェックしておきます。以下の公式を参考にしました。

$ ./gcloud config
（略）
User Config Directory: ~~~~~~~~~~~~
（略）

自分の場合は/home/cloudshell-user/.configに保存されるようでした。最初の時点ではpowershellの設定のみでした。（powershellも動かせるんですね。。。）

$ ll /home/cloudshell-user/.config
total 4
drwxr-xr-x 2 cloudshell-user cloudshell-user 4096 Feb  8  2021 powershell

認証ファイルをセット

ここで先ほどダウンロードした認証ファイルをCloudShelにアップロードします

# 認証ファイルをわかりやすいところに移動
mv /home/cloudshell-user/clientLibraryConfig-awstogcp.json ./

# 認証
$ ./gcloud auth login --cred-file=clientLibraryConfig-awstogcp.json 

Authenticated with external account credentials for: [[e-mail]].
Your current project is [None].  You can change this setting by running:
  $ gcloud config set project PROJECT_ID

（うまくいかない）実行

認証もセットできたので、実際にコマンドを打ってみたのですが、エラーになってうまくいきませんでした。

$ ./gcloud iam roles list

ERROR: gcloud crashed (TransportError): HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /latest/meta-data/iam/security-credentials (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xfffffffffff>: Failed to establish a new connection: [Errno 22] Invalid argument'))

エラーに出てくる169.254.169.254というIPを調べてみると、インスタンスの情報を色々教えてくれるようです。

ですがこれをClooudShellから実行するとエラーになりました。

$ curl http://169.254.169.254/latest/meta-data/instance-id/
curl: (7) Couldn't connect to server

この情報が取得できないためか、CloudShellからWorkload Identity連携はダメでした。

（うまくいく）Cloud9を使う方法

Cloud9だと、IAMロールをインスタンスに付与しておけば、先に説明した流れで実行できるようになりました。
方法は参考に挙げましたNRIさんの方のページをご確認ください。
curl http://169.254.169.254/latest/meta-data/instance-id/を実行すると、インスタンス名を返してくれました、こちらではうまくいくようです。

削除

gcloudをインストールしているわけではないので、解凍したファイルを削除します。
また、認証情報が（私の場合は）/home/cloudshell-user/.config/gcloud/というディレクトリ下に作られたので、ディレクトリごと削除しました。

GCP側の削除はコンソールから「プールを削除」になります。必要に応じてサービスアカウントも削除します。

おわりに

今回はAWSのClooudShellからWorkload Identity連携に失敗した内容を紹介しました。
AWSのCloudShellからgcpが触れると色々便利と考えたのですが、本運用で使うこともないと思われるので、あまり詳細に調べていません。
同じようなことを試される方の参考になれば幸いです。

また、「実はできます」という話ありましたら教えてください。