Cloud Native Security Conference 2022での発表資料です。 https://event.cloudnativedays.jp/cnsec2022/talks/1439

1. Kubernetes Service Account
As Multi-Cloud Identity
Shingo Omura
Preferred Networks, Inc.
Cloud Native Security Conference 2022
2022/08/05 15:05-15:45 - Track A

2. 2
@everpeace
Shingo OMURA / @everpeace
▶ Preferred Networks, Inc. / エンジニア
▶ 社内向けGPUクラスタの開発運用
▶ 社内クラスタ向けにkube-schedulerを拡張
▶ 主にkubernetes sig-schedulingで活動中

3. 3
@everpeace
▶ Kubernetesクラスタ内での典型的なCloud API認証パターン
▶ 典型的な方法に潜むセキュリティリスクを考える
▶ Kubernetes ServiceAccount As Multi-Cloud Identity
▶ この方法における安全性とセキュリティリスクを考える
▶ Kubernetes ServiceAccount以外のIdentityを使った認証
▶ まとめ
Outline

4. 4
@everpeace
扱う認証主体はKubernetes内で動くアプリ
Icons made by Freepik from www.flaticon.com
アプリケーション用のCloud API向け
クレデンシャルを扱います
AWS: アクセスキーID/シークレットアクセスキー
GCP: サービスアカウントキー
Azure: クライアントID/シークレット

5. 5
Kubernetesクラスタ
でのCloud API認証パターン
~オンプレKubernetes編~
認証したいCloudとは別の
Cloudで動いてる場合もOk

6. 6
@everpeace
クレデンシャルを含んだSecretをPodに注入する
マウント/環境変数
クレデンシャルを
Secretリソース
として保存
クレデンシャル
を発行
Icons made by Freepik from www.flaticon.com
GitOps
できない😰

7. 7
@everpeace
Sealed Secrets を使う(GitOpsできる)
SealedSecret
Controllerで暗号化した
SealedSecret作成
マウント/環境変数
SealedSecret
からクレデンシャル
を復号してSecret
を自動作成
Icons made by Freepik from www.flaticon.com
Git管理可🎉
クレデンシャル
を発行

8. 8
@everpeace
External Secrets Operator を使う(GitOpsできる)
ExternalSecret
ExternalSecret作成
(Keyの名前だけ)
クレデンシャル発行
してSecret Manager
に保存
マウント/環境変数
Secret Manager
からクレデンシャル
をPullしてSecret
を自動作成
Icons made by Freepik from www.flaticon.com
Git管理可🎉

9. 9
@everpeace
Secrets Store CSI Driver を使う(Secret要らない)
Ephemeral CSI Volume
でKey名を指定して
Podを作成
クレデンシャル発行
してSecret Manager
に保存
Secret Managerからクレデンシャル
がPullされてCSI Volumeとしてマウント
Secret要らない🎉
Icons made by Freepik from www.flaticon.com

10. 10
従来の方法に潜む
セキュリティリスクを考える

11. 11
@everpeace
従来の方法に潜むセキュリティリスクを考える
Icons made by Freepik from www.flaticon.com
典型的なアプリ向けクレデンシャル
は無期限(非常に長い)が多い☠
(AWS→無期限、GCP→無期限、Azure→最長2年)
漏洩時により悪用されやすく
被害が大きい
暗号/キー名(≠平文)での
運用ができており
漏洩機会は減らせている🉑
が、扱っているクレデンシャルが
無期限なので根本的な対策でない
無期限なアプリ向け
クレデンシャルを開発者が
管理してしまいやすい🧐
異動後・退職後も利用できて
しまう可能性
ローテーションが徹底されづらい

12. 12
@everpeace
● そもそも秘密情報を扱うのに必要な運用
○ 秘密情報自体の権限管理
○ 監査/利用記録
○ 暗号化(生で保存しない)
○ etc.
● 無期限なクレデンシャル向けの運用
○ 定期的なローテーション(90日な規定が多い)
○ 不使用クレデンシャルの削除(90日な規定が多い)
○ IP制限(ローテーション漏れ・できない場合の緩和策として有効
クラウドププロバイダ、利用環境によっては実施が難しいことも)
○ etc.
参考: CIS AWS Foundations Benchmark 標準 - AWS Security Hub
無期限(長期間有効)なクレデンシャルは運用大変
各Cloudでの運用は可能だけど
正しく運用するのはかなり大変😰
Icons made by Freepik from www.flaticon.com

