soobook
INFRA

IAM Roles Anywhere

AWS 밖의 워크로드가 장기 액세스 키 없이 인증서만으로 IAM role을 빌리는 방법

2026.07.10 12 min read

AWS 밖에서 도는 서버가 AWS API를 부르려면 자격증명이 필요하다. IAM Roles Anywhere는 그 자격증명을 파일로 박아 두는 대신, 이미 갖고 있는 X.509 인증서를 내밀면 단기 IAM 자격증명으로 바꿔 준다.

Intro

AWS 안에서 도는 워크로드는 자격증명 고민이 거의 없다. EC2 인스턴스에는 instance profile을 붙이고, EKS 파드에는 IRSA를 붙이면, SDK가 알아서 단기 자격증명을 받아 온다. 액세스 키를 어디에도 적어 둘 필요가 없다.

문제는 AWS 밖이다. 온프레미스 서버, 다른 클라우드의 VM, 사내 CI 러너가 S3나 DynamoDB를 호출해야 하면, 보통 IAM 사용자를 하나 만들고 그 사용자의 액세스 키(Access Key)를 발급해서 그 머신에 심는다.

이 키가 골칫거리다. 만료가 없어서 한 번 유출되면 회수 전까지 계속 유효하고, 어느 서버에 어떤 키가 깔려 있는지 추적이 안 되며, 주기적으로 교체(rotation)하려면 배포 파이프라인을 다시 건드려야 한다. 장기 자격증명은 그 자체가 관리 부채다.

IAM Roles Anywhere는 이 부채를 없애자는 서비스다. 2022년에 나왔고, 발상은 단순하다. 머신이 이미 갖고 있는 신원 증명을 재활용하자. 대부분의 조직은 내부 서버에 이미 인증서 기반 PKI를 굴리고 있다. 그 인증서를 AWS에 신원으로 제시하게 하고, AWS는 그 대가로 단기 IAM 자격증명을 내준다. 서버에 박아 둘 장기 키가 사라진다.

What IAM Roles Anywhere Is

한 줄로 말하면, AWS 밖 워크로드가 X.509 인증서를 제시하고 단기 IAM 자격증명을 받아 가는 서비스다.

X.509 인증서란 “이 공개키의 주인은 누구다”라는 사실을 신뢰할 수 있는 인증기관(CA)이 서명해 준 문서를 말한다. HTTPS에서 웹 서버가 자기 신원을 증명할 때 쓰는 것과 같은 물건이다. 여기서는 반대로 서버(클라이언트)가 자기 신원을 AWS에 증명하는 데 쓴다.

받아 가는 자격증명은 AWS 내부 워크로드가 쓰는 것과 완전히 같은 종류다. IAM role을 assume해서 나오는 임시 키(액세스 키, 시크릿 키, 세션 토큰 세 쌍)이고, 짧은 수명을 갖고, 만료되면 다시 받는다. 중요한 건 역할과 정책을 새로 만들 필요가 없다는 점이다. 이미 AWS 안에서 쓰던 IAM role과 정책을 그대로 밖의 워크로드에도 물려줄 수 있다.

구성 요소는 세 가지다. 인증서를 신뢰할 근거인 trust anchor, 어떤 role을 빌려줄지 정하는 profile, 그리고 실제로 인증서에 서명해서 자격증명을 받아 오는 클라이언트 도구인 credential helper다. 하나씩 본다.

The Trust Chain

가장 먼저 답해야 할 질문은 “AWS가 이 인증서를 왜 믿어야 하는가”다. 아무 인증서나 들이민다고 자격증명을 내주면 안 된다.

그래서 trust anchor를 등록한다. trust anchor란 “이 CA가 서명한 인증서라면 믿겠다”고 AWS에 미리 선언해 두는 신뢰의 뿌리를 말한다. 두 가지 방식이 있다.

  • AWS Private CA(ACM PCA)를 trust anchor로 지정한다. AWS 안에서 CA를 굴리는 경우다.
  • 외부 CA의 인증서를 PEM 번들로 붙여 넣는다. 이미 사내에 PKI가 있는 경우다.

한 가지 제약이 있다. public CA(Let’s Encrypt, DigiCert 같은 공개 인증기관)가 발급한 인증서는 trust anchor로 쓸 수 없다. 신뢰의 근거는 내가 통제하는 사설 CA여야 한다. 공개 CA를 허용하면 그 CA가 서명한 전 세계 아무 인증서나 내 AWS 계정에 들어올 수 있기 때문이다.

