STS VPC endpoint 정책 적용 변경 이후 EKS IRSA(AssumeRoleWithWebIdentity)에서 발생하는 AccessDenied 오류 해결 방법

4분 분량

콘텐츠 수준: 중급

2026년 7월 21일부로 적용된 AWS STS의 동작 변경이 EKS IRSA 환경에 미치는 영향과 해결 방법을 설명하는 기술 문서입니다.

개요

2026년 7월 21일부터 AWS STS는 페더레이션 요청(AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity)에 대해 STS VPC endpoint 정책 및 VPC 조건 키를 평가하는 방식을 변경했습니다. 이번 변경은 federated request를 다른 모든 STS API 호출이 VPC endpoint를 통해 처리되는 방식과 동일하게 정렬하기 위한 것입니다. 이 글에서는 해당 변경 사항이 EKS 환경의 인증 메커니즘에 어떤 영향을 미치는지, 그리고 이에 대한 대응 방안을 정리합니다.

변경 사항 요약

인증 방식	변경 전	변경 후
Federated request	VPC endpoint를 경유하는 STS federated request는 VPC endpoint policy 평가를 거치지 않았습니다. 예: AssumeRoleWithSAML, AssumeRoleWithWebIdentity	Federated request도 다른 STS API와 동일하게 VPC endpoint policy의 평가 대상이 됩니다.
API 요청의 결과	VPC endpoint policy에 명시적으로 해당 API를 허용하지 않아도 요청이 성공했습니다.	VPC endpoint policy가 해당 요청을 명시적으로 허용하지 않으면 AccessDenied 에러가 발생합니다.

EKS 인증 체계와 STS의 관계

EKS에서 Pod가 AWS 리소스에 접근하기 위해 IAM credential을 획득하는 과정은 여러 경로가 있으며, 각 경로는 서로 다른 STS API를 사용합니다. 이번 변경의 영향을 정확히 이해하려면, 각 인증 경로에서 어떤 STS API가 호출되고 그 요청이 VPC endpoint를 경유하는지 파악해야 합니다. 일반적으로 Pod 혹은 Node가 STS API를 호출하는 유형은 크게 세 가지로 구분됩니다.

IRSA: AssumeRoleWithWebIdentity를 사용합니다.
Pod Identity: AssumeRoleForPodIdentity를 사용합니다.
Node IAM Role: AssumeRole를 사용합니다.

앞서 기재했듯이 EKS에서 Federated 인증을 사용하여 인가받는 경우 기존에 적용하고 있었던 STS VPC Endpoint policy와 동일하게 적용할 때 기존 동작방식과는 다르게 거절될 수 있습니다. 위의 세 가지 경우 중 OIDC를 이용해 Federated 인증을 사용하는 방식은 IRSA에 해당합니다.

이 과정에서 변경된 정책에 따른 실제 사례를 살펴보도록 하겠습니다. 예를 들어 한 유저가 기존에 STS VPC Endpoint를 사용하며 다음과 같은 policy를 적용하고 있었다고 가정합니다. 변경된 정책에 따르면 VPC Endpoint Policy에서 aws:PrincipalOrgID조건을 사용하는 경우, 기존에는 평가가 skip되어 문제없이 동작했지만 변경된 이후부터는 EKS OIDC Provider로 인증되는 Principal은 외부 Identity Provider로 취급되기 때문에 묵시적으로 거절되게 됩니다.[1]

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowOrgPrincipals",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": [
                        "o-1111111111",
                        "o-2222222222",
                        "o-3333333333"
                    ],
                    "aws:ResourceOrgID": [
                        "o-1111111111",
                        "o-2222222222",
                        "o-3333333333"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAWSServices",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:PrincipalIsAWSService": "true"
                }
            }
        }
    ]
}