13. 13
@everpeace
昨今、公開OSSライブラリが汚染されることによるクレデンシャルの外部漏洩リ
スクが高まっている☣
○ AWS認証情報が盗まれる2つのライブラリ改ざんについてまとめてみた
○ PyPIからAWS認証情報を窃取するPythonパッケージが複数見つかる
プライベートネットワークも安全ではない
(ソフトウェアサプライチェーン攻撃)
出典: AWS認証情報が盗まれる 2つのライブラリ改ざんに
ついてまとめてみた - piyolog

14. 14
無期限なAPIクレデンシャルは
気軽に発行できて便利だけど
リスクをコントロールしながら
正しく運用するのは大変😰

15. 15
Kubernetesクラスタ内
でのCloud API認証パターン
~Managed Kubernetes~

16. 16
@everpeace
(AWSの場合) IAM Roles for Service Accounts
IAM RoleにServiceAccount
によるRoleの引き受けを許可
Role
ServiceAccountに引き受けたい
IAM RoleをAnnotationする
Icons made by Freepik from www.flaticon.com
SDKがSTS(Security Token Service)
を使ってService Account Tokenと
IAM Roleの一時的なクレデンシャルを発行
一時的なクレデンシャルをつかって
Cloud APIにアクセス
Bound SA Tokenは
Kubeletが安全に
Rotateします🔄
失効したら
SDKが自動的に
再取得🔄

17. 17
@everpeace
Kubernetes Bound Service Account Tokenとは
(v1.21以降でデフォルトで有効)
JWT
Header Payload Signature
ヘッダ
署名アルゴリズム, key ID, etc.
ペイロード
署名
ヘッダ, payloadに対する署名
"iss": "https://oidc.eks.ap-northeast-1.amazonaws.com/id/F...9",
"sub": "system:serviceaccount:default:default"
# Audienceを指定することでtokenの用途を明確化できる
"aud": ["sts.amazonaws.com"],
# 有効期間が設定できる
"exp": 1657687937,
"nbf": 1657684337,
"iat": 1657684337,
# Objectが生存する間だけ有効にできる(Kubernetesクラスタ内のみ有効)
"kubernetes.io": {
"namespace": "default",
"pod": { "name": "test", "uid": "381...fb66" },
"serviceaccount": { "name": "default", "uid": "17c...14a" }
},
Audience,Time,ObjectにBound可能なService Account Token
詳しく知りたい方はBound Service Account Tokenとは何か - Qiitaがオススメ💡
Icons made by Freepik from www.flaticon.com

18. 18
@everpeace
Kubernetes Bound Service Account Tokenとは
(v1.21以降でデフォルトで有効)
"iss": "https://oidc.eks.ap-northeast-1.amazonaws.com/id/F...9",
"sub": "system:serviceaccount:default:default"
# Audienceを指定することで tokenの用途を明確化できる
"aud": ["sts.amazonaws.com"],
# 有効期間が設定できる
"exp": 1657687937,
"nbf": 1657684337,
"iat": 1657684337,
# Objectが生存する間だけ有効にできる (Kubernetesクラスタ内のみ有効 )
"kubernetes.io": {
"namespace": "default",
"pod": { "name": "test", "uid": "381...fb66" },
"serviceaccount": { "name": "default", "uid": "17c...14a" }
},
volumes:
- name: aws-iam-token
projected:
defaultMode: 420
sources:
# ServiceAccountTokenをsourceとする
# Projected Volumeを使って発行
# kubeletが自動でRotateしてくれます
# (24時間経過or有効期限の8割超過)
- serviceAccountToken:
audience: sts.amazonaws.com
expirationSeconds: 86400
path: token
EKSでは自動でこのVolume
VolumeMounts、その他の設定を
自動でInjectしてくれます💡
詳しく知りたい方はBound Service Account Tokenとは何か - Qiitaがオススメ💡
Icons made by Freepik from www.flaticon.com

