Closed7
podidentityを試してみる
- namespace「test」に存在するpodからs3を操作する
- s3操作権限はpod identityで与える
エージェントのセットアップ
アドオン名
$ aws eks describe-addon-versions | jq -r '.addons[].addonName' | grep -i identity
eks-pod-identity-agent
利用可能バージョン
$ aws eks describe-addon-versions --addon-name eks-pod-identity-agent | jq -r '.addons[].addonVersions[].addonVersion'
v1.3.0-eksbuild.1
v1.2.0-eksbuild.1
v1.1.0-eksbuild.1
v1.0.0-eksbuild.1
terraform
resource "aws_eks_addon" "pod-identity-agent" {
cluster_name = aws_eks_cluster.main.name
addon_name = "eks-pod-identity-agent"
addon_version = "v1.3.0-eksbuild.1"
}
確認
$ kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
eks-pod-identity-agent-8lgcz 1/1 Running 0 6m15s
IAMroleをサービスアカウントに割り当てる
IAMロール作成
ロールの信頼ポリシーは
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
のように
あとはs3のポリシーをつける
data "aws_iam_policy_document" "assume_role" {
statement {
effect = "Allow"
principals {
type = "Service"
identifiers = ["pods.eks.amazonaws.com"]
}
actions = [
"sts:AssumeRole",
"sts:TagSession"
]
}
}
resource "aws_iam_role" "example" {
name = "eks-pod-identity-example"
assume_role_policy = data.aws_iam_policy_document.assume_role.json
}
resource "aws_iam_role_policy_attachment" "example_s3" {
policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
role = aws_iam_role.example.name
}
EKS Pod Identity の関連付けの作成
resource "aws_eks_pod_identity_association" "example" {
cluster_name = aws_eks_cluster.main.name
namespace = "test"
service_account = "test"
role_arn = aws_iam_role.example.arn
}
コンソールから確認できる
動作確認
テスト用リソース
podidentityで指定したnamespace/serviceaccountとともにdeploymentを用意する
---
apiVersion: v1
kind: Namespace
metadata:
name: test
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: test
namespace: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: awscli
namespace: test
spec:
selector:
matchLabels:
app: awscli
template:
metadata:
labels:
app: awscli
spec:
serviceAccountName: test
containers:
- name: aws-cli
image: public.ecr.aws/aws-cli/aws-cli:2.17.37
command: ["sleep", "infinity"]
中に入って確認
bash-4.2# aws s3 ls
xxx
yyy
zzz
OK
podのdescribeを見ると
このようにサービスアカウントトークンのファイルがマウントされていることを確認できる
│ AWS_CONTAINER_CREDENTIALS_FULL_URI: http://169.254.170.23/v1/credentials │
│ AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
EKS Pod Identity の関連付けを削除して動作確認
-resource "aws_eks_pod_identity_association" "example" {
- cluster_name = aws_eks_cluster.main.name
- namespace = "test"
- service_account = "test"
- role_arn = aws_iam_role.example.arn
-}
もう一度aws s3 lsをする
bash-4.2# aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/eks-worker-role/i-06ddbdc7f673ea9a0 is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action
OK
awscliのバージョンが古い場合
このように出てくる
bash-4.2# aws --version
aws-cli/2.7.21 Python/3.9.11 Linux/5.10.223-211.872.amzn2.x86_64 docker/x86_64.amzn.2 prompt/off
bash-4.2# aws s3 ls
Unsupported host '169.254.170.23'. Can only retrieve metadata from these hosts: 169.254.170.2, localhost, 127.0.0.1
EKS Pod Identity エージェントはデフォルトでポッドが認証情報をリクエストするために IPv4 と IPv6 のアドレスをリッスンします。エージェントは、IPv4 のループバック (localhost) IP アドレス 169.254.170.23 と IPv6 の localhost IP アドレス [fd00:ec2::23] を使用します。
割と新し目の機能であるため、対応していないバージョンのawscli/各種SDKに注意
所感
- IRSAと比較してserviceaccountにiam roleのarnを書く必要がない、楽
- IRSAと比較してIAMロールの信頼ポリシーをシンプルに出来る、楽
このスクラップは2ヶ月前にクローズされました