Amazon Web Services ブログ
詳解: IAM Roles for Service Accounts
この記事は Diving into IAM Roles for Service Accounts (記事公開日: 2022 年 2 月 28 日) を翻訳したものです。
AWS 上で Kubernetes ソリューションを設計するときにアーキテクトが直面するよくある課題は、コンテナ化したワークロードに対して、AWS サービスやリソースへのアクセス許可をどのように付与するのかという課題です。AWS Identity and Access Management (IAM) は、最小権限の原則を保証するために、誰がどの AWS サービスやリソースにアクセスできるかを指定できるきめ細かいアクセス制御を提供します。しかしながら、ワークロードが Kubernetes で実行されている場合の課題は、IAM が認証に使用できる ID を Kubernetes ワークロードに提供することです。
2019 年、AWS は IAM Roles for Service Accounts (IRSA、サービスアカウントの IAM ロール) を導入し、AWS Identity API、OpenID Connect (OIDC) ID プロバイダー、Kubernetes Service Account (サービスアカウント) を活用し、Kubernetes Pod にきめ細かいアクセス制御を適用できるようになりました。詳しくは、IRSA ローンチブログ (日本語訳) を参照してください。
この記事では、IAM Roles for Service Accounts について深く掘り下げます。さまざまな要素がどのように組み合わされ、舞台裏で実際に何が起こっているのかを理解するのに役立ちます。
ウォークスルー
このウォークスルーでは、AWS サービスやリソースへのアクセスを獲得するためにどのように Kubernetes Service Account を活用できるのか、その道のりやコンセプトを紹介します。Amazon S3 にアクセスするために、Amazon EKS クラスター上で多数の Kubernetes Pod を起動します。
前提条件
- Amazon Web Services (AWS) の有効なアカウント
- AWS コマンドラインインターフェース (AWS CLI) バージョン 2 以降: macOS、Linux、または Windows にインストールおよび設定されている必要があります。EKS クラスターを作成したり IAM ロールを作成したりするための IAM 権限 が必要です。
- kubectl コマンドラインユーティリティ: Amazon EKS クラスターにアクセスするためにインストールおよび設定されている必要があります。これについての詳細は、Amazon EKS のドキュメントの kubectl のインストールを参照してください。
- eksctl コマンドラインユーティリティ (バージョン 0.5.0 以降): インストールの詳細については、このドキュメントを参照してください。
- jq コマンドラインツール: json をパースします。
- jwt-cli: JSON Web Token をデコードします。
手順の詳細
まずは EKS クラスターを作成しましょう。
$ eksctl create cluster \
--name eks-oidc-demo \
--region us-east-2次に、Pod 内のワークロードが終了しても Pod の再起動を試みないように、restartPolicy を設定した Kubernetes Pod を 1 つ作成します。Kubernetes Pod は amazon/aws-cli コンテナイメージを活用し、Pod 内で aws s3 list コマンドを実行します。
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test1
spec:
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
args: ['s3', 'ls']
restartPolicy: Never
EOFkubectl get pod コマンドを使用して、Pod が実行されたことが確認できます。しかし、エラーで終了しています。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
eks-iam-test1 0/1 Error 0 37sログを見ると、根本原因がわかります。ListBuckets API を呼び出す際に、Access Denied エラーが発生しています (これはこの段階では想定通りです) 。
$ kubectl logs eks-iam-test1
An error occurred (AccessDenied) when calling the ListBuckets operation: Access DeniedAWS マネジメントコンソールの AWS CloudTrail コンソールを確認すると、このエラーについてさらに詳細な情報を得ることができます。S3 バケットをリストしようとしているので、Event name を “ListBuckets” として、CloudTrail イベントをフィルタリングしましょう。
CloudTrail のログから ListBuckets イベントを選択してイベントログを開くと、以下のような出力が表示されます。
出力の userIdentity セクションで、Kubernetes Pod で実行されているワークロードが Amazon EC2 インスタンスにアタッチされた IAM ロールを引き受け、このロールを活用して S3 バケットをリストしようとしていることがわかります。これは、コンテナ内に他の AWS 認証情報が見つからなかったためで、Python boto3 SDK のドキュメントに記載されているように、SDK はインスタンスメタデータサービスにフォールバックしました。
EC2 インスタンスプロファイル内の IAM ロールが S3 バケットをリストするのに必要な権限を持っていないため、コマンドは “Access Denied” エラーを受け取りました。これを解決する 1 つの方法は、EC2 インスタンスプロファイルに追加のアクセス許可を付与することです。ただし、これはセキュリティの重要な原則である最小権限の原則に反します。この追加のアクセス許可は、Kubernetes Pod レベルではなく、EC2 ノードレベルで行われます。したがって、そのノード上で実行されているすべての Pod は、私たちの S3 バケットにアクセスできるようになります。私たちはこの権限を Pod レベルに制限したいのです。
これが次の問いにつながります。コンテナが EC2 インスタンスプロファイルをデフォルトにしないように、AWS 認証情報をコンテナに注入するにはどうしたらよいでしょうか。Kubernetes Secret や環境変数を介して AWS 認証情報を注入することは安全ではなく、ユーザーはこれらの認証情報のライフサイクルを管理する必要があります。AWS は、これらのアプローチのいずれもお勧めしません。
Kubernetes Service Account
Kubernetes Pod は、Kubernetes Service Account と呼ばれる Kubernetes のコンセプトを通じて ID が付与されます。Service Account が作成されると、JWT トークンが Kubernetes Secret として自動的に作成されます。この Secret を Pod にマウントし、Secret 内の Service Account の JWT トークンを Kubernetes API サーバーの認証に使用することができます。
$ kubectl get sa
NAME SECRETS AGE
default 1 23h$ kubectl describe sa default
Name: default
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: default-token-8j54j
Tokens: default-token-8j54j
Events: <none>残念ながら、このデフォルトのトークンにはいくつかの問題があり、IAM 認証には使用できません。まず、このトークンを検証できるのは Kubernetes API サーバーのみです。次に、これらの Service Account トークンには有効期限がなく、署名キーのローテーションは難易度の高いプロセスです。Secret を取得して jwt-cli ツールに渡すことで、トークンを表示することができます。
$ kubectl get secret default-token-m4tdn -o json | jq -r '.data.token' | base64 -d | jwt decode --json -
{
"header": {
"alg": "RS256",
"kid": "LflWmdoop8Xt5sUnBFTmCLX0B8MnS1kcPSUcyjr8npw"
},
"payload": {
"iss": "kubernetes/serviceaccount",
"kubernetes.io/serviceaccount/namespace": "default",
"kubernetes.io/serviceaccount/secret.name": "default-token-m4tdn",
"kubernetes.io/serviceaccount/service-account.name": "default",
"kubernetes.io/serviceaccount/service-account.uid": "5af7481a-2c9c-4613-9266-1037a23961a4",
"sub": "system:serviceaccount:default:default"
}
}Kubernetes 1.12 では、Service Account Token Volume Projection という機能が導入されました。この機能により、Kubernetes の TokenRequest API で発行された OIDC 完全準拠 の JWT トークンを、Projected Volume として Pod にマウントすることができます。バージョン 1.21 以降の EKS クラスターでは、この機能に関連する BoundServiceAccountTokenVolume フィーチャーフラグがデフォルトで有効になっています。そのため、前の段落で説明した Service Account の作成時に Secret として自動的に作成される JWT トークンではなく、OIDC 完全準拠の JWT Service Account トークンが各 Pod に投影されています。
この OIDC トークンを検査するために、以下のコマンドを使用して、内部に sleep プロセスを持つ Pod を新規に作成しましょう。
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test2
spec:
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
EOF特定の Kubernetes Service Account を指定していないので、デフォルト (default) の Service Account が使用され、その Service Account 用の OIDC トークンが生成され、Pod にマウントされます。
トークンを取得して展開することで、OIDC に完全準拠したトークンを表示することができます。
$ SA_TOKEN=$(kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
$ jwt decode $SA_TOKEN --json --iso8601
{
"header": {
"alg": "RS256",
"kid": "689de1734321bcfdfbef825503a5ead235981e7a"
},
"payload": {
"aud": [
"https://kubernetes.default.svc"
],
"exp": "2023-02-18T16:37:58+00:00",
"iat": "2022-02-18T16:37:58+00:00",
"iss": "https://oidc.eks.us-east-2.amazonaws.com/id/xxxx",
"kubernetes.io": {
"namespace": "default",
"pod": {
"name": "eks-iam-test2",
"uid": "cd953361-41a2-4de0-b799-51f169920741"
},
"serviceaccount": {
"name": "default",
"uid": "5af7481a-2c9c-4613-9266-1037a23961a4"
},
"warnafter": 1645205885
},
"nbf": "2022-02-18T16:37:58+00:00",
"sub": "system:serviceaccount:default:default"
}
}この JWT のペイロードを見ればわかるように、発行元 (Issuer, iss) は OIDC プロバイダーです。トークンの対象者 (Audience, aud) は https://kubernetes.default.svc です。これは、Kubernetes API サーバーへのアクセスに使用されるクラスター内のアドレスです。
セキュリティ上の理由から、Pod 内のワークロードが Kubernetes API サーバーへの呼び出しを行わない場合は、Kubernetes Pod にトークンを含めたくないかもしれません。これは、Pod を作成する際に PodSpec に automountServiceAccountToken: false を渡すことで実現可能です。
この OIDC 準拠のトークンは、AWS API の認証に使用できるトークンを見つけるための基礎を提供します。ただし、AWS API で使用するための第 2 のトークンを Kubernetes Pod に注入するには、追加コンポーネントが必要です。Kubernetes は Validating Webhook と Mutating Webhook をサポートしており、AWS は EKS クラスターにプリインストールされる Pod Identity Webhook を作成しました。この Webhook は Create Pod API コールをリッスンし、Pod に追加のトークンを注入できます。この Webhook は、このガイドを使用して、AWS 上のセルフマネージドな Kubernetes クラスターにインストールすることも可能です。
Webhook で Pod に新しいトークンを注入するために、新しい Kubernetes Service Account を作成し、AWS IAM ロールの ARN を Service Account にアノテーション (Annotations) として付与します。そして Kubernetes Pod でこの新しい Kubernetes Service Account を参照します。eksctl ツールを使用するといくつかの手順を自動化できますが、これらの手順をすべて手動で実行することもできます。
eksctl create iamserviceaccount コマンドは、以下を作成します。
- Kubernetes Service Account
- 指定の IAM ポリシーがアタッチされた IAM ロール
- その IAM ロールの信頼ポリシー
最後に、作成した IAM ロールの ARN を Kubernetes Service Account にアノテーションとして付与します。
なお、Service Account を作成する前には、IAM OIDC プロバイダーを関連付ける必要があります。
$ eksctl utils associate-iam-oidc-provider --region=us-east-2 --cluster=eks-oidc-demo --approve$ eksctl create iamserviceaccount \
--name my-sa \
--namespace default \
--cluster eks-oidc-demo \
--approve \
--attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text) 新しく作成された Kubernetes Service Account を調べると、Pod で引き受けようとしている IAM ロールを確認できます。
$ kubectl describe sa my-sa
Name: my-sa
Namespace: default
Labels: app.kubernetes.io/managed-by=eksctl
Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::xxxx:role/eksctl-eks-oidc-demo-addon-iamserviceaccount-Role1-H47XCR6FPRGQ
Image pull secrets: <none>
Mountable secrets: my-sa-token-kv6kc
Tokens: my-sa-token-kv6kc
Events: <none>この IAM ロールが AWS マネジメントコンソール内でどのように見えるか確認しましょう。IAM > Roles に移動して、ロールを検索します。Service Account の Annotations フィールドを確認してください。
AmazonS3ReadOnlyAccess ポリシーがこのロールにアタッチされていることがわかります。
Trust relationships タブを選択し、Edit trust policy を選択してポリシードキュメントを表示します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/xxxx"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-2.amazonaws.com/id/xxxx:aud": "sts.amazonaws.com",
"oidc.eks.us-east-2.amazonaws.com/id/xxxx:sub": "system:serviceaccount:default:my-sa"
}
}
}
]
}このポリシーは、ID system:serviceaccount:default:my-sa が sts:AssumeRoleWithWebIdentity アクションを使用してロールを引き受けることを許可していることがわかります。このポリシーのプリンシパルは、OIDC プロバイダーです。
次に、Kubernetes Pod 内でこの新しい Service Account を使用するとどうなるかを見てみましょう。
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test3
spec:
serviceAccountName: my-sa
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
EOFkubectl と jq を使用して Pod を検査すると、Pod に 2 つのボリュームがマウントされていることがわかります。2 つ目は、Mutating Webhook を介してマウントされています。aws-iam-token は引き続き Kubernetes API サーバーによって生成されていますが、新しい OIDC JWT 対象者 (Audience) が使用されています。
$ kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].volumeMounts'
[
{
"mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
"name": "kube-api-access-p2dlk",
"readOnly": true
},
{
"mountPath": "/var/run/secrets/eks.amazonaws.com/serviceaccount",
"name": "aws-iam-token",
"readOnly": true
}
]
$ kubectl get pod eks-iam-test3 -o json | jq -r '.spec.volumes[] | select(.name=="aws-iam-token")'
{
"name": "aws-iam-token",
"projected": {
"defaultMode": 420,
"sources": [
{
"serviceAccountToken": {
"audience": "sts.amazonaws.com",
"expirationSeconds": 86400,
"path": "token"
}
}
]
}
}実行中の Pod に exec してこのトークンを検査すると、前に見た Service Account トークンとは少し異なって見えることがわかります。
$ IAM_TOKEN=$(kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token)
$ jwt decode $IAM_TOKEN --json --iso8601
{
"header": {
"alg": "RS256",
"kid": "689de1734321bcfdfbef825503a5ead235981e7a"
},
"payload": {
"aud": [
"sts.amazonaws.com"
],
"exp": "2022-02-19T16:43:55+00:00",
"iat": "2022-02-18T16:43:55+00:00",
"iss": "https://oidc.eks.us-east-2.amazonaws.com/id/xxxx",
"kubernetes.io": {
"namespace": "default",
"pod": {
"name": "eks-iam-test3",
"uid": "6fd2f65f-4554-4317-9343-c8e5d28029c3"
},
"serviceaccount": {
"name": "my-sa",
"uid": "2c935d89-3ff0-425d-85c2-8236a6d626aa"
}
},
"nbf": "2022-02-18T16:43:55+00:00",
"sub": "system:serviceaccount:default:my-sa"
}
}このトークンの対象者 (aud) は sts.amazonaws.com となり、このトークンを作成して署名した発行者 (iss) は引き続き OIDC プロバイダーとなっています。そして、トークンの有効期限は 24 時間とはるかに短くなっています。Pod の定義や Service Account の定義で eks.amazonaws.com/token-expiration アノテーションを使用して、Service Account トークンの有効期限を変更できます。
Mutating Webhook は、Pod に追加のトークンをマウントするだけではありません。Mutating Webhook は環境変数も注入します。
$ kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].env'
[
{
"name": "AWS_DEFAULT_REGION",
"value": "us-east-2"
},
{
"name": "AWS_REGION",
"value": "us-east-2"
},
{
"name": "AWS_ROLE_ARN",
"value": "arn:aws:iam::111122223333:role/eksctl-eks-oidc-demo-addon-iamserviceaccount-Role1-1SJZ3F7H39X72"
},
{
"name": "AWS_WEB_IDENTITY_TOKEN_FILE",
"value": "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"
}
]これらの環境変数は、Web Identity からロールを引き受ける際に AWS SDK や CLI によって使用されます。例について、Python boto3 SDK を参照してください。ワークロードの SDK は、EC2 インスタンスプロファイルにある認証情報を使用する代わりに、これらの認証情報を使用します。
デフォルトでは、Mutating Webhook は SDK にリージョナル STS エンドポイントを使用するように指示しません。代わりに、 デフォルトでグローバルなレガシーエンドポイントを使用します。AWS は、Service Account にアノテーション eks.amazonaws.com/sts-regional-endpoints: "true" を追加することを推奨します。これにより、ワークロードに環境変数 AWS_STS_REGIONAL_ENDPOINTS=regional が注入されます。詳細については、ドキュメントをご覧ください。この動作は、将来の EKS プラットフォームリリースではデフォルトとなる予定です (訳注: EKS 1.22 以降でデフォルトとなります) 。
ワークロードが IAM で認証を試みるために使用できるトークンができたので、次のパートは AWS IAM にこれらのトークンを信頼させることです。AWS IAM は、OIDC ID プロバイダーを使用したフェデレーション ID をサポートしています。この機能により、IAM は有効な OIDC JWT を受け取った後、サポートされている ID プロバイダーで AWS API コールを認証することができます。このトークンを AWS STS AssumeRoleWithWebIdentity API オペレーションに渡すことで、一時的な IAM 認証情報を取得することができます。
Kubernetes ワークロードが持っている OIDC JWT トークンは署名、暗号化されており、AWS STS AssumeRoleWithWebIdentity API オペレーションが一時的な認証情報を送信する前に、IAM はこれらのトークンを信頼して検証する必要があります。Kubernetes の Service Account 発行者検出 (Service Account Issuer Discovery) 機能の一部として、EKS は公開 OpenID プロバイダー設定ドキュメント (Discovery エンドポイント) とトークン署名を検証するための公開鍵 (JSON Web Key Sets – JWKS) を https://OIDC_PROVIDER_URL/.well-known/openid-configuration でホスティングしています。
このエンドポイントを見てみましょう。aws eks describe-cluster コマンドで OIDC プロバイダーの URL を取得できます。
$ IDP=$(aws eks describe-cluster --name eks-oidc-demo --query cluster.identity.oidc.issuer --output text)
# Reach the Discovery Endpoint
$ curl -s $IDP/.well-known/openid-configuration | jq -r '.'
{
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/xxxx",
"jwks_uri": "https://oidc.eks.us-east-2.amazonaws.com/id/xxxx/keys",
"authorization_endpoint": "urn:kubernetes:programmatic_authorization",
"response_types_supported": [
"id_token"
],
"subject_types_supported": [
"public"
],
"claims_supported": [
"sub",
"iss"
],
"id_token_signing_alg_values_supported": [
"RS256"
]
}上記の出力では、JWKS (JSON Web Key set) フィールドを確認できます。このフィールドには、JWT (JSON Web Token) の検証に使用する公開鍵を含むキーのセットが含まれています。JWKS のプロパティの詳細については、ドキュメントを参照してください。
$ curl -s $IDP/keys | jq -r '.'
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"kid": "b12d2f264e3eb3036bde33008066f24f9eafa28e",
"alg": "RS256",
"n": "xxx"
},
...
]
}IAM サービスは、これらの公開鍵を使用してトークンを検証します。ワークフローは以下の通りです。
Pod からのトークンを受け取るには、IAM と OIDC プロバイダーの間に信頼関係が確立されている必要があります。この記事では、Service Account 作成の際に IAM OIDC プロバイダーを関連付けているので、この信頼関係は既に確立されているはずです。
そうでない場合は、以下の手順で手動で設定することも可能です。手動で信頼関係を作成するには、AWS コンソールで IAM > Identity Providers に移動し、ID プロバイダーを追加します。
- Provider type として、OpenID Connect を選択します。
- Provider URL は
https://oidc.eks.eu-west-1.amazonaws.com/id/xxxxを指定します。 - Get Thumbprint を選択します。
- 対象者 (Audience) は
sts.amazonaws.comとします。 - Add provider を選択します。
これで、Kubernetes Pod でトークンを使用して、Amazon S3 API で認証できます。
$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test4
spec:
serviceAccountName: my-sa
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
args: ["s3", "ls"]
restartPolicy: Never
EOF数秒後、Pod が正常に完了したことが確認できます。Pod のログを確認すると、S3 バケットが表示されるはずです。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
eks-iam-test4 0/1 Completed 0 83s$ kubectl logs eks-iam-test4
<s3 bucket list>クリーンアップ
今後の課金を避けるために、eksctl を使用して EKS クラスターを削除しましょう。
eksctl delete cluster \
--name eks-oidc-demo \
--region us-east-2まとめ
この旅を楽しんでいただき、Pod から AWS サービスにアクセスしようとするときに舞台裏で実際に何が起こっているのか、理解していただけていれば幸いです。ワークロードが AWS 認証情報を見つけられない場合に EC2 インスタンスプロファイルがデフォルトとされる動作と、Kubernetes Service Account と Service Account トークンを使用して Pod にアイデンティティを与える方法を確認しました。最後に、IAM が外部の OIDC ID プロバイダーとトークンを使用して、一時的な IAM 認証情報を提供する方法を確認しました。
さらなる詳細については、以下をご確認ください。
- IAM Roles for Service Accounts については、ドキュメントを参照してください。
- Amazon EKS Pod Identity Webhook については、GitHub リポジトリを参照してください。
- Amazon EKS の全ての機能とサービスのロードマップについては、公開ロードマップを参照してください。
翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。