즉 VPC에 STS VPC endpoint(com.amazonaws.<region>.sts)가 있는 경우, Pod의 STS API 호출은 해당 endpoint를 통해 라우팅됩니다. 2026년 7월 21일 이전에는 AssumeRoleWithWebIdentity 및 AssumeRoleWithSAML 호출에 대해 STS VPC endpoint 정책에서 aws:PrincipalOrgID 조건이 존재하더라도 문제없이 적용되었습니다. 하지만 2026년 7월 21일 이후에는 STS VPC endpoint 정책에 aws:PrincipalOrgID 조건이 존재하면 묵시적으로 거부되게 됩니다.[1]

IRSA를 통해 sts:AssumeRoleWithWebIdentity가 호출되면, 요청을 수행하는 보안 주체는 조직 내의 IAM 보안 주체가 아니라 OIDC 자격 증명 공급자입니다. aws:PrincipalOrgID 조건 키는 페더레이션(웹 자격 증명 또는 SAML) 보안 주체에 대해 확인할 수 없습니다. 이들은 어떤 AWS Organization에도 속하지 않기 때문입니다. 조건을 충족할 수 없으므로 VPC endpoint 정책에 의해 요청이 거부됩니다.

해결 방법: 페더레이션 작업에 대한 명시적 허용 구문 추가

STS VPC endpoint 정책에 다음 구문을 추가하여 페더레이션 요청을 명시적으로 허용합니다:

{
    "Sid": "AllowFederatedActions",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:AssumeRoleWithSAML"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:ResourceOrgID": [
                "o-1111111111",
                "o-2222222222",
                "o-3333333333"
            ]
        }
    }
}

이 수정 사항의 주요 포인트는 다음과 같습니다.

이 구문은 AssumeRoleWithWebIdentity 및 AssumeRoleWithSAML 호출이 VPC endpoint를 통과할 수 있도록 허용합니다.
aws:ResourceOrgID 조건은 조직에 속한 역할만 수임할 수 있도록 하여 보안 경계를 유지합니다.
aws:PrincipalOrgID 조건은 의도적으로 생략되었습니다. 페더레이션 보안 주체(OIDC 공급자, SAML IdP)에는 연결된 Organization ID가 없기 때문입니다.

문제 확인 방법

Pod 로그에서 sts:AssumeRoleWithWebIdentity 호출에 대한 AccessDenied 오류를 확인합니다.
VPC에 STS VPC endpoint가 구성되어 있는지 확인합니다:

aws ec2 describe-vpc-endpoints --filters "Name=service-name,Values=com.amazonaws.<region>.sts"

STS endpoint에 연결된 VPC endpoint 정책을 검토합니다.
AWS CloudTrail에서 오류 코드가 AccessDenied인 AssumeRoleWithWebIdentity 거부 이벤트를 확인합니다.

추가 고려 사항

EKS Pod Identity: IRSA의 최신 대안인 EKS Pod Identity를 사용하는 경우, AssumeRoleWithWebIdentity에 의존하지 않는 다른 인증 메커니즘을 사용하므로 이 변경의 영향을 받지 않습니다.
IAM 역할 신뢰 정책: VPC endpoint 정책 외에도, VPC 조건 키(aws:SourceVpc, aws:SourceVpce)를 StringNotEquals 또는 StringEqualsIfExists 연산자와 함께 사용하는 IAM 역할 신뢰 정책도 영향을 받을 수 있으므로 검토하시기 바랍니다.

결론

이번 AWS STS의 VPC endpoint policy 평가 방식 변경은 보안 일관성을 높이기 위한 조치이지만, EKS 환경에서 IRSA를 포함한 다양한 federation 기반 인증 메커니즘에 영향을 줄 수 있습니다. 특히 VPC endpoint policy에 조직 기반 조건을 사용하는 환경에서는 즉각적인 검토가 필요합니다.

아직 Pod Identity로 마이그레이션하지 않은 환경이라면, 이번 변경을 계기로 마이그레이션을 검토하는 것을 권장합니다. Pod Identity는 이번 변경에 영향받지 않을 뿐만 아니라, 더 단순한 설정과 향상된 보안 모델을 제공합니다.