trust anchor로는 root CA도, 중간(intermediate) CA도 지정할 수 있다. 그리고 어느 CA를 지정하느냐가 자격증명을 요청할 수 있는 인증서의 범위를 결정한다. trust anchor로 지정한 CA, 그리고 그 아래 계층의 CA가 발급한 모든 말단(end-entity) 인증서가 자격증명을 요청할 수 있다.

root CA
├── intermediate CA (팀 A)
│   ├── server-1 인증서
│   └── server-2 인증서
└── intermediate CA (팀 B)
    └── server-3 인증서

여기서 root CA를 trust anchor로 지정하면 세 서버 전부가 요청할 수 있다. 반대로 팀 A의 intermediate CA를 trust anchor로 지정하면 server-1, server-2만 들어올 수 있고 server-3은 배제된다. 낮은 계층을 고를수록 신뢰 범위가 좁아진다. 이 선택 자체가 첫 번째 보안 통제다.

Profiles and Roles

trust anchor가 “누구를 믿을지”를 정한다면, profile은 “무엇을 빌려줄지”를 정한다.

profile은 하나 이상의 IAM role을 묶는다. 인증에 성공한 워크로드는 profile에 묶인 role을 assume해서 그 role의 권한을 갖는다. 필요하면 profile에 session policy를 붙여 권한을 한 번 더 좁힐 수 있다. session policy란 role이 원래 가진 권한 위에 덧씌우는 상한선을 말한다.

그런데 role을 그냥 profile에 묶는다고 IAM Roles Anywhere가 그 role을 빌려줄 수 있는 건 아니다. role 쪽에서도 “IAM Roles Anywhere라는 서비스가 나를 assume하는 걸 허용한다”고 명시해야 한다. 이걸 신뢰 정책(trust policy)에 적는다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:rolesanywhere:ap-northeast-2:111122223333:trust-anchor/TA-ID"
        }
      }
    }
  ]
}

세 가지 액션이 나온다. sts:AssumeRole은 role을 빌리는 기본 동작이다. sts:TagSession은 인증서의 속성(Common Name, Organization 같은 것)을 세션 태그로 실어 나르기 위해 필요하고, sts:SetSourceIdentity는 그 세션이 어느 신원에서 나왔는지를 감사 로그에 남기기 위해 필요하다.

Condition의 aws:SourceArn은 뒤에서 다룰 보안의 핵심이라 지금은 “특정 trust anchor에서 온 요청만 이 role을 빌릴 수 있게 못 박는 조건” 정도로만 기억해 두자.

How Authentication Works

이제 실제로 자격증명이 발급되는 순간을 따라가 본다. 워크로드 쪽 도구가 credential helper다.

정식 이름은 rolesanywhere-credential-helper이고, 빌드하면 aws_signing_helper라는 바이너리가 나온다. 이 도구가 하는 일은 인증서의 개인키로 요청에 서명한 다음, IAM Roles Anywhere 엔드포인트를 호출해 임시 자격증명을 받아 오는 것이다.

핵심은 SDK와 붙는 방식이다. AWS SDK와 CLI에는 credential_process라는 표준 확장점이 있다. 설정 파일에 “자격증명이 필요하면 이 명령을 실행해서 그 JSON 출력을 자격증명으로 써라”라고 적어 두는 기능이다. credential helper의 출력이 바로 그 표준 JSON 포맷이라, 설정 파일 한 줄이면 연결이 끝난다.

# ~/.aws/config
[profile ra]
credential_process = /usr/local/bin/aws_signing_helper credential-process \
  --certificate /etc/pki/server.crt \
  --private-key /etc/pki/server.key \
  --trust-anchor-arn arn:aws:rolesanywhere:ap-northeast-2:111122223333:trust-anchor/TA-ID \
  --profile-arn      arn:aws:rolesanywhere:ap-northeast-2:111122223333:profile/PROFILE-ID \
  --role-arn         arn:aws:iam::111122223333:role/my-workload-role

이렇게 해 두면 aws s3 ls --profile ra를 실행하는 순간 SDK가 helper를 호출하고, helper가 자격증명을 받아 와 명령이 실행된다. 자격증명이 만료되기 전에 SDK가 알아서 다시 받아 오므로, 갱신 로직을 직접 짤 필요가 없다.

전체 흐름은 이렇게 이어진다.

