Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Kubernetes Novice Tokyo #26 の LT 資料です。
https://k8s-novice-jp.connpass.com/event/286692/

逆井(さかさい)

July 04, 2023
Tweet

More Decks by 逆井(さかさい)

Other Decks in Technology

Transcript

  1. - 2023/07/04 Kubernetes Novice Tokyo #26 - GKE のワークロードから GCP

    サービスへ 安全 にアクセスする 〜 Workload Identity 入門 〜 逆井(さかさい) 啓佑 @k6s4i53rx
  2. - 2023/07/04 Kubernetes Novice Tokyo #26 - 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
  3. GKE 上のアプリ から GCP サービス を扱う ことがよくあるけど、 どうアクセスしているんだろう...?? - 2023/07/04

    Kubernetes Novice Tokyo #26 - 今日 15 分くらいで話すこと Cloud Trace CloudSQL Cloud Datastore Pod (アプリ) GKE ユーザー ※ アーキテクチャの構成要素などはイメージです。
  4. GKE 上のアプリ から GCP サービス を扱う ことがよくあるけど、 どうアクセスしているんだろう...?? - 2023/07/04

    Kubernetes Novice Tokyo #26 - 今日 15 分くらいで話すこと Cloud Trace CloudSQL Cloud Datastore Pod (アプリ) GKE ユーザー ※ アーキテクチャの構成要素などはイメージです。 本 LT では GKE 上のアプリが GCP サービスに アクセスする仕組み について簡単に紹介します! これがわかるようになることがゴール GCP サービスを使う権限を持っていそうだけど、どう与えられている...? (Pod A は Datastore アクセス OK だけど、Pod B は NG ってどうやる?)
  5. - 2023/07/04 Kubernetes Novice Tokyo #26 - 今日話すコトと、話さないコト 留意点 -

    本スライドの検証には GKE Version: 1.25.8-gke.1000 を用いています 本日お話しできないこと(時間 && 技術的) - IRSA や Azure AD との比較については触れ (られ) ません - Workload Identity の ”詳細” な認証フローについては時間上触れません - Zenn 記事としたのでそちらにオフロード 󰝊シュッ! https://zenn.dev/k6s4i53rx/articles/18a72c2db8c9e9 本日お話しすること - GKE のワークロードが、GCP サービスにアクセスする方法を幾つか紹介 - オススメの方法である “GKE Workload Identity” についてデモと共に紹介
  6. - 2023/07/04 Kubernetes Novice Tokyo #26 - GCP リソースを扱うためには... 結論からいうと,,,

    (GKE 関係なく、) GCP リソースを操作するライブラリ がよしなにやってくれる! ※ Application Default Credentials(ADC) という認証情報取得の仕組みを用いて ① 特定の場所に配置された認証情報を使う ② GCE(実行環境)に紐付いた IAM Service Account を使う 参考:アプリケーションのデフォルト認証情報の仕組み
  7. ① 特定の場所に配置された認証情報を使う - 2023/07/04 Kubernetes Novice Tokyo #26 - GCP

    リソースを扱うためには... 結論からいうと,,, (GKE 関係なく、) GCP リソースを操作するライブラリ がよしなにやってくれる! ※ Application Default Credentials(ADC) という認証情報取得の仕組みを用いて 実行環境 IAM SA ・CloudSQL 編集権限 ・Datastore 読取権限 ・GCS 編集権限… リクエスト キー(JSON) をエクスポート Datastore ロール アプリ "GOOGLE_APPLICATION_CREDENTIALS" 環境変数で指定された PATH ✔ アクセス可
  8. - 2023/07/04 Kubernetes Novice Tokyo #26 - GCP リソースを扱うためには... 結論からいうと,,,

    (GKE 関係なく、) GCP リソースを操作するライブラリ がよしなにやってくれる! ※ Application Default Credentials(ADC) という認証情報取得の仕組みを用いて ② GCE に紐付いた IAM Service Account を使う 実行環境 IAM SA メタデータサーバー Datastore ① 認証情報をリクエスト ② アクセス元に紐づく IAM SA応じた認証情報 ③ datastore アクセス ・Datastore 読取権限 ロール アプリ ✔ アクセス可
  9. - 2023/07/04 Kubernetes Novice Tokyo #26 - GCP リソースを扱うためには... クライアント

    ライブラリ便利!! クライアント ライブラリの ADC を使えば、認証部分もライブラリに任せられる! ▪ 補足: - Go の場合は、 - google-cloud-go: https://github.com/googleapis/google-cloud-go の中の - google/oauth2: https://github.com/golang/oauth2 に認証情報を順繰り探していく実装 が あるので、興味のある方はチェックしてください 👍
  10. - 2023/07/04 Kubernetes Novice Tokyo #26 - GKE 上のアプリケーションでは? なるほど。。。IAM

    Service Account と GCP リソースを操作するライブラリ が良い感じに認証してくれるんだな。 GKE 上のアプリケーション(Pod) もおんなじ感じで良さそうでは・・・?
  11. ① 特定の場所に配置された認証情報を使う   => IAM SA のキーを Secret リソースとしてデプロイして、Pod にマウントする -

    2023/07/04 Kubernetes Novice Tokyo #26 - できることはできるけど課題が・・・ GKE Pod Secret IAM SA リクエスト Datastore Pod にマウント ✔ アクセス可
  12. - 2023/07/04 Kubernetes Novice Tokyo #26 - できることはできるけど課題が・・・ GKE Pod

    Secret IAM SA リクエスト Datastore 1. IAM SA キーの 手動でローテションが必要 2. エクスポートした IAM SA キーの流出のリスク ※ この方法は推奨されていない Pod にマウント ✔ アクセス可 ① 特定の場所に配置された認証情報を使う   => IAM SA のキーを Secret リソースとしてデプロイして、Pod にマウントする
  13. ② GCE に紐付いた IAM Service Account を使う   => GKE ノード作成時にデフォルトの

    IAM Service Account がアタッチされ(※ 指定も可能)、     そのノード上のワークロード(Pod) は、この IAM Service Account を使って認証される。 - 2023/07/04 Kubernetes Novice Tokyo #26 - できることはできるけど課題が・・・ 同じ IAM SA の認証情報 GKE ノードA ノードB IAM SA メタデータサーバー Pod A Pod B Datastore ✔ アクセス可
  14. - 2023/07/04 Kubernetes Novice Tokyo #26 - できることはできるけど課題が・・・ 同じ IAM

    SA の認証情報 GKE ノードA ノードB IAM SA メタデータサーバー Pod A Pod B Datastore 1. 同一ノードの上のワークロード は同じ権限を持つことになる 2. 最小権限の原則に反する ※ デフォルト IAM SA の場合、 K8sクラスタ実行に過剰権限になる ✔ アクセス可 ② GCE に紐付いた IAM Service Account を使う   => GKE ノード作成時にデフォルトの IAM Service Account がアタッチされ(※ 指定も可能)、     そのノード上のワークロード(Pod) は、この IAM Service Account を使って認証される。
  15. ▪ GKE 上の Pod(アプリ)の認証まとめ:  ① IAM SA のキーを Secret としてマウントして使う

     => IAM SA キーのエクスポートは推奨されていない  ② GKE ノードの IAM SA を使って、メタデータサーバー から認証情報取得  => GKE ノード上のワークロードが同じ権限を持ってしまう  ③ Workload Identity を使う ← オススメ - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity を使おうぜ 😎(やっとメイン)
  16. - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity is

    何? Workload Identity とは • Workload Identity は、 外部ワークロード(ex: AWS, Okta, …) に GCP リソースへのアクセス権を付与する仕組み • GKE で Workload Identity の仕組みを使うことで、 IAM SA と K8s SA を連携し、GKE 上のワークロードを個別の IAM SA として実行可能
  17. - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity is

    何? これにより、実現したかったことができるようになります! 同一ノード上の、 - Pod A には “Datastore 編集権限” を持たせる - Pod B には “Datastore 編集権限” を持たせない × Pod B Pod A K8s SA: sa-k8snovice K8s SA: default Datastore ✔ アクセス可 アクセス不可 IAM SA ・Datastore 読取権限 ロール 連携
  18. Workload Identity の手続き(サラッと): • GKE に “GKE メタデータサーバー” というコンポーネントが Daemonset

    としてデプロイ(勝手に) • 関連付けたい K8s SA と IAM SA の間に IAM Policy Binding を追加 $ gcloud iam service-accounts add-iam-policy-binding     <IAM SA>@<PJID>.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:<PJID>.svc.id.goog[NAMESPACE/<K8s SA>]" • K8s SA の annotation に関連付けたい IAM SA 以下を追加 iam.gke.io/gcp-service-account:<IAM SA>@<PJID>.iam.gserviceaccount.com - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity is 何? IAM 内の 関連付け K8s 内の 関連付け
  19. これにより、 "K8s SA" が "IAM SA の認証情報" を "GKE メタデータサーバー"

    から取得可能!! - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity is 何? Pod Worker Node GKE メタデータ サーバー Datastore K8s SA: sa-k8snovice IAM SA: iam-sa-k8snovice の認証情報をリクエスト K8s SA と IAM SA の 関連付けを確認 iam-sa-k8snovice になりすまして datastore アクセス
  20. - 2023/07/04 Kubernetes Novice Tokyo #26 - Workload Identity is

    何? 正確にかくと GKE メタデータサーバーを中心に、 細かい認証フローがある(Zenn 参照)が、ユーザー側からは単に GKE メタデータサーバーが、 K8s SA に関連付く IAM SA の認証情報を返してくれているように見える。 GKE メタデータサーバー 優秀 Zenn 記事へ!
  21. - 2023/07/04 Kubernetes Novice Tokyo #26 - 最後に、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 ・Datastore 読取権限 ロール 連携
  22. - 2023/07/04 Kubernetes Novice Tokyo #26 - 最後に、Let’s Try Workload

    Identity アプリによって、 付与する権限を変更できた!
  23. - 2023/07/04 Kubernetes Novice Tokyo #26 - まとめ • GKE

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