19. 19
@everpeace
(AWSの場合) IAM Roles for Service Accounts
IAM RoleにServiceAccount
によるRoleの引き受けを許可
Role
ServiceAccountに引き受けたい
IAM RoleをAnnotationする
Icons made by Freepik from www.flaticon.com
SDKがSTS(Security Token Service)
を使ってService Account Tokenと
IAM Roleの一時的なクレデンシャルを発行
一時的なクレデンシャルをつかって
Cloud APIにアクセス
Bound SA Tokenは
Kubeletが安全に
Rotateします🔄
失効したら
SDKが自動的に
再取得🔄

20. 20
@everpeace
(AWSの場合) IAM Roles for Service Accounts
ServiceAccountとIAM Roleと
紐付ける(引き受けを許可)
Role
ServiceAccountに引き受けたい
IAM RoleをAnnotationする
STS(Security Token Service)を使って
Service Account TokenとIAM Roleの
一時的なクレデンシャルを交換
一時的なクレデンシャルをつかって
Cloud APIにアクセス
SA Tokenは
Kubeletが安全に
Rotateします🔄
Expireしたら
自動的に再取得
されます🔄
アプリ開発者は
一度もクレデンシャル
を目にすることがない🙈
無期限なクレデンシャル
が存在しない🈚♾
めっちゃいい🎉
他のCloudも同様の
仕組みがあります
Icons made by Freepik from www.flaticon.com

21. 21
@everpeace
(AWSの場合) IAM Roles for Service Accounts
ServiceAccountとIAM Roleと
紐付ける(引き受けを許可)
Role
ServiceAccountに引き受けたい
IAM RoleをAnnotationする
STS(Security Token Service)を使って
Service Account TokenとIAM Roleの
一時的なクレデンシャルを交換
一時的なクレデンシャルをつかって
Cloud APIにアクセス
SA Tokenは
Kubeletが安全に
Rotateします🔄
Expireしたら
自動的に再取得
されます🔄
各Public Cloudでの機能名
AWS: IAM Roles for Service Accounts
GCP: Workload Identity
Azure: Azure AD Workload Identity
Icons made by Freepik from www.flaticon.com

22. 22
こういうのって
🙋オンプレでもできる❓
🎉出来ます🎉

23. 23
Kubernetes Service Account
As Multi-Cloud Identity

24. 24
@everpeace
ポイントはココ: SA Tokenをどうやって認証する？
STS(Security Token Service)を使って
Service Account TokenとIAM Roleの
一時的なクレデンシャルを発行
クラウド側でRoleとSAは紐付けられている🪢ので、
STSがBound SA Token(JWT(OIDC IDToken)形式)を
検証可能な状況にすればいい✅
Icons made by Freepik from www.flaticon.com

25. 25
@everpeace
ポイントはココ: SA Tokenをどうやって認証する？
STS(Security Token Service)を使って
Service Account TokenとIAM Roleの
一時的なクレデンシャルを発行
事前にRoleとSAは紐付けられている🪢ので、
STSはBound SA Token(OIDC IDToken(JWT))を検証できればよい✅
Icons made by Freepik from www.flaticon.com
🛠使う道具は２つ
(実はIRSAとほぼ同じ仕組み)
○ 各Cloudの外部OIDC ProviderとのID Federation
○ Kubernetes ServiceAccountIssuerDiscovery
(v1.21以降デフォルトで有効)

