この投稿は、2024年JINSのアドベントカレンダー20日目の記事です。
はじめに
JINSは多くのワークロードがAWSで稼働しているのですが、用途に合わせて一部ではAzureやGoogle Cloud、Alibaba Cloudも利用するマルチクラウド構成になっています。
今回AWS上にあるデータをGoogle CloudのBigQueryに連携する要件があり、
「S3のCSV → Google Cloud Storage → BigQuery」
といった経路でデータ連携を実装しました。
ここでGoogle CloudのWorkload Identity連携という機能を初めて使ってみたのでその紹介です。
データ連携方式
まず、今回はAWS → Google Cloudへのデータ連携で、Google Cloud側からS3へファイルを取りに来るパターンも考えはしました。
例えば、BigQueryのデータ転送等です。
一方、直近JINSではデータ連携方式としてはデータソース側システムがファイルを連携してあげる方式をベースとしています。
詳しくはこちらの記事で〜
そのため今回もデータソース側であるAWS側からデータを送る方式としました。
コード自体はPythonでLambdaで動かしたのですが、AWSからGoogle Cloudを操作するにあたり必ずGoogle Cloud側の認証情報が必要になります。
サービスアカウントでjsonで鍵を作成しそれを利用することもできるのですが、鍵は漏洩リスクもあるのでできれば使わなくて済む方法はないかしらと色々調べてみました。
(別途AWS周りのワークロードでIAMロール化してアクセスキーなくしたりやSession ManegerでアクセスするようにしてSSHキーなくしたり活動を細々とやってます)
その結果、Workload Identity連携なるものにたどり着きました。
Workload Identity連携とは
Workload Identity連携はAWSなどの外部ワークロードがサービスアカウントの鍵などを発行せずにサービスアカウントの権限を利用できる機能になっています。
結構簡略された公式の概略図にはなりますが、以下のように一時的なトークンをGoogle Cloud側からもらうことで権限を借用できるような仕組みです。
私も公式や以下記事を見たりしながら、Workloas Identity連携とはをお勉強したので、参考リンクをば。
連携までの流れ
JINSでリソースを構築する際はTerraformから構築するが基本なのですが、今回はとりあえずWorkload Identity連携を使ってGoogle Cloudと繋いでみるをまず試したかったので手動でリソース作成しています。
IAMロールの作成
まずはAWS側でIAMロールを作成します。
ここはいつもの手順です。
今回はLambdaを実行できればよいので、lambda実行周りやS3へのアクセスの権限を付与した感じです。
サービスアカウントの作成
次はGoogle Cloud側での作業になります。
まずはGoogle Cloudを操作するために必要なサービスアカウントを発行します。
今回の用途とわかるような名前をつけてあります。
このサービスアカウントにはGCSへの読み書きとBigQueryにジョブが実行できるように
- BigQuery ジョブユーザー
- BigQuery データ編集者
を付与してあります。
Workload Identityプールの作成
ここからがWorkload Identity周りの設定になります。
まずはWorkload Identityプールを作成します。
以下のように名称を定義し、
プロバイダとして連携先を定義します。
プロバイダは、AWS、OpenID Connect（OIDC）、SAMLが提供されています。
AWSの場合はここで連携先のAWSアカウントIDを入力します。
サービスアカウントと接続
次に作成したWorkload Identityプールの詳細画面で「アクセスを許可」を押下し、サービスアカウントとの連携を実施します。
ここで作成したサービスアカウントを選択します。
その下の「プリンシパルを選択する」の中でIAMロールを定義することができ、こうすることで指定したプロバイダ(今回だとAWSアカウント)の中の特定のIAMロールだけがサービスアカウントの権限を借用できるようになり、よりセキュアになります。
ちなみに、ここで私はARN形式で書いておらずずっとAccess Deniedになる凡ミスをやりました・・・
構成ファイルの取得と配置
ここまで設定が完了すると構成ファイルが取得できるようになります。
画面の注意書きにも記載の通り、このファイルの中身には認証情報や機密データは含まれないものとなります。
あとはこの構成ファイルをデプロイパッケージの中に一緒に入れてあげます。
Lambdaであれば、関数と同じディレクトリに置いてあげればOKです。
そうしてあげることで、やっと実行するワークロードがサービスアカウントの権限を借用できます。
まとめ
サービスアカウントの鍵を持つことなくセキュアにクラウド間をやり取りできるのはとても便利な機能でした。
AWS内で閉じる場合はIAMロールでなどの鍵を持たない仕組みはなるべく採用しているので、マルチクラウド間でもこういった機能は積極的に使っていきたいと思います。
ちなみに
せっかく検証してみたのですが、最終的にはAWSからGoogle Cloudへのデータ連携機能は現時点ではいらないことになったので本番環境での実装はされてないです...
そんなわけなので、せっかく調査し実装まで試してみたということもありAdvent Calenderのネタにしてとりあえず供養です。
Discussion