SlideShare a Scribd company logo
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
@everpeace
Shingo OMURA / @everpeace
▶ Preferred Networks, Inc. / エンジニア
▶ 社内向けGPUクラスタの開発運用
▶ 社内クラスタ向けにkube-schedulerを拡張
▶ 主にkubernetes sig-schedulingで活動中
3
@everpeace
▶ Kubernetesクラスタ内での典型的なCloud API認証パターン
▶ 典型的な方法に潜むセキュリティリスクを考える
▶ Kubernetes ServiceAccount As Multi-Cloud Identity
▶ この方法における安全性とセキュリティリスクを考える
▶ Kubernetes ServiceAccount以外のIdentityを使った認証
▶ まとめ
Outline
4
@everpeace
扱う認証主体はKubernetes内で動くアプリ
Icons made by Freepik from www.flaticon.com
アプリケーション用のCloud API向け
クレデンシャルを扱います
AWS: アクセスキーID/シークレットアクセスキー
GCP: サービスアカウントキー
Azure: クライアントID/シークレット
5
Kubernetesクラスタ
でのCloud API認証パターン
~オンプレKubernetes編~
認証したいCloudとは別の
Cloudで動いてる場合もOk
6
@everpeace
クレデンシャルを含んだSecretをPodに注入する
マウント/環境変数
クレデンシャルを
Secretリソース
として保存
クレデンシャル
を発行
Icons made by Freepik from www.flaticon.com
GitOps
できない😰
7
@everpeace
Sealed Secrets を使う(GitOpsできる)
SealedSecret
Controllerで暗号化した
SealedSecret作成
マウント/環境変数
SealedSecret
からクレデンシャル
を復号してSecret
を自動作成
Icons made by Freepik from www.flaticon.com
Git管理可🎉
クレデンシャル
を発行
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
@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
従来の方法に潜む
セキュリティリスクを考える
11
@everpeace
従来の方法に潜むセキュリティリスクを考える
Icons made by Freepik from www.flaticon.com
典型的なアプリ向けクレデンシャル
は無期限(非常に長い)が多い☠
(AWS→無期限、GCP→無期限、Azure→最長2年)
漏洩時により悪用されやすく
被害が大きい
暗号/キー名(≠平文)での
運用ができており
漏洩機会は減らせている🉑
が、扱っているクレデンシャルが
無期限なので根本的な対策でない
無期限なアプリ向け
クレデンシャルを開発者が
管理してしまいやすい🧐
異動後・退職後も利用できて
しまう可能性
ローテーションが徹底されづらい
12
@everpeace
● そもそも秘密情報を扱うのに必要な運用
○ 秘密情報自体の権限管理
○ 監査/利用記録
○ 暗号化(生で保存しない)
○ etc.
● 無期限なクレデンシャル向けの運用
○ 定期的なローテーション(90日な規定が多い)
○ 不使用クレデンシャルの削除(90日な規定が多い)
○ IP制限(ローテーション漏れ・できない場合の緩和策として有効
クラウドププロバイダ、利用環境によっては実施が難しいことも)
○ etc.
参考: CIS AWS Foundations Benchmark 標準 - AWS Security Hub
無期限(長期間有効)なクレデンシャルは運用大変
各Cloudでの運用は可能だけど
正しく運用するのはかなり大変😰
Icons made by Freepik from www.flaticon.com
13
@everpeace
昨今、公開OSSライブラリが汚染されることによるクレデンシャルの外部漏洩リ
スクが高まっている☣
○ AWS認証情報が盗まれる2つのライブラリ改ざんについてまとめてみた
○ PyPIからAWS認証情報を窃取するPythonパッケージが複数見つかる
プライベートネットワークも安全ではない
(ソフトウェアサプライチェーン攻撃)
出典: AWS認証情報が盗まれる 2つのライブラリ改ざんに
ついてまとめてみた - piyolog
14
無期限なAPIクレデンシャルは
気軽に発行できて便利だけど
リスクをコントロールしながら
正しく運用するのは大変😰
15
Kubernetesクラスタ内
でのCloud API認証パターン
~Managed Kubernetes~
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
@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
@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
@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
@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
@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
こういうのって
🙋オンプレでもできる❓
🎉出来ます🎉
23
Kubernetes Service Account
As Multi-Cloud Identity
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
@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
🛠使う道具は2つ
(実はIRSAとほぼ同じ仕組み)
○ 各Cloudの外部OIDC ProviderとのID Federation
○ Kubernetes ServiceAccountIssuerDiscovery
(v1.21以降デフォルトで有効)
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
@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
@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
@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
@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
各CloudでOIDC Providerとの
信頼関係を設定する
Icons made by Freepik from www.flaticon.com
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
@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
@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
ワークロードへの
Bound SA Token,Cloud SDK設定
の注入
Icons made by Freepik from www.flaticon.com
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
@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
@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
@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
完成🎉
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
この方法における安全性と
セキュリティリスクを考える
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
@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
@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
@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をとして利用できる仕組みを紹介しました󰢛
まとめ
Making the real world computable