26. 26
@everpeace
OIDC IDTokenの検証プロセス
JWT
OIDC IDToken
Header Payload Signature
ヘッダ
(署名アルゴリズム, key ID, etc.)
{
"iss": "https://provider.url",
"sub": "app:comp",
"exp": 1234567,
…
}
署名
(ヘッダ, payloadに対する署名)
OIDC Provider
Icons made by Freepik from www.flaticon.com
https://provider.url
{
"jwks_uri": "https://.../jwks",
...その他provider情報
}
OIDC Discovery Endpoint
/.well-known/openid-configuration
{ "keys": [
{
"kid": "I8v…k",
"use": "sig",
…公開鍵の中身
}
]}
JWKS Endpoint: /jwks
IDTokenのIssuer("iss")の
OIDC Discovery Endpointから
JWKS Endpointを取得
JWKS Endpointから署名用の
公開鍵情報を取得
IDTokenのヘッダのKey IDの
公開鍵を使って署名を検証

27. 27
@everpeace
Public Cloudでの外部OIDC Providerによるフェデレーション
OIDC Provider
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
IDToken検証
引受権限をcheck JWT
Header Payload Signature
検証&認可成功したら
一時的なクレデンシャルを返す
OIDC IDToken
Icons made by Freepik from www.flaticon.com
EKSも実は
このエンドポイントを
持っています‼
https://oidc.eks.ap-northeast-1.
amazonaws.com/id/F98…89

28. 28
@everpeace
Public Cloudでの外部OIDC Providerによるフェデレーション
OIDC Provider
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
IDToken検証
引受権限をcheck JWT
Header Payload Signature
検証&認可成功したら
一時的なクレデンシャルを返す
OIDC IDToken
Icons made by Freepik from www.flaticon.com
つまり、
クラウドの外に立てた
Kubernetesクラスタ
向けのこれをどう作るか？

29. 29
@everpeace
Kubernetes Service Account Issuer Discovery
(v1.21以降でデフォルトで有効)
● kube-apiserverが実装しています
○ --service-account-issuer=https://my.provider
○ --service-account-jwks-uri=https://my.provider/jwks
○ --service-account-key-file=/etc/…/sa.pub
● あとはkube-apiserverがExposeしてくれた中身を
issuerのURLでインターネット(STSからアクセスできる)に公開
すればOK👌
● 注意:
○ issuerを完全に切替えると発行済のTokenが失効してしまうの
で、--service-account-issuerを新旧複数指定するのを忘れ
ずに‼(最初のが発行に使われて、後は検証時に利用)
○ DiscoveryエンドポイントはRBACによって制限されています
(system:service-account-issuer-discovery ClusterRole)
kube-apiserver
{
"iss": "https://my.provider",
"jwks_uri": "https://my.provider/jwks",
...その他provider情報
}
OIDC Discovery Endpoint
/.well-known/openid-configuration
{ "keys": [
{
"kid": "I8v…k",
"use": "sig",
…SAToken署名用公開鍵
}
]}
JWKS Endpoint: /jwks

30. 30
@everpeace
Bound SA Token,Cloud SDK設定
注入用Mutating Webhookをデプロイ
Kubernetes Service Account As Multi-Cloud Identity
Icons made by Freepik from www.flaticon.com
kube-apiserver
OIDC Discovery Endpoint
JWKS Endpoint
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
→オンプレ(他クラウド)
クラウド←
kube-apiserverの公開する
OIDC Discovery, JWKS Endpointの
内容を指定したIssuerのURLで
公開する(e.g.S3＆CloudFront)
Bound SA Tokenが
Cloud横断的にFederated Identity
として利用できる🎉
(各クラウドはTokenを検証可能)
各CloudでOIDC Providerとの
信頼関係を設定
service-account-issuer=
https://my.provider

31. 31
各CloudでOIDC Providerとの
信頼関係を設定する
Icons made by Freepik from www.flaticon.com

32. 32
@everpeace
AWSでのOIDC Providerとの信頼関係の設定
● IAM ID Provider(OIDC)を作成する
{ "Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "arn:aws:iam::xxxx:oidc-provider/my.provider"},
"Action": "sts:AssumeRoleWithWebIdentity",
# Conditionsで使えるキーは他にもあります
"Condition": { "StringEquals": {
# subの条件を忘れると全 ServiceAccountがこのRoleになれちゃうので注意
"my.provider:sub": "system:serviceaccount:<namespace>:<sa_name>"
}}
}]}
● IAM Roleに信頼ポリシーを設定する
# aws iam create-open-id-connect-provider 向けのinput.json
{ "Url": "https://my.provider",
# 許可する"aud" claimを指定(e.g. https://sts.amazonaws.com)
"ClientIDList": ["https://sts.amazonaws.com"],
"ThumbprintList": ["c3...LE"] }
このk8sクラスタの発行した
"aud"が一致するTokenが対象
その中で、特定の"sub"へ
このRoleの引受を許可する

