GKEのワークロードからGCPサービスへ安全にアクセスする〜Workload Identity入門〜 / Getting started GKE Workload Identity

- 2023/07/04 Kubernetes Novice Tokyo #26 -
GKE のワークロードから GCP サービスへ安全にアクセスする
〜 Workload Identity 入門〜
逆井(さかさい) 啓佑
@k6s4i53rx

View Slide

Who AM I ??
逆井啓佑
さかさい
intro.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
belongs: "SIer"
kind: "SRE 兼バックエンドエンジニア "
# GKE の運用をしながら、 Go のアプリを書いてます
metadata:
#17: "性能試験は CI/CD にお任せ！"
#21: "OpenTelemetry を用いた O11y 基盤の実装"
twitter: @k6s4i53rx

View Slide

GKE 上のアプリから GCP サービスを扱うことがよくあるけど、
どうアクセスしているんだろう...??
今日 15 分くらいで話すこと

Cloud
Trace
CloudSQL
Cloud
Datastore
Pod
(アプリ)
GKE
ユーザー
※ アーキテクチャの構成要素などはイメージです。

View Slide

GKE 上のアプリから GCP サービスを扱うことがよくあるけど、
どうアクセスしているんだろう...??
今日 15 分くらいで話すこと

Cloud
Trace
CloudSQL
Cloud
Datastore
Pod
(アプリ)
GKE
ユーザー
※ アーキテクチャの構成要素などはイメージです。
本 LT では GKE 上のアプリが GCP サービスに
アクセスする仕組みについて簡単に紹介します！
これがわかるようになることがゴール
GCP サービスを使う権限を持っていそうだけど、どう与えられている...？
(Pod A は Datastore アクセス OK だけど、Pod B は NG ってどうやる？)

View Slide

今日話すコトと、話さないコト
留意点
- 本スライドの検証には GKE Version: 1.25.8-gke.1000 を用いています
本日お話しできないこと(時間 && 技術的)
- IRSA や Azure AD との比較については触れ (られ) ません
- Workload Identity の ”詳細” な認証フローについては時間上触れません
- Zenn 記事としたのでそちらにオフロード 󰝊ｼｭｯ！
https://zenn.dev/k6s4i53rx/articles/18a72c2db8c9e9
本日お話しすること
- GKE のワークロードが、GCP サービスにアクセスする方法を幾つか紹介
- オススメの方法である “GKE Workload Identity” についてデモと共に紹介

View Slide

GCP リソースを扱うためには...
結論からいうと,,,
(GKE 関係なく、) GCP リソースを操作するライブラリがよしなにやってくれる！
※ Application Default Credentials(ADC) という認証情報取得の仕組みを用いて
① 特定の場所に配置された認証情報を使う
② GCE(実行環境)に紐付いた IAM Service Account を使う
参考：アプリケーションのデフォルト認証情報の仕組み

View Slide

実行環境
IAM SA
・CloudSQL 編集権限
・Datastore 読取権限
・GCS 編集権限…
リクエスト
キー(JSON)
をエクスポート
Datastore
ロール
アプリ
"GOOGLE_APPLICATION_CREDENTIALS" 環境変数で指定された PATH
✔
アクセス可

View Slide

② GCE に紐付いた IAM Service Account を使う
実行環境
IAM SA
メタデータサーバー
Datastore
① 認証情報をリクエスト
② アクセス元に紐づく IAM SA応じた認証情報
③ datastore アクセス
ロール
アプリ ✔
アクセス可

View Slide

クライアントライブラリ便利！！
クライアントライブラリの ADC を使えば、認証部分もライブラリに任せられる！
■ 補足：
- Go の場合は、
- google-cloud-go: https://github.com/googleapis/google-cloud-go の中の
- google/oauth2: https://github.com/golang/oauth2 に認証情報を順繰り探していく実装が
あるので、興味のある方はチェックしてください 👍

View Slide

GKE 上のアプリケーションでは？
なるほど。。。IAM Service Account と
GCP リソースを操作するライブラリが良い感じに認証してくれるんだな。
GKE 上のアプリケーション(Pod) もおんなじ感じで良さそうでは・・・？

View Slide

　　=> IAM SA のキーを Secret リソースとしてデプロイして、Pod にマウントする
できることはできるけど課題が・・・
GKE
Pod
Secret
IAM SA
リクエスト
Datastore
Pod にマウント
✔
アクセス可

View Slide

GKE
Pod
Secret
IAM SA
リクエスト
Datastore
1. IAM SA キーの
手動でローテションが必要
2. エクスポートした
IAM SA キーの流出のリスク
※ この方法は推奨されていない
Pod にマウント
✔
アクセス可
　　=> IAM SA のキーを Secret リソースとしてデプロイして、Pod にマウントする

View Slide

