从EKS集群调用AWS Pinpoint API出现Access Denied错误求助

核心原因分析 #

你的IAM角色权限策略中配置的Condition条件不匹配EKS Pod通过IRSA（IAM Roles for Service Accounts）调用API的上下文，导致权限被拒绝。

具体来说，策略里的aws:SourceArn被设置为sms-voice相关的ARN，但EKS Pod通过IRSA发起请求时，aws:SourceArn的实际值是EKS ServiceAccount的ARN，而非sms-voice资源的ARN，这就导致条件匹配失败——即使策略允许sms-voice:*动作，也会因为条件不满足而被拒绝。

解决方案 #

方案1：移除不必要的条件（推荐，若无需严格限制请求来源） #

修改角色的权限策略，删除Condition块，让角色直接拥有sms-voice的全部权限：

{
    "Statement": [
        {
            "Action": "sms-voice:*",
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "SMSVoiceFullAccess"
        }
    ],
    "Version": "2012-10-17"
}

方案2：保留条件并修正来源ARN（若需要限制仅特定ServiceAccount调用） #

将aws:SourceArn改为你的EKS ServiceAccount的ARN，格式为arn:aws:iam::<account_id>:serviceaccount/<namespace>/auth-dev-serviceaccount>，同时确保aws:SourceAccount填写正确的AWS账号ID：

{
    "Statement": [
        {
            "Action": "sms-voice:*",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:iam::<account_id>:serviceaccount/<your-namespace>/auth-dev-serviceaccount"
                },
                "StringEquals": {
                    "aws:SourceAccount": "<account_id>"
                }
            },
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "SMSVoiceFullAccess"
        }
    ],
    "Version": "2012-10-17"
}

注意替换<your-namespace>为ServiceAccount所在的Kubernetes命名空间。

额外验证步骤 #

1. 确认权限策略已附加到角色：登录IAM控制台，找到auth-dev-serviceaccount-role，检查权限策略列表中是否包含修改后的策略。
2. 验证Pod的角色挂载：进入Pod内部执行env | grep AWS_ROLE_ARN，确认输出的ARN是auth-dev-serviceaccount-role的ARN，说明IRSA已正确生效。
3. 确认信任关系正确性：检查信任关系中的OIDC提供商ARN是否与你的EKS集群的OIDC提供商一致（可通过aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer"获取）。

内容的提问来源于stack exchange，提问作者bjlevine