33. 33
@everpeace
GCPでのOIDC Providerとの信頼関係の設定
● Workload Identity プール, プロバイダを作成する
# 特定のsubjectに対してGCP サービスアカウントの権限の借用を許可する
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL
--role=roles/iam.workloadIdentityUser
--member="principal://iam.googleapis.com/projects/PROJECT_ID/locations/global/workloadIdentityPools/
POOL_ID/subject/myprovider::system:serviceaccount:<namespace>:<sa_name>"
● サービス アカウントの権限借用を許可する権限を外部 ID に付与する
# GCPはWorkload Identityプールが複数のプロバイダを包含する
$ gcloud iam workload-identity-pools create POOL_ID
--location="global"
--description="DESCRIPTION" --display-name="DISPLAY_NAME"
$ gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID
--location="global"
--workload-identity-pool="POOL_ID"
--issuer-uri="https://my.provider"
--allowed-audiences="https://sts.googleapis.com" # 許可するaudience
--attribute-mapping='google.subject="myprovider::"+assertion.sub' # グループ等のmappingも可
このk8sクラスタの発行した
"aud"が一致するTokenが対象
特定の"sub"へこのサービス
アカウント権限の借用を許可
Icons made by Freepik from www.flaticon.com

34. 34
@everpeace
AzureでのOIDC Providerとの信頼関係の設定
● 外部 ID プロバイダーを信頼するようにアプリを構成する (プレビュー)
# ObjectIDはAzure ADのObjectID(Client IDとは異なるので注意 )
$ az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/
<ObjectID>/federatedIdentityCredentials' --body '{
"name":"MyProviderFederation",
"issuer":"https://my.provider",
"audiences":["api://AzureADTokenExchange"],
"subject":"system:serviceaccount:<namespace>:<sa_name>",
"description":"DESCRIPTION" }'
Azureはアプリケーションに
直接Federated Identityを
紐付ける
Icons made by Freepik from www.flaticon.com

35. 35
ワークロードへの
Bound SA Token,Cloud SDK設定
の注入
Icons made by Freepik from www.flaticon.com

36. 36
@everpeace
AWS SDKの設定の注入
aws/amazon-eks-pod-identity-webhook をインストールすればやってくれます
# ServiceAccountにroleをannotationしておけば
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceaccount
namespace: default
annotations:
eks.amazonaws.com/role-arn: |
arn:aws:iam::xxx:role/s3-reader
### optional: sa tokenの期限を指定できます
eks.amazonaws.com/token-expiration: "3600"
# Podに必要な設定を注入してくれます(太字が注入されます)
spec:
serviceAccountName: my-serviceaccount
volumes:
- name: aws-token
projected:
sources:
- serviceAccountToken: ### AWS用audienceにBoundされたSA Token Volume
audience: "sts.amazonaws.com"
expirationSeconds: 3600
path: token
containers:
- name: container-name
image: container-image:version
env:
- name: AWS_WEB_IDENTITY_TOKEN_FILE
value: "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"
- name: AWS_ROLE_ARN
value: "arn:aws:iam::111122223333:role/s3-reader"
- name: AWS_STS_REGIONAL_ENDPOINTS
value: "regional"
volumeMounts:
- mountPath: "/var/run/secrets/eks.amazonaws.com/serviceaccount/"
name: aws-token
Icons made by Freepik from www.flaticon.com