워크로드의 credential helper가 개인키로 서명한 CreateSession 요청을 IAM Roles Anywhere에 보내면, 서비스가 공개키로 서명을 검증하고 trust anchor 발급분인지 확인한 뒤 AWS STS를 호출해 수명이 짧은 임시 자격증명을 워크로드에 돌려준다

서명 자체는 SigV4의 X.509 확장(AWS4-X509-RSA-SHA256 또는 ECDSA 변형)을 쓴다. 요청에는 인증서와 함께 trust anchor ARN, profile ARN, role ARN 세 개가 실린다. AWS는 먼저 공개키로 서명을 검증하고, 그 인증서가 등록된 trust anchor에서 나온 것인지 확인한 다음, STS를 호출해 세션을 만든다.

Effective Permissions

세션이 어떤 권한을 갖는지는 한 곳에서 결정되지 않는다. 여러 제약의 교집합이다.

 

유효 권한=role 정책∩session policy∩permission boundary∩SCP\textbf{\text{유효 권한}} = \text{role 정책} \cap \text{session policy} \cap \text{permission boundary} \cap \text{SCP}

 

role의 identity 기반 정책이 출발점이고, profile의 session policy가 그 위에 상한을 씌운다. 여기에 role에 permission boundary가 걸려 있으면 그것도 상한이 되고, 계정이 조직(Organizations) 아래 있으면 SCP도 적용된다. 이 계산 방식은 IAM Roles Anywhere만의 특별한 규칙이 아니라, AWS 안에서 role을 assume할 때와 완전히 동일하다. 밖에서 왔다고 권한 모델이 달라지지 않는다는 게 이 서비스의 설계 의도다.

The Persistence Trap

여기까지만 보면 깔끔하지만, 반드시 알아야 할 함정이 하나 있다. 보안 연구팀(Palo Alto Unit 42)이 지적한 부분이다.

기본 설정에서는 trust anchor와 profile 사이에 아무 상관관계가 없다. 즉 같은 리전, 같은 계정에 trust anchor 하나와 profile 여러 개가 있으면, 그 trust anchor가 서명한 아무 인증서나 profile에 묶인 아무 role이나 빌릴 수 있다. trust anchor용으로 발급한 인증서 한 장이면, 그 계정/리전의 IAM Roles Anywhere role 전체가 잠재적 대상이 된다.

공격자 관점에서 이건 훌륭한 지속성(persistence) 통로다. 인증서와 개인키 한 쌍만 손에 넣으면, 그게 폐기되기 전까지 계속 유효한 자격증명을 찍어낼 수 있다. 액세스 키를 없애려고 도입한 서비스가, 통제 없이 쓰면 오히려 은밀한 뒷문이 된다.

기본 설정에서는 trust anchor가 서명한 인증서 하나로 profile에 묶인 아무 role이나 assume할 수 있다. 반면 role 신뢰 정책에 aws:SourceArn 조건을 걸면 지정한 trust anchor와 role 짝만 허용되고 나머지 role은 차단된다

완화책은 두 가지다.

첫째, role 신뢰 정책에 aws:SourceArn 조건을 걸어 특정 trust anchor에서 온 요청만 그 role을 빌리게 못 박는다. 앞의 trust policy 예시에 있던 그 조건이다. 이것만 걸어도 “아무 trust anchor나 아무 role” 조합이 깨지고, trust anchor와 role이 명시적으로 짝지어진다.

둘째, 인증서 속성 매핑으로 범위를 더 좁힌다. 인증서의 Common Name이나 Organizational Unit 같은 필드를 세션 태그(aws:PrincipalTag/x509Subject/CN 같은 키)로 끌어와, 정책 조건에서 “CN이 server-1인 인증서만 이 role”처럼 제한할 수 있다.

여기서 흔한 오해를 하나 짚는다. role 신뢰 정책 안에 CN을 조건으로 거는 방식이 눈에 보이지만, 그 CN 조건 키는 신뢰 정책 단계에서 강제되지 않는다는 게 Unit 42의 지적이다. 실제로 속성 기반 제한을 걸려면 세션 태그로 매핑한 뒤 권한 정책에서 조건을 거는 경로를 써야 한다. “trust policy에 CN 조건 적었으니 안전하다”고 착각하면 통제가 실제로는 비어 있을 수 있다.

