- 나의 생각 : AWS Certificate Manager (ACM)은 SSL/TLS 인증서를 생성 및 관리할 수 있는 AWS의 관리형 서비스이다. Leaf Certificate (리프 인증서) 는 인증서 체계에서 가장 아래(최종)에 위치한 인증서를 말하며, 주로 웹 사이트, 앱, api 서버에 설치되고, 브라우저나 클라이언트가 실제 접속할 때 검증하는 대상이다. 인증 경로에서 말단 인증서라고 불린다. acm에서 leaf인증서로 non-aws workloads와 통신한다. 그런 다음, 해당 leaf인증서를 통해 iam roles에 접근하고 aws sts 권한을 획득한다. 획득한 sts 권한으로 non-aws workloads에 접근하고, 일시적인 접근키를 활용하여 aws 리소스에 접근한다.
aws 밖에 있는 워크로그(온프렘/다른 클라우드)가 IAM Roles Anywhere + ACM 인증서를 이용해서 임시 Role 자격증명으로 S3·Aurora·Lambda 등에 접근하는 구조
0. 전체 구조 한 줄 요약
온프렘 서버가 “X.509 인증서(신분증)”로 AWS에 본인 인증 →
IAM Roles Anywhere가 이 인증서를 검증 → STS가 “임시 출입증(AccessKey/Secret/Token)” 발급 →
서버는 그 출입증으로 S3·Aurora·Lambda에 접근
1. 주요 구성요소 정리
오른쪽: Non-AWS workloads
-
AWS 밖에 있는 자원들
- 온프렘 서버
- 다른 클라우드 VM
- 쿠버네티스 Pod, CI 서버 등
-
이 애들이 AWS 리소스에 접근해야 하는 상황 (예: 백업을 S3에 올리기, Aurora에 접속 등)
아래: AWS Certificate Manager (ACM)
- 사설 CA(Private CA) 같은 걸 운영해서
신뢰할 수 있는 클라이언트 인증서(leaf certificate) 를 발급해주는 역할. - 여기서 발급한 인증서가 “이 서버는 우리 조직이 검증했다”는 ID 카드.
중앙: IAM Roles Anywhere
- AWS 밖의 워크로드를 IAM Role과 연결해 주는 서비스.
- X.509 인증서를 보고 “어떤 Role을 대신 사용할 수 있게 할지” 결정.
- 백엔드에서 AWS STS를 호출해 임시 자격증명을 받아온다.
AWS STS
- IAM Role에 대해
AssumeRole해서
임시 보안 자격증명(AccessKeyId/SecretAccessKey/SessionToken) 을 생성해주는 서비스.
왼쪽: Application account + AWS resources
-
Application account안에- IAM Role (권한 + 신뢰 정책)
- S3, Aurora, Lambda 같은 실제 리소스가 존재.
-
Roles Anywhere는 여기 있는 Role을 대신 Assume해서 권한을 얻는다.
2. 번호 순서대로 플로우 분석
① ACM → Leaf certificate 발급
-
ACM(또는 ACM Private CA)을 사용해 클라이언트 인증서(leaf certificate) 를 발급.
-
이 인증서는 나중에 Non-AWS 서버에 설치된다.
-
실제로는:
- 관리자: “백업 서버용 인증서 하나 발급해줘”
- ACM: 해당 서버의 키/CSR 기반으로 인증서 발급
- 인증서 + 비밀키가 서버에 저장
비유: 회사 인사팀(ACM)이 직원에게 사원증(leaf cert)을 발급하는 단계.
② Non-AWS workload가 인증서로 IAM Roles Anywhere에 인증
-
그림에서 “Leaf certificate” ↔ “IAM Roles Anywhere” 사이에 ② 표시.
-
Non-AWS 서버는 Roles Anywhere credential helper / SDK를 사용해
- 자신의 인증서로 요청에 서명해서
- “나 이 인증서 가진 서버인데, 이 IAM Role을 사용하고 싶어” 라고 IAM Roles Anywhere에 요청.
-
IAM Roles Anywhere는
- 인증서 체인이 ACM의 Trust anchor(CA)에서 발급됐는지,
- 인증서의 Subject/Issuer/OID 조건이 IAM Profile 조건과 맞는지 확인.
비유: 출입구(IAM Roles Anywhere)에서 경비가 서버의 사원증(인증서)을 스캐너에 찍어서 진짜 직원인지 검증하는 과정.
③ IAM Roles Anywhere → AWS STS 호출
-
③ 번호가
AWS STS↔IAM Roles Anywhere사이에 있음. -
인증서가 유효하다고 판단되면, Roles Anywhere는
- 해당 워크로드에 매핑된 IAM Profile과
- 그 프로필에 묶인 IAM Role 정보를 보고
-
AssumeRole(혹은 내부 API)을 STS에 호출해서
임시 Role 자격증명을 요청.
비유: 경비(IAM Roles Anywhere)가 인사 시스템(STS)에 전화해서
“이 직원에게 오늘 하루짜리 방문자 출입증 좀 발급해줘요”라고 요청하는 단계.
④ STS 결과 → Temporary role credential 반환
-
STS가 발급한 임시 자격증명
(AccessKeyId, SecretAccessKey, SessionToken, 만료 시간)을
IAM Roles Anywhere가 받아서 Non-AWS workload에 돌려준다. -
그림에서는:
- IAM Roles Anywhere → “Temporary role credential” 아이콘 → Non-AWS workloads 로 가는 흐름 옆에 ④.
비유: 인사 시스템이 방문증을 만들어 경비에게 주고,
경비가 그걸 직원에게 건네주는 단계.
⑤ 임시 자격증명으로 AWS 리소스 접근
-
Non-AWS workload는 받은 임시 자격증명을
- AWS SDK / CLI 환경변수(
AWS_ACCESS_KEY_ID, ...)에 세팅해서 - S3, Aurora, Lambda 등에 API 호출을 보낸다.
- AWS SDK / CLI 환경변수(
-
그림에서:
- “Temporary role credential” → AWS resources (S3/Aurora/Lambda) 방향에 ⑤.
-
권한은 그 Role에 붙어 있는 IAM Policy 가 결정:
-
예:
s3:PutObjectonmy-backup-bucket/*rds-db:connectto 특정 Auroralambda:InvokeFunctionon 특정 함수
-
비유: 직원이 받은 방문증(임시 자격증명)을 들고
“S3 창고”, “DB 방”, “Lambda 작업실” 같은 특정 방에만 들어갈 수 있는 것.
3. 이 아키텍처의 포인트(장점/보안)
-
장점
-
Non-AWS 환경에서도 장기 Access Key를 파일에 저장하지 않고
짧은 수명의 STS 토큰만 사용 → 유출 리스크 감소. -
인증서 기반이기 때문에
- 만료일/갱신/폐기(Revocation) 정책으로 관리 가능.
-
IAM Role으로 접근하므로
- 기존 AWS 권한 모델(IAM Policy, CloudTrail, GuardDuty 등)을 그대로 활용.
-
-
주의점
-
인증서(특히 private key) 보안이 뚫리면 그 서버로 가장해서 Role을 얻을 수 있음 →
온프렘/타클라우드 쪽 키 관리 중요. -
IAM Roles Anywhere에서
- 어떤 CA, 어떤 Subject에 어떤 Role을 허용할지
조건을 촘촘하게 걸어야 함(OU, CN, SAN 등으로 제한).
- 어떤 CA, 어떤 Subject에 어떤 Role을 허용할지
-
STS 토큰 만료 시간/회전 주기 고려해서 애플리케이션이
자동 재발급 로직을 갖고 있어야 함.
-