37. 37
@everpeace
GCP SDKの設定の注入 1/2
# ServiceAccountに
# Workload Identity Provider, GCPサービスアカウント
# をannotationしておくと
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceaccount
annotations:
cloud.google.com/workload-identity-provider: "
projects/xxx/locations/global/
workloadIdentityPools/POOL_ID/providers/PROVIDER_ID"
cloud.google.com/service-account-email:"
app-x@project.iam.googleapis.com"
### optional: sa tokenの期限を指定できます
cloud.google.com/token-expiration: "3600"
# Podに設定を注入してくれる(1/2) Container&Volume編
spec:
serviceAccountName: my-serviceaccount
volumes:
- name: gcp-token
projected:
sources:
- serviceAccountToken: ### GCP用audienceにBoundされたSA Token Volume
audience: sts.googleapis.com
expirationSeconds: 3600
path: token
containers:
- name: container-name
image: container-image:version
env:
- name: GOOGLE_APPLICATION_CREDENTIALS ### injected initContainerで生成(次頁)
value: /var/run/secrets/sts.googleapis.com/serviceaccount/cred-config.json
volumeMounts:
- name: gcp-token
mountPath: /var/run/secrets/sts.googleapis.com/serviceaccount
…
※webhookが公開されてないので自分でやる必要があります (内製してます)
Icons made by Freepik from www.flaticon.com

38. 38
@everpeace
GCP SDKの設定の注入 2/2
# ServiceAccountに
# Workload Identity Provider, GCPサービスアカウント
# をannotationしておくと
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceaccount
annotations:
cloud.google.com/workload-identity-provider: "
projects/xxx/locations/global/
workloadIdentityPools/POOL_ID/providers/PROVIDER_ID"
cloud.google.com/service-account-email:"
app-x@project.iam.googleapis.com"
### optional: sa tokenの期限を指定できます
cloud.google.com/token-expiration: "3600"
※webhookが公開されてないので自分でやる必要があります (内製してます)
Icons made by Freepik from www.flaticon.com
# Podに設定を注入してくれる(2/2) InitContainer編
…
initContainers:
- name: gcloud-setup
image: gcloud-sdk:slim
command:
- sh
- -c
- |
# GCP向けaudience boundなSA Token Fileを指定してcred-configを生成
gcloud iam workload-identity-pools create-cred-config
$(GCP_WORKLOAD_IDENTITY_PROVIDER)
--service-account=$(GCP_SERVICEACCOUNT_EMAIL)
--credential-source-file=/var/…/sts.googleapis.com/serviceaccount/token
--output-file=/var/…/sts.googleapis.com/serviceaccount/cred-config.json
env:
- name: GCP_WORKLOAD_IDENTITY_PROVIDER
value: "projects/…/providers/PROVIDER_ID"
- name: GCP_SERVICEACCOUNT_EMAIL
value: app-x@project.iam.gserviceaccount.com
volumeMounts:
- name: gcp-token
mountPath: /var/run/secrets/sts.googleapis.com/serviceaccount

39. 39
@everpeace
Azure SDKの設定の注入
Azure/azure-workload-identity をインストールすればやってくれます
# ServiceAccountにアプリケーションをannotationしておけば
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceaccount
namespace: default
labels:
### labelで明示的に azure workload identityを有効にする必要あり
azure.workload.identity/use: "true"
annotations:
azure.workload.identity/tenant-id: xxxxx
azure.workload.identity/client-id: yyyyy
### optional: sa tokenの期限を指定できます
azure.workload.identity/service-account-token-expiration: "3600"
# Podに必要な設定を注入してくれます
spec:
serviceAccountName: my-serviceaccount
volumes:
- name: azure-token
projected:
sources:
- serviceAccountToken: ### Azure用audienceにBoundされたSA Token Volume
audience: "api://AzureADTokenExchange"
expirationSeconds: 3600
path: token
containers:
- name: container-name
image: container-image:version
env:
- name: AZURE_FEDERATED_TOKEN_FILE # Azure向けaudience boundなSA Token File
value: /var/run/secrets/azure/tokens/token
- name: AZURE_AUTHORITY_HOST
value: "https://login.microsoftonline.com/"
- name: AZURE_TENANT_ID
value: "xxxxx"
- name: AZURE_CLIENT_ID
value: "yyyyy"
volumeMounts:
- mountPath: "/var/run/secrets/azure/tokens"
name: azure-token
Icons made by Freepik from www.flaticon.com