정리하면, IAM Roles Anywhere는 켜는 것보다 좁히는 것이 본론인 서비스다. trust anchor를 최대한 낮은 계층으로 잡고, aws:SourceArn으로 trust anchor와 role을 묶고, 속성 매핑으로 인증서 단위까지 좁히는 세 겹을 기본값으로 삼아야 한다.

When to Use

IAM Roles Anywhere가 항상 정답은 아니다. AWS의 워크로드 신원 도구들은 각자 자리가 있다.

  • AWS 안이면 굳이 쓸 이유가 없다. EC2는 instance profile, EKS 파드는 IRSA나 Pod Identity가 더 단순하다. 이들은 인증서 없이 인스턴스 메타데이터나 OIDC로 신원을 증명한다.
  • 사람의 로그인이라면 IAM Identity Center가 맞다. IAM Roles Anywhere는 사람이 아니라 머신(non-human identity)을 위한 것이다.
  • AWS 밖의 머신이면서 이미 PKI가 있다면 IAM Roles Anywhere가 자연스럽게 들어맞는다. 온프레미스 서버, 하이브리드 클러스터, 다른 클라우드의 워크로드, 사내 CI 러너가 전형적인 자리다.
  • 인증서 인프라가 없다면 도입 비용이 만만치 않다. CA를 세우고 인증서를 발급, 배포, 폐기하는 라이프사이클을 운영해야 한다. 이 경우 Secrets Manager에 자격증명을 넣고 다른 방식으로 접근하는 편이 가벼울 수 있고, 멀티클라우드 전반의 워크로드 신원을 통일하려면 SPIFFE/SPIRE 같은 벤더 중립 체계가 더 맞을 수 있다.

핵심 판단 기준은 단순하다. AWS 밖이고, 인증서 라이프사이클을 이미(또는 어차피) 운영한다면 IAM Roles Anywhere가 장기 액세스 키를 없애는 가장 AWS 네이티브한 길이다.

Cost

IAM Roles Anywhere 서비스 자체에는 별도 과금이 없다. 비용은 사실상 인증서를 어디서 찍느냐에서 나온다.

AWS Private CA를 쓰면 그 비용이 지배적이다. 작성 시점 기준으로 범용(general-purpose) 모드는 CA 하나당 월 400달러 수준이고, 수명이 짧은 인증서만 발급하는 short-lived 모드는 월 50달러 수준이다. short-lived 모드는 최대 7일짜리 인증서만 찍을 수 있는데, IAM Roles Anywhere처럼 단기 신원용으로는 오히려 이쪽이 목적에 맞는다. 이미 사내 CA가 있어서 외부 CA를 trust anchor로 붙이면 이 비용도 들지 않는다.

Post-Quantum Certificates

가장 최근(2026년 3월경) 변화는 포스트 양자 암호(PQC) 지원이다. IAM Roles Anywhere는 기존 X.509 인증서에 더해 양자 내성 서명 알고리즘인 ML-DSA(FIPS 204) 인증서를 지원한다.

두 종류는 같은 환경에서 공존하고 동작이 동일하다. 그래서 전면 교체 없이 기존 X.509와 ML-DSA 인증서를 섞어 쓰며 점진적으로 넘어갈 수 있다. 엄밀히 말하면 ML-DSA 인증서도 형식은 X.509이고 서명 알고리즘만 바뀐 것이라, “X.509 대 ML-DSA”라는 표현은 편의상의 대비다. 당장 필요한 기능은 아니지만, 장기 신뢰 뿌리를 다루는 서비스가 양자 이후를 준비하기 시작했다는 신호로 읽어 둘 만하다.

Summary

IAM Roles Anywhere는 AWS 밖의 워크로드가 장기 액세스 키 대신 X.509 인증서로 단기 IAM 자격증명을 받게 해 준다. trust anchor로 신뢰할 CA를 등록하고, profile로 빌려줄 role을 정하고, credential helper가 인증서로 요청에 서명해 자격증명을 받아 온다. 유효 권한은 AWS 내부에서 role을 assume할 때와 똑같이 여러 정책의 교집합으로 계산된다.

가장 중요한 실무 포인트는 보안이다. 기본값은 위험할 만큼 넓다. trust anchor를 낮은 계층으로 잡고, aws:SourceArn으로 trust anchor와 role을 묶고, 인증서 속성으로 범위를 좁히는 것이 선택이 아니라 필수다. 이 서비스는 켜는 것이 아니라 좁히는 것이 본론이다.

References