워크로드 신원 모델 전환 — SPIFFE에서 IAM으로
범위: VPC Lattice service/resource API와 AWS Gateway API Controller. 선택한 release와 설치 CRD를 확인합니다. 마지막 업데이트: 2026년 9월 13일
이 문서에서 다루는 것
- SPIFFE/SPIRE가 워크로드 신원 문제를 어떻게 풀었는가 — 특히 attestation이 bootstrapping 문제를 해소하는 원리
- SPIFFE 기반 mTLS와 Lattice IAM Auth의 유사점(짧은 수명 자격증명 + 플랫폼 attestation)과 결정적 차이 2개
- 이 차이가 왜 금융권 보안 심의의 핵심 쟁점이 되는가
문제의 출발점 — 워크로드는 자신을 어떻게 증명하는가
서비스 A가 서비스 B를 호출할 때 B는 "이 요청이 정말 A에서 왔는가"를 알아야 합니다. 이 문제가 어려운 이유는 증명에 필요한 비밀을 애초에 어떻게 전달하는가입니다.
비밀(인증서, API 키)을 워크로드에 넣어주려면 그 워크로드가 진짜 그 워크로드인지 알아야 하고, 그것을 알려면 비밀이 필요합니다. 이것이 bootstrapping 문제이며, 전통적인 회피책들은 모두 문제를 옮기기만 합니다.
| 회피책 | 문제를 어디로 옮기는가 |
|---|---|
| 이미지에 인증서 굽기 | 이미지 유출 = 신원 유출. 갱신 시 재빌드 |
| Secret으로 마운트 | Secret에 접근할 수 있는 주체 전부가 그 신원을 위조 가능 |
| 배포 시 주입 | CI/CD 시스템이 모든 신원의 마스터 키를 보유 |
SPIFFE/SPIRE와 Lattice IAM Auth는 둘 다 이 문제를 "플랫폼이 워크로드를 대신 증명한다"는 방식으로 해결합니다. 그래서 구조가 놀랄 만큼 닮았습니다. 그리고 닮았기 때문에 다른 지점이 정확히 무엇인지가 심의의 초점이 됩니다.
SPIFFE 3요소
SPIFFE(Secure Production Identity Framework For Everyone)는 워크로드 신원의 표준입니다. 구현이 아니라 규격입니다.
① SPIFFE ID — 신원의 이름
URI 형식으로 워크로드를 식별합니다.
spiffe://<trust-domain>/<workload-path>
예: spiffe://finance.example.com/ns/prodcatalog/sa/prodcatalog-satrust-domain은 신뢰 경계의 이름입니다. 같은 trust domain에 속한 워크로드끼리는 공통의 신뢰 근원(같은 CA)을 공유합니다. 경로 부분은 조직이 자유롭게 설계하며, Kubernetes 환경에서는 보통 namespace와 ServiceAccount를 반영합니다.
주목할 점은 이름 안에 네트워크 정보가 없다는 것입니다. IP도 호스트명도 포트도 없습니다. 이것이 의도된 설계입니다 — 워크로드가 어디로 스케줄되든, IP가 바뀌든, 신원은 그대로입니다. 04번 문서에서 본 "IP 기반 통제에서 신원 기반 통제로"의 이동이 여기서 시작됩니다.
② SVID — 신원의 증명서
SPIFFE Verifiable Identity Document. SPIFFE ID를 담고 있으며 검증 가능한 문서로, 두 형태가 있습니다.
| 형태 | 내용 | 주 용도 |
|---|---|---|
| X.509-SVID | SPIFFE ID를 SAN URI에 담은 X.509 인증서 + 개인키 | mTLS 상호 인증 |
| JWT-SVID | SPIFFE ID를 sub 클레임에 담은 JWT | HTTP 헤더로 신원 전달, L7 인가 |
핵심 특성은 짧은 수명입니다. SVID는 보통 수십 분에서 수 시간 단위로 발급되고 자동 갱신됩니다. 짧은 수명이 중요한 이유는 폐기(revocation) 문제를 회피하기 때문입니다. 인증서 폐기 목록(CRL)이나 OCSP는 운영이 까다로운데, 자격증명이 곧 만료된다면 폐기 메커니즘 없이도 침해의 유효 기간이 제한됩니다.
③ Workload API — 신원의 전달 통로
워크로드가 자신의 SVID를 받아오는 인터페이스입니다. 핵심은 Unix Domain Socket(UDS)으로 노출된다는 점입니다.
UDS를 쓰는 이유가 이 설계의 정수입니다. 워크로드는 이 소켓에 연결할 때 아무런 자격증명을 제시하지 않습니다. 대신 커널이 소켓 연결의 상대편 프로세스 정보(PID, UID, GID)를 신뢰할 수 있게 제공하고, SPIRE Agent가 그 정보로 상대가 누구인지 직접 조사합니다.
즉 "비밀을 제시해서 신원을 증명"하는 것이 아니라 "플랫폼이 관찰해서 신원을 판정"하는 구조입니다. 여기서 bootstrapping 문제가 풀립니다.
SPIRE 구성
SPIRE는 SPIFFE의 대표적인 구현체입니다.
| 구성요소 | 역할 |
|---|---|
| SPIRE Server | 신뢰 근원. CA를 보유하고 SVID를 서명 발급. Registration Entry(어떤 selector가 어떤 SPIFFE ID를 받는가)를 관리 |
| SPIRE Agent (DaemonSet) | 각 노드에서 동작. 노드 자신의 신원을 Server에 증명하고, 그 노드의 워크로드들을 조사해 SVID를 대리 수령·전달·갱신 |
| Attestation | 신원 판정 절차. Node Attestation(노드 증명)과 Workload Attestation(워크로드 증명) 2단계 |
| Envoy SDS 연동 | Envoy가 Secret Discovery Service 프로토콜로 Agent에게서 인증서를 받음. 애플리케이션 코드는 mTLS를 전혀 모름 |
Attestation이 bootstrapping 문제를 해소하는 원리
이것이 SPIRE의 핵심이며, IAM과 비교할 때의 기준점입니다.
Node Attestation — Agent가 Server에게 "나는 이 노드다"를 증명합니다. 여기서 사용하는 증거는 미리 심어둔 비밀이 아니라 플랫폼이 발급한 증명입니다. AWS에서는 EC2 인스턴스의 IMDS 서명 문서나 인스턴스 신원 문서를 씁니다. Server는 그 증거를 AWS에 대조해 검증할 수 있으므로, 노드에 사전 공유 비밀을 넣어둘 필요가 없습니다.
Workload Attestation — Agent가 노드 안의 워크로드를 조사합니다. 순서는 이렇습니다.
- 워크로드가 UDS에 연결합니다 — 자격증명 없이
- Agent가 커널에서 상대 프로세스의 PID를 얻습니다 — 위조 불가. 커널이 알려주는 사실입니다
- PID로부터 cgroup을 읽어 어느 컨테이너인지 알아냅니다
- kubelet/kube-apiserver에 조회해 그 컨테이너가 속한 Pod, namespace, ServiceAccount, 레이블을 확인합니다
- 이 속성들을 selector로 조합해 Server에 제출합니다
- Server가 Registration Entry에서 매칭되는 SPIFFE ID를 찾아 SVID를 발급합니다
bootstrapping 문제가 해소되는 지점은 2번입니다. 워크로드는 자신이 누구인지 주장하지 않습니다. 주장할 필요가 없습니다. 커널이 사실을 알려주고, 그 사실을 플랫폼(Kubernetes)의 기록과 대조합니다. 위조하려면 커널이나 Kubernetes API 서버를 침해해야 하며, 그 수준의 침해는 이미 다른 모든 것이 무너진 상태입니다.
이 원리를 한 문장으로 정리하면: 신원은 제시되는 것이 아니라 관찰되고 판정되는 것입니다.
IAM Auth와의 대조
Lattice IAM Auth의 절차는 03번 문서에 있습니다. 두 모델을 항목별로 대조하면 이렇습니다.
| 항목 | SPIFFE/SPIRE (AS-IS) | Lattice IAM Auth (TO-BE) |
|---|---|---|
| 신원의 이름 | SPIFFE ID (spiffe://<trust-domain>/ns/<ns>/sa/<sa>) | IAM Role ARN / assumed-role 세션 ARN |
| 자격증명의 형태 | X.509-SVID 또는 JWT-SVID | STS 임시 credential (access key + secret + session token) |
| 증명 방식 | 인증서 개인키 보유 증명 (TLS handshake) | SigV4 요청 서명 (secret key 보유 증명) |
| 증명 단위 | connection — 연결 수립 시 1회 | 요청 — 매 요청 |
| attestation 주체 | SPIRE Agent (노드) + SPIRE Server | EKS Pod Identity Agent + EKS Auth API |
| attestation 증거 | 커널 PID → cgroup → Pod/ServiceAccount 조회 | ServiceAccount ↔ Role 연결 (EKS Auth API) 또는 OIDC 토큰(IRSA) |
| 검증 방식 | 상대 워크로드의 Envoy가 SVID 체인을 trust bundle로 검증 | Lattice가 서명 재계산·대조 후 3중 정책 평가 |
| 신뢰 근원 | 고객이 운영하는 SPIRE Server CA | AWS IAM / STS |
| 자격 수명 | 수십 분~수 시간, 자동 갱신 | STS 임시 credential, 자동 갱신 |
| 인가 표현 | Envoy 인가 필터 (SPIFFE ID 기반) | IAM 정책 3중 (identity-based + service network + service) |
| 관측 수단 | Envoy 메트릭·로그 (SPIFFE ID 단위) | Lattice access log (principal 단위, span 없음) |
| 운영 부담 | 높음 — SPIRE Server HA, CA 키 관리, CA 로테이션, Registration Entry 관리, Agent 배포·업그레이드, trust bundle 배포 | 낮음 — Pod Identity Agent 애드온 + ServiceAccount↔Role 연결. CA·키 관리 없음 |
| 멀티 클러스터 | trust domain 설계와 federation 구성 필요 | Pod Identity로 Role 재사용, 클러스터별 추가 설정 최소 |
| AWS 외부 워크로드 | 적절한 SPIRE attestor로 가능 | 적절한 IAM credential provider와 지원 Lattice 연결 필요. IAM 자체의 금지는 아님 |
유사점 — 왜 이 전환이 가능한가
대조표만 보면 완전히 다른 체계처럼 보이지만, 구조적으로는 같은 패턴입니다. 이것이 전환이 성립하는 근거입니다.
① 둘 다 짧은 수명 자격증명을 쓴다
SVID도, STS 임시 credential도 짧은 수명이며 자동 갱신됩니다. 둘 다 같은 이유로 그렇게 설계되었습니다 — 폐기 메커니즘 없이 침해의 유효 기간을 제한하기 위해서입니다.
두 방식 모두 장기 애플리케이션 비밀 배포를 피할 수 있지만 자격 증명 수명·갱신·침해 대응·인가를 여전히 검토해야 합니다. 짧은 수명이 폐기나 긴급 Deny 요구를 없애지는 않습니다.
② 둘 다 플랫폼 attestation에 기반한다
워크로드가 비밀을 미리 갖고 있지 않고, 플랫폼이 대신 증명해줍니다.
| 단계 | SPIRE | EKS Pod Identity |
|---|---|---|
| 노드 신원 | Node Attestation (EC2 신원 문서 등) | 노드 Role의 AssumeRoleForPodIdentity 권한 |
| 워크로드 판정 | 커널 PID → cgroup → Pod/SA | Pod의 ServiceAccount ↔ Role 연결 |
| 자격증명 전달 | Workload API (UDS) | Pod Identity Agent (link-local 주소) |
| 자격증명 갱신 | Agent가 SVID 갱신 | SDK가 credential 갱신 |
두 방식 모두 플랫폼 증거를 활용하지만 selector·token 검증·자격 증명 노출·신뢰 경계가 다릅니다. 모델이 동등하다고 단정하지 말고 실제 attestor나 credential provider를 검증합니다.
사전 배포한 장기 비밀이 없다는 것과 실행 중 비밀이 없다는 것은 다릅니다. X.509-SVID 전달에는 개인 키가, 임시 IAM 자격 증명에는 secret access key/session token이 포함됩니다. Agent socket/endpoint·메모리·log·캐시를 보호하며 attestation은 설정된 신뢰 가정에 의존합니다.
결정적 차이 2개
유사점이 많으므로, 심의에서 실제로 다투게 되는 것은 다른 두 지점입니다. 이 둘은 운영 편의로 해소되지 않는 구조적 차이입니다.
차이 (a) — 양방향 상호 인증 vs 단방향 + 요청 인증
AS-IS: 양방향입니다.
mTLS handshake에서 클라이언트와 서버가 서로의 SVID를 검증합니다. 클라이언트는 "내가 연결한 상대가 진짜 결제 서비스인가"를 SPIFFE ID로 확인하고, 서버는 "나에게 연결한 상대가 진짜 주문 서비스인가"를 확인합니다. 양쪽 모두 워크로드 신원 체계 안에서 증명됩니다.
TO-BE: 비대칭입니다.
| 방향 | AS-IS | TO-BE |
|---|---|---|
| 클라이언트 → 서버 (클라이언트 증명) | SVID 상호 인증 | SigV4 요청 서명 (요청 단위, 더 세밀) |
| 서버 → 클라이언트 (서버 증명) | SVID 상호 인증 | TLS 서버 인증서 (일반 TLS 수준) |
SigV4는 요청의 서명된 필드를 인증하고 mTLS는 TLS peer를 인증하며, 양쪽 모두 별도로 요청별 인가를 적용할 수 있습니다. 어느 쪽이 보편적으로 더 강한 것은 아닙니다. Lattice는 UNSIGNED-PAYLOAD를 요구하므로 TLS로 본문을 보호하고 replay·자격 증명 탈취 위험을 검토합니다.
문제는 서버 증명입니다. 클라이언트가 확인할 수 있는 것은 "이 TLS 인증서가 유효하고 도메인이 맞다"까지입니다. "이 서비스가 진짜 그 팀이 운영하는 그 서비스인가"를 워크로드 신원 체계로 확인하는 단계가 없습니다.
심의에서 실제로 나오는 질문은 이렇습니다.
DNS·인증서·서비스 association·target 등록의 무단 변경으로 트래픽이 다른 곳으로 갈 수 있는가? Endpoint 인증과 함께 제어 평면 권한을 검토합니다. 같은 표시 이름을 만드는 것만으로 기존 generated service DNS 신원이 이전되지는 않습니다.
정직한 답은 **"워크로드 신원 체계로는 구별할 수 없고, 서비스 네트워크와 Lattice 리소스에 대한 IAM 통제로 막아야 한다"**입니다. 즉 방어선의 위치가 워크로드 간 상호 인증에서 리소스 생성 권한 통제로 이동합니다.
이것은 나쁜 답이 아닙니다. 실제로 Lattice Service를 만들 수 있는 주체를 IAM으로 엄격히 제한하고, service network association을 통제하고, CloudTrail로 리소스 생성을 감시하면 실질적 위험은 관리됩니다. 그러나 심의 문서에 "상호 인증"이라고 적혀 있었다면 그 항목은 다시 써야 하고, 통제의 근거를 다른 계층에서 제시해야 합니다. 이것을 전환 후반에 발견하면 일정이 크게 밀립니다.
차이 (b) — 신뢰 근원의 소유권
이것이 금융권 심의에서 더 무거운 항목입니다.
| 항목 | AS-IS | TO-BE |
|---|---|---|
| 신뢰 근원 | 고객이 운영하는 SPIRE Server CA | AWS IAM / STS |
| CA 개인 키 소유 | 고객 또는 설정한 upstream CA | 고객 Lattice CA는 없지만 임시 IAM 비밀 자격 증명은 존재 |
| 누가 신원을 발급하는가 | 고객이 정의한 Registration Entry에 따라 고객의 CA | AWS STS |
| 신원 발급 규칙의 결정권 | 고객이 완전 통제 | 고객이 IAM으로 통제, 실행은 AWS |
| 감사 증적 | SPIRE Server 로그 (고객 보유) | CloudTrail (AWS 서비스) |
| CA 로테이션 결정권 | 고객 | (해당 없음) |
| AWS 외부 사용 | Attestor와 연결에 따라 다름 | 적절한 credential provider와 지원 사설 연결로 가능하며 Pod Identity가 자동 제공하는 것은 아님 |
| 운영 부담 | 고객 부담 | AWS 부담 |
트레이드오프는 명확합니다. 운영 부담을 AWS에 넘기는 대가로 신뢰 근원의 소유권을 넘깁니다.
이 항목이 금융권에서 무거운 이유는 규제와 심의 관행 때문입니다. 많은 조직의 보안 기준이 **"인증 체계의 신뢰 근원을 자체 통제해야 한다"**를 명시적으로 요구하거나, 최소한 그렇게 해석되는 조항을 갖고 있습니다. 자체 CA를 운영하는 것은 그 요구를 만족시키는 가장 직접적인 방법이었고, SPIRE 도입 자체가 그 심의를 통과한 결과일 가능성이 높습니다.
Lattice IAM Auth로 옮기면 이 논거를 다시 세워야 합니다. 제시할 수 있는 근거들:
| 근거 | 내용 |
|---|---|
| 책임 공유 모델 | IAM/STS는 AWS가 이미 여러 규제 프레임워크에서 인증받아 운영하는 통제 |
| 정책 결정권 유지 | 누가 무엇을 호출할 수 있는가는 고객이 IAM 정책으로 완전히 정의 |
| 감사 증적 확보 | CloudTrail로 credential 발급과 API 호출 이력 확보. Lattice access log로 데이터 경로 이력 확보 |
| CA 운영 부담 감소 | AWS가 서비스 PKI를 처리하지만 고객은 임시 자격 증명·역할·token·endpoint 키를 계속 보호 |
| 자격 수명·attestation 유지 | 앞의 유사점 두 가지는 그대로 만족 |
다만 이것은 "동등하다"는 주장이 아니라 "다른 방식으로 통제된다"는 주장입니다. 심의 담당자가 후자를 받아들일지는 조직의 기준에 달려 있고, 기술적으로 해소할 수 있는 문제가 아닙니다.
금융권 심의 쟁점으로서의 위치
정리하면 이 전환의 심의 쟁점은 다음과 같이 배치됩니다.
| 항목 | 심의 상태 | 근거 |
|---|---|---|
| 이미지 내 장기 비밀 회피 | 설정 검증 | 양쪽 모두 자동 갱신 단기 자격 증명 사용 가능 |
| 실행 중 비밀 노출 | 검토 필요 | 단기 개인 키/token도 보호 필요 |
| 요청별 인가 | 실제 정책 비교 | mTLS 신원으로도 요청별 인가 가능. SigV4만 가능한 것은 아님 |
| 클라이언트 신원 증명 | 방식 변경 | TLS peer 증명과 요청 서명의 범위·위협 가정이 다름 |
| 서버 신원 증명 | ⚠️ 약화 — 대체 통제 필요 | 워크로드 신원 체계에서 TLS 서버 인증서 수준으로. 방어선을 리소스 생성 권한 IAM 통제로 이동 |
| 신뢰 근원 소유권 | ⚠️ 이전 — 논거 재작성 필요 | 고객 CA → AWS IAM/STS |
| End-to-end 암호화 | 신뢰 경계 선택 | HTTPS는 Lattice에서 종료. Passthrough는 endpoint TLS를 유지하지만 인증된 HTTP SigV4 신원은 사용 불가 |
| 관측성 (추적) | ⚠️ 약화 | Envoy span 소멸. 애플리케이션 계측 필요 (01번) |
| AWS 외부 워크로드 | 별도 설계 | 불가능하다고 가정하지 말고 자격 증명과 지원 네트워크 경로 검토 |
바뀐 신뢰·운영 경계를 보안 담당자와 검토합니다. Endpoint mTLS·Lattice 인증 HTTP·익명 네트워크 문맥 정책은 서로 다른 제어입니다. 한 구성이 모든 조직의 검토 기준을 만족한다고 주장하지 말고 실제 요구에 따라 선택합니다.
SPIRE를 계속 쓰는 선택지
전환이 반드시 SPIRE 폐기를 의미하지는 않습니다.
- AWS 외부 워크로드에서는 SPIRE가 계속 유용할 수 있지만 다른 credential/identity 방식도 평가할 수 있습니다.
- TLS Passthrough 구성을 택하면 엔드포인트가 직접 mTLS를 수행해야 하고, 그 인증서를 SPIRE가 계속 공급할 수 있습니다
- 이 경우 App Mesh는 사라지지만 SPIRE는 남는 구성이 됩니다 — App Mesh 지원 종료의 대응과 SPIRE 존속은 별개 결정입니다
SPIRE 운영 부담 자체를 없애는 것이 전환의 목표 중 하나였다면, 위 조건들이 그 목표와 충돌하는지 먼저 확인해야 합니다.
정리
- SPIFFE 3요소는 SPIFFE ID(URI 형식 이름), SVID(짧은 수명 X.509/JWT), Workload API(UDS)입니다.
- SPIRE의 attestation이 bootstrapping 문제를 푸는 원리는 **"신원은 제시되는 것이 아니라 관찰되고 판정되는 것"**입니다. 커널이 알려주는 PID는 위조할 수 없습니다.
- 양쪽 모두 단기 자격 증명과 플랫폼 증거를 사용할 수 있지만 실행 중 비밀과 정책 차이는 계속 검토해야 합니다.
- 결정적 차이는 둘입니다. (a) 양방향 상호 인증이 단방향+요청 인증으로 바뀌어 서버 신원 증명이 약화되고, (b) 신뢰 근원이 고객 CA에서 AWS IAM/STS로 이전됩니다.
- 이 두 항목은 기술로 해소되지 않으며 조직의 판단이 필요합니다. 전환 착수 전에 심의 담당자와 검토해야 하고, 결과에 따라 아키텍처가 바뀝니다.
다음: 제약사항과 의사결정 포인트에서 설계 확정 전에 답해야 할 항목들을 정리합니다.