More Related Content

What's hot

コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
NTT DATA Technology & Innovation
 
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
Recruit Lifestyle Co., Ltd.
 
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
Amazon Web Services Japan
 
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
Toru Makabe
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
 
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Kohei Tokunaga
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
 
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
Katsuya Yamaguchi
 
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
Google Cloud Platform - Japan
 
Ingress on Azure Kubernetes Service
Ingress on Azure Kubernetes ServiceIngress on Azure Kubernetes Service
Ingress on Azure Kubernetes Service
Toru Makabe
 
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
NTT DATA Technology & Innovation
 
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container ServiceAWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
Amazon Web Services Japan
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
dcubeio
 
DevOps with Database on AWS
DevOps with Database on AWSDevOps with Database on AWS
DevOps with Database on AWS
Amazon Web Services Japan
 
20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh
Amazon Web Services Japan
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
 

What's hot (20)

コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
コンテナとimmutableとわたし。あとセキュリティ。(Kubernetes Novice Tokyo #15 発表資料)
 
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
 
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
 
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
細かすぎて伝わらないかもしれない Azure Container Networking Deep Dive
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動するStargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
 
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
株式会社コロプラ『GKE と Cloud Spanner が躍動するドラゴンクエストウォーク』第 9 回 Google Cloud INSIDE Game...
 
Ingress on Azure Kubernetes Service
Ingress on Azure Kubernetes ServiceIngress on Azure Kubernetes Service
Ingress on Azure Kubernetes Service
 
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
IAM Roles Anywhereのない世界とある世界(2022年のAWSアップデートを振り返ろう ~Season 4~ 発表資料)
 
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container ServiceAWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
 
DevOps with Database on AWS
DevOps with Database on AWSDevOps with Database on AWS
DevOps with Database on AWS
 
20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh20200721 AWS Black Belt Online Seminar AWS App Mesh
20200721 AWS Black Belt Online Seminar AWS App Mesh
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 

Similar to Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Conference 2022 / #CNSec2022

20180313 Amazon Container Services アップデート
20180313 Amazon Container Services アップデート20180313 Amazon Container Services アップデート
20180313 Amazon Container Services アップデート
Amazon Web Services Japan
 
AWS Black Belt Online Seminar 2017 AWS Cognito
AWS Black Belt Online Seminar 2017 AWS CognitoAWS Black Belt Online Seminar 2017 AWS Cognito
AWS Black Belt Online Seminar 2017 AWS Cognito
Amazon Web Services Japan
 
Scale Your Business without Servers
Scale Your Business without ServersScale Your Business without Servers
Scale Your Business without Servers
Keisuke Nishitani
 
AWS_reInforce_2022_reCap_Ja.pdf
AWS_reInforce_2022_reCap_Ja.pdfAWS_reInforce_2022_reCap_Ja.pdf
AWS_reInforce_2022_reCap_Ja.pdf
Hayato Kiriyama
 
20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito
Amazon Web Services Japan
 
20191125 Container Security
20191125 Container Security20191125 Container Security
20191125 Container Security
Amazon Web Services Japan
 
[AWSマイスターシリーズ] AWS SDK for Java / .NET
[AWSマイスターシリーズ] AWS SDK for Java / .NET[AWSマイスターシリーズ] AWS SDK for Java / .NET
[AWSマイスターシリーズ] AWS SDK for Java / .NET
Amazon Web Services Japan
 
Getting Started With AKS
Getting Started With AKSGetting Started With AKS
Getting Started With AKS
Balaji728392
 
20120528 aws meister-reloaded-awssd-kforjava-public
20120528 aws meister-reloaded-awssd-kforjava-public20120528 aws meister-reloaded-awssd-kforjava-public
20120528 aws meister-reloaded-awssd-kforjava-public
Amazon Web Services Japan
 
Azure AD によるリソースの保護 how to protect and govern resources under the Azure AD
Azure AD によるリソースの保護 how to protect and govern resources under the Azure ADAzure AD によるリソースの保護 how to protect and govern resources under the Azure AD
Azure AD によるリソースの保護 how to protect and govern resources under the Azure AD
junichi anno
 
S3 Client-Side Encryption by AWS SDK for Java/Ruby
S3 Client-Side Encryption by AWS SDK for Java/RubyS3 Client-Side Encryption by AWS SDK for Java/Ruby
S3 Client-Side Encryption by AWS SDK for Java/Ruby
真吾 吉田
 
20210119 AWS Black Belt Online Seminar AWS CloudTrail
20210119 AWS Black Belt Online Seminar AWS CloudTrail20210119 AWS Black Belt Online Seminar AWS CloudTrail
20210119 AWS Black Belt Online Seminar AWS CloudTrail
Amazon Web Services Japan
 
AWS Black Belt Techシリーズ AWS SDK
AWS Black Belt Techシリーズ AWS SDKAWS Black Belt Techシリーズ AWS SDK
AWS Black Belt Techシリーズ AWS SDK
Amazon Web Services Japan
 
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
Junji Nishihara
 
これからのクラウドネイティブアプリケーションの話をしよう
これからのクラウドネイティブアプリケーションの話をしようこれからのクラウドネイティブアプリケーションの話をしよう
これからのクラウドネイティブアプリケーションの話をしよう
真吾 吉田
 
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
[Cloud OnAir] Cloud Run Deep Dive  ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...[Cloud OnAir] Cloud Run Deep Dive  ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
Google Cloud Platform - Japan
 
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
SORACOM, INC
 
[AWS Developers Meetup 2017] Developerのための ライブAWSウォークスルー 〜 AWS SDKの使い方 〜
[AWS Developers Meetup 2017] DeveloperのためのライブAWSウォークスルー 〜 AWS SDKの使い方 〜[AWS Developers Meetup 2017] DeveloperのためのライブAWSウォークスルー 〜 AWS SDKの使い方 〜
[AWS Developers Meetup 2017] Developerのための ライブAWSウォークスルー 〜 AWS SDKの使い方 〜
Atsushi Fukui
 
AWS as MBaaS 〜APIキーとかの話〜
AWS as MBaaS 〜APIキーとかの話〜AWS as MBaaS 〜APIキーとかの話〜
AWS as MBaaS 〜APIキーとかの話〜
Yuki Hirai
 
The Usage and Patterns of MagicOnion
The Usage and Patterns of MagicOnionThe Usage and Patterns of MagicOnion
The Usage and Patterns of MagicOnion
Yoshifumi Kawai
 

Similar to Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Conference 2022 / #CNSec2022 (20)

20180313 Amazon Container Services アップデート
20180313 Amazon Container Services アップデート20180313 Amazon Container Services アップデート
20180313 Amazon Container Services アップデート
 
AWS Black Belt Online Seminar 2017 AWS Cognito
AWS Black Belt Online Seminar 2017 AWS CognitoAWS Black Belt Online Seminar 2017 AWS Cognito
AWS Black Belt Online Seminar 2017 AWS Cognito
 
Scale Your Business without Servers
Scale Your Business without ServersScale Your Business without Servers
Scale Your Business without Servers
 
AWS_reInforce_2022_reCap_Ja.pdf
AWS_reInforce_2022_reCap_Ja.pdfAWS_reInforce_2022_reCap_Ja.pdf
AWS_reInforce_2022_reCap_Ja.pdf
 
20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito
 
20191125 Container Security
20191125 Container Security20191125 Container Security
20191125 Container Security
 
[AWSマイスターシリーズ] AWS SDK for Java / .NET
[AWSマイスターシリーズ] AWS SDK for Java / .NET[AWSマイスターシリーズ] AWS SDK for Java / .NET
[AWSマイスターシリーズ] AWS SDK for Java / .NET
 
Getting Started With AKS
Getting Started With AKSGetting Started With AKS
Getting Started With AKS
 
20120528 aws meister-reloaded-awssd-kforjava-public
20120528 aws meister-reloaded-awssd-kforjava-public20120528 aws meister-reloaded-awssd-kforjava-public
20120528 aws meister-reloaded-awssd-kforjava-public
 
Azure AD によるリソースの保護 how to protect and govern resources under the Azure AD
Azure AD によるリソースの保護 how to protect and govern resources under the Azure ADAzure AD によるリソースの保護 how to protect and govern resources under the Azure AD
Azure AD によるリソースの保護 how to protect and govern resources under the Azure AD
 
S3 Client-Side Encryption by AWS SDK for Java/Ruby
S3 Client-Side Encryption by AWS SDK for Java/RubyS3 Client-Side Encryption by AWS SDK for Java/Ruby
S3 Client-Side Encryption by AWS SDK for Java/Ruby
 
20210119 AWS Black Belt Online Seminar AWS CloudTrail
20210119 AWS Black Belt Online Seminar AWS CloudTrail20210119 AWS Black Belt Online Seminar AWS CloudTrail
20210119 AWS Black Belt Online Seminar AWS CloudTrail
 
AWS Black Belt Techシリーズ AWS SDK
AWS Black Belt Techシリーズ AWS SDKAWS Black Belt Techシリーズ AWS SDK
AWS Black Belt Techシリーズ AWS SDK
 
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
"Kong Summit, Japan 2022" パートナーセッション:Kong on AWS で実現するスケーラブルな API 基盤の構築
 
これからのクラウドネイティブアプリケーションの話をしよう
これからのクラウドネイティブアプリケーションの話をしようこれからのクラウドネイティブアプリケーションの話をしよう
これからのクラウドネイティブアプリケーションの話をしよう
 
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
[Cloud OnAir] Cloud Run Deep Dive  ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...[Cloud OnAir] Cloud Run Deep Dive  ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月...
 
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
IAM & Consolidated Billing -ほぼ週刊AWSマイスターシリーズ第4回
 
[AWS Developers Meetup 2017] Developerのための ライブAWSウォークスルー 〜 AWS SDKの使い方 〜
[AWS Developers Meetup 2017] DeveloperのためのライブAWSウォークスルー 〜 AWS SDKの使い方 〜[AWS Developers Meetup 2017] DeveloperのためのライブAWSウォークスルー 〜 AWS SDKの使い方 〜
[AWS Developers Meetup 2017] Developerのための ライブAWSウォークスルー 〜 AWS SDKの使い方 〜
 
AWS as MBaaS 〜APIキーとかの話〜
AWS as MBaaS 〜APIキーとかの話〜AWS as MBaaS 〜APIキーとかの話〜
AWS as MBaaS 〜APIキーとかの話〜
 
The Usage and Patterns of MagicOnion
The Usage and Patterns of MagicOnionThe Usage and Patterns of MagicOnion
The Usage and Patterns of MagicOnion
 

More from Preferred Networks

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
Preferred Networks
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Preferred Networks
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Preferred Networks
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
Preferred Networks
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Preferred Networks
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
Preferred Networks
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Preferred Networks
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
Preferred Networks
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
Preferred Networks
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Preferred Networks
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Preferred Networks
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
Preferred Networks
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
Preferred Networks
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
Preferred Networks
 
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50
Preferred Networks
 
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
Preferred Networks
 

More from Preferred Networks (20)

PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
PodSecurityPolicy からGatekeeper に移行しました / Kubernetes Meetup Tokyo #57
 
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
 
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
PFNのオンプレ計算機クラスタの取り組み_第55回情報科学若手の会
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
 
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
独断と偏見で選んだ Kubernetes 1.24 の注目機能と今後! / Kubernetes Meetup Tokyo 50
 
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50
 
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
 

Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Conference 2022 / #CNSec2022

  • 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/シークレット
  • 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
  • 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
  • 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
  • 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 🛠使う道具は2つ (実は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
  • 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
  • 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をデプロイ
  • 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