40. 40
完成🎉

41. 41
@everpeace
Kubernetes Service Account As Multi-Cloud Identity
Icons made by Freepik from www.flaticon.com
kube-apiserver
OIDC Discovery Endpoint
JWKS Endpoint
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
→オンプレ(他クラウド)
クラウド←
kube-apiserverの公開する
OIDC Discovery, JWKS Endpointの
内容を指定したIssuerのURLで
公開する(e.g.S3＆CloudFront)
Bound SA Tokenが
Cloud横断的にFederated Identity
として利用できる🎉
(各クラウドはTokenを検証可能)
各CloudでOIDC Providerとの
信頼関係を設定
service-account-issuer=
https://my.provider
Bound SA Token,Cloud SDK設定
注入用Mutating Webhookをデプロイ

42. 42
この方法における安全性と
セキュリティリスクを考える

43. 43
@everpeace
この方法における安全性
Icons made by Freepik from www.flaticon.com
kube-apiserver
OIDC Discovery Endpoint
JWKS Endpoint
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
→オンプレ(他クラウド)
クラウド←
service-account-issuer=
https://my.provider
アプリ開発者は
一度もクレデンシャル
を目にすることがない🙈
無期限なクレデンシャル
が存在しない🈚♾
めっちゃいい🎉

44. 44
@everpeace
Kubernetes Service Account
As Multi-Cloud Identityのリスク
Icons made by Freepik from www.flaticon.com
kube-apiserver
OIDC Discovery Endpoint
JWKS Endpoint
https://my.provider
OIDC Discovery Endpoint
JWKS Endpoint
→オンプレ(他クラウド)
クラウド←
service-account-issuer=
https://my.provider
OIDC Discovery, JWKS Endpointが
改変されたら、攻撃者が任意の
IDTokenを発行でき、クラウド側で
許可したRoleを取得できます。
このEndpointの変更権限を持つ
クレデンシャルは取扱厳重注意。
Bound SA Token署名用秘密鍵が
漏洩したら任意のSA権限が取得
できます。キーペアは厳重管理
&定期的にローテーションしま
しょう。
(ローテ後はJWKS更新必要です)
SA Token,各Cloudの一時クレデンシャル
は自動でローテーションされますが、
漏れたら有効期限内は利用される可能性
があるので注意しましょう。
(有効期限と更新回数のトレードオフ)
(各クラウドでのIP制限も有効です)
☠
☠
☠

45. 45
@everpeace
● AWS OIDC Authentication with SPIFFE | Square Corner Blog
○ Squareの事例
○ Kubernetes ServiceAccountではなくSPIFFIEを利用
○ SVID(SPIFFIE上のID)単位でAWSの認証を行っている
■ SPIFFIEの参照実装であるSPIREもOIDC Discoveryを提供していて
本セッションと同じようにそれをS3で公開する方法
(この事例ではCronJobでS3へのsyncをやっている)
Kubernetes Service Account以外のIdentity
を使ったFederationの事例

46. 46
@everpeace
● 従来のシークレットアクセスキー等を用いたCloud認証のアーキテクチャパターン
とそれらのセキュリティリスク・正しい運用の難しさをおさらい
● Managed KubernetesではIRSA/Workload Identity等の仕組みが完備されていて
○ アプリ開発者は一度もクレデンシャルを目にすることがなく🙈
○ 無期限なクレデンシャルが存在しない🈚♾
状況でCloudAPI認証ができている
● オンプレ(クラウド外)のKubernetesクラスタでも
○ Cloudが提供する外部OIDC ProviderとのIdentity Federation
○ Kubernetes Service Account Issuer Discovery
を組み合わせることで、
● Managed Kubernetesと同じくらいSecureに、Kubernetes Service Accountを
Multi-CloudなFederated Identityをとして利用できる仕組みを紹介しました󰢛
まとめ

47. Making the real world computable