　　=> GKE ノード作成時にデフォルトの IAM Service Account がアタッチされ(※ 指定も可能)、
　　　そのノード上のワークロード(Pod) は、この IAM Service Account を使って認証される。
同じ IAM SA
の認証情報
GKE
ノードA ノードB
IAM SA
Pod A
Pod B
Datastore
✔
アクセス可

View Slide

同じ IAM SA
の認証情報
GKE
ノードA ノードB
IAM SA
Pod A
Pod B
Datastore
1. 同一ノードの上のワークロード
は同じ権限を持つことになる
2. 最小権限の原則に反する
※ デフォルト IAM SA の場合、
K8sクラスタ実行に過剰権限になる
✔
アクセス可
　　=> GKE ノード作成時にデフォルトの IAM Service Account がアタッチされ(※ 指定も可能)、
　　　そのノード上のワークロード(Pod) は、この IAM Service Account を使って認証される。

View Slide

■ GKE 上の Pod(アプリ)の認証まとめ：
　① IAM SA のキーを Secret としてマウントして使う
　=> IAM SA キーのエクスポートは推奨されていない
　② GKE ノードの IAM SA を使って、メタデータサーバーから認証情報取得
　=> GKE ノード上のワークロードが同じ権限を持ってしまう
　③ Workload Identity を使う ← ｵｽｽﾒ
Workload Identity を使おうぜ 😎（やっとメイン）

View Slide

Workload Identity is 何？
Workload Identity とは
● Workload Identity は、
外部ワークロード(ex: AWS, Okta, …) に GCP リソースへのアクセス権を付与する仕組み
● GKE で Workload Identity の仕組みを使うことで、
IAM SA と K8s SA を連携し、GKE 上のワークロードを個別の IAM SA として実行可能

View Slide

これにより、実現したかったことができるようになります！
同一ノード上の、
- Pod A には “Datastore 編集権限” を持たせる
- Pod B には “Datastore 編集権限” を持たせない
×
Pod B
Pod A
K8s SA:
sa-k8snovice
K8s SA:
default
Datastore
✔
アクセス可
アクセス不可
IAM SA
ロール
連携

View Slide

Workload Identity の手続き(サラッと)：
● GKE に “GKE メタデータサーバー” というコンポーネントが Daemonset としてデプロイ(勝手に)
● 関連付けたい K8s SA と IAM SA の間に IAM Policy Binding を追加
$ gcloud iam service-accounts add-iam-policy-binding 　　　
@.iam.gserviceaccount.com \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:.svc.id.goog[NAMESPACE/]"
● K8s SA の annotation に関連付けたい IAM SA 以下を追加
iam.gke.io/gcp-service-account:@.iam.gserviceaccount.com
IAM 内の
関連付け
K8s 内の
関連付け

View Slide

これにより、
"K8s SA" が "IAM SA の認証情報" を "GKE メタデータサーバー" から取得可能！！
Pod
Worker Node
GKE
メタデータ
サーバー
Datastore
K8s SA:
sa-k8snovice
IAM SA: iam-sa-k8snovice
の認証情報をリクエスト
K8s SA と
IAM SA の
関連付けを確認
iam-sa-k8snovice
になりすまして
datastore アクセス

View Slide

正確にかくと GKE メタデータサーバーを中心に、
細かい認証フローがある(Zenn 参照)が、ユーザー側からは単に GKE メタデータサーバーが、
K8s SA に関連付く IAM SA の認証情報を返してくれているように見える。
GKE
優秀
Zenn 記事へ！

View Slide

最後に、Let’s Try Workload Identity
デモ構成：
1. 以下のように K8s SA を付与した / 付与していない Pod を用意します。
2. 各 Pod 内部で GKE メタデータサーバーに認証情報を問い合わせます。
3. 認証情報を使って datastore にアクセスして、データ取得を試みます。
×
K8s SA:
sa-k8snovice
K8s SA:
default
Datastore
GKE
メタデータ
サーバー
✔
アクセス可
アクセス不可
k8snovice-
pod-without-sa
k8snovice-
pod-with-sa
IAM SA
ロール
連携

View Slide

デモ動画

View Slide

アプリによって、
付与する権限を変更できた！

View Slide

まとめ
● GKE で実行されているワークロードから、
GCP リソースにアクセスする方法を幾つか紹介しました
● GKE の Workload Identity を使うことで安全にアクセスできる
○ GKE メタデータサーバーありがとう
● Enjoy GKE !

View Slide

記載されている会社名、商品名、
またはサービス名は、各社の商標登録または商標です。

View Slide

GKEのワークロードからGCPサービスへ安全にアクセスする〜Workload Identity入門〜 / Getting started GKE Workload Identity

GKEのワークロードからGCPサービスへ安全にアクセスする〜Workload Identity入門〜 / Getting started GKE Workload Identity

逆井（さかさい）

More Decks by 逆井（さかさい）

Other Decks in Technology

Featured

Transcript