배포 자격증명을 워크로드 신원으로 전환하는 설계

클라우드 권한을 처음 연결할 때 가장 손쉬운 방법은 액세스 키나 토큰을 CI 변수, 시크릿 저장소, 컨테이너 환경변수 중 한 곳에 넣는 것입니다. 배포는 곧 성공하고 장애 대응도 단순합니다. 그러나 시간이 지나면 그 값은 여러 저장소, 과거 파이프라인, 디버그 출력, 개발 환경으로 복제됩니다. 권한을 회수해야 하는 순간에도 “어느 실행이 이 값을 아직 쓰는가”를 바로 답하기 어렵습니다. 문제는 비밀값이 있다는 사실이 아니라, 그 값이 현재 실행 중인 워크로드의 신원과 분리돼 있다는 점입니다.

정적 자격증명은 유출된 뒤에도 만료될 이유가 없습니다. 반대로 워크로드 아이덴티티는 실행 중인 프로세스가 자신이 어떤 서비스 계정·노드·네임스페이스·이미지 조건에서 시작됐는지를 증명하고, 그 증거에만 묶인 짧은 수명의 자격증명을 받게 합니다. SPIFFE의 개념 문서는 X.509 SVID와 JWT SVID를 워크로드가 자신의 신원을 증명하는 문서로 정의하고, 키와 인증서가 노출 시간을 줄이기 위해 짧게 유지되고 자동 회전될 수 있다고 설명합니다. 중요한 것은 특정 제품의 도입이 아니라, 발급 대상이 저장된 문자열에서 실행 맥락으로 이동한다는 구조적 변화입니다.

정적 시크릿이 만드는 진짜 병목은 키 관리가 아니라 식별 불능입니다

시크릿을 90일마다 바꾸는 정책은 최소한의 방어선이 될 수 있습니다. 다만 값 하나를 교체했다고 해서 누가 그 값을 사용할 수 있는지 세분화되지는 않습니다. 같은 토큰을 여러 잡과 서비스가 공유하면 감사 로그에는 키 식별자만 남고, 실제 호출자가 결제 API인지 데이터 적재 배치인지 구별하기 어렵습니다. 회전 중 한 서비스가 누락되면 운영자는 만료 시간을 연장하고, 예외는 다시 장기 시크릿이 됩니다.

여기서 흔히 범하는 실수는 키의 개수를 늘리는 것입니다. 서비스마다 키를 하나씩 만들면 추적성은 조금 나아지지만, 만료·배포·폐기 일정을 사람이 연결해야 하는 구조는 그대로입니다. 더 나은 질문은 “이 요청을 낸 프로세스가 지금 이 권한을 받아도 되는가”입니다. 답하려면 발급자는 워크로드의 검증 증거를 보고, 수신자는 발급된 자격증명의 대상·발급자·만료 시간을 확인해야 합니다.

Kubernetes의 projected ServiceAccountToken은 Pod 단위로 대상(audience)과 만료 시간을 지정하는 방법을 제공합니다. 이는 토큰 문자열을 이미지에 굽지 않고, 실행 환경에서 투영한다는 점에서 유용합니다. 하지만 토큰 파일이 있다는 사실만으로 안전해지지는 않습니다. 어떤 외부 서비스가 어떤 audience를 수용하는지, 토큰 교체를 클라이언트가 어떻게 감지하는지, 노드가 침해됐을 때 어떤 경계가 남는지를 별도로 결정해야 합니다.

그렇다면 저장소에서 값을 꺼내는 방식과 실행 신원을 증명하는 방식은 실제 요청 경로에서 어디가 달라질까요? 핵심은 발급과 사용 사이에 검증 가능한 연결고리를 넣는 것입니다.

“누가 호출했나”를 네트워크가 아닌 증명으로 답하는 경로

워크로드 아이덴티티의 최소 흐름은 네 단계입니다. 첫째, 플랫폼 또는 에이전트가 실행 중인 워크로드의 속성을 확인합니다. 둘째, 발급자가 그 속성과 등록 규칙을 대조해 짧은 수명의 SVID나 클라우드 토큰을 제공합니다. 셋째, 클라이언트는 갱신 스트림이나 파일 갱신을 받아 연결 풀과 TLS 컨텍스트를 교체합니다. 넷째, 수신 서비스는 서명 체인, 대상, 만료, 호출자 신원을 검증한 뒤 필요한 최소 권한만 허용합니다.

[CI: deploy manifest] → [scheduler]
                              │ workload attributes
                              ▼
                    [identity issuer / agent]
                       │ short-lived identity
              ┌────────┴─────────┐
              ▼                  ▼
     [service A runtime]  [batch runtime]
              │ mTLS / scoped token
              ▼
        [target API verifies issuer, audience, expiry]

SPIFFE Workload API는 워크로드가 SVID와 신뢰 번들을 얻는 표준 인터페이스이며, 업데이트를 빠르게 전파하기 위한 서버 스트림을 정의합니다. 이 설계가 좋은 이유는 애플리케이션이 발급 서버의 내부 구현을 몰라도 갱신된 신원과 신뢰 번들을 받을 수 있기 때문입니다. 그러나 스트림이 있다고 해서 모든 언어 런타임이 인증서를 자동 교체하는 것은 아닙니다. HTTP 클라이언트, gRPC 채널, 데이터베이스 드라이버처럼 연결을 오래 유지하는 구성요소는 새 인증서를 어떻게 반영하는지 별도로 시험해야 합니다.

이 차이는 보안 검토 때만 중요하지 않습니다. 서비스가 자신의 신원을 명확히 갖게 되면, 권한 정책도 프로덕션 결제 API가 읽기 작업을 수행한다처럼 업무 단위로 쓸 수 있습니다. 네트워크 CIDR, 공유 프록시, 단일 자동화 계정에 의존하는 정책보다 변화의 이유를 읽기 쉬워집니다. 다만 신원을 너무 세밀하게 나누면 등록 규칙이 운영 병목이 됩니다. 처음에는 서비스 경계와 권한 목적이 분명한 경로부터 시작하고, 임시 작업과 사람의 접근은 별도 흐름으로 남기는 것이 좋습니다.

▲ 자동 회전의 성공 여부는 발급기보다, 새 신원을 받아 연결과 설정을 안전하게 바꾸는 런타임 경로에서 결정된다

만료 시간을 줄였는데 왜 배포 장애가 늘어날 수 있을까?

짧은 수명은 탈취된 자격증명의 유효 시간을 줄입니다. 동시에 갱신 경로가 한 번이라도 끊기면 만료 시점에 인증 실패가 모일 수 있습니다. 특히 애플리케이션이 시작할 때만 인증서를 읽거나, 연결 풀을 새로 만들지 않거나, 신뢰 번들의 새 루트를 수용하지 못하면 회전은 재시작 폭주로 변합니다. 보안 개선이 가용성 저하로 느껴지는 이유가 바로 여기 있습니다.

따라서 회전 설계에는 세 개의 시간축이 필요합니다. 첫째는 자격증명 TTL입니다. 둘째는 런타임이 새 값을 관측하고 적용하는 갱신 지연입니다. 셋째는 발급기나 네트워크가 일시적으로 실패해도 버틸 수 있는 잔여 유효 시간입니다. 세 값의 관계를 측정하지 않은 채 TTL만 공격적으로 낮추면, 정상적인 배포 지연이나 인증 인프라의 짧은 장애가 곧바로 고객 오류로 이어집니다. SPIRE Agent의 기본 회전 전략이 수명의 절반을 기준으로 동작할 수 있도록 둔 것도, 만료 직전까지 갱신을 미루지 않기 위한 운영적 선택으로 볼 수 있습니다.

신원 전환을 안전한 배포 경로로 만드는 세 단계

첫 단계는 자산 목록이 아니라 호출 목록을 만드는 것입니다. 어떤 서비스가 어떤 외부 API·데이터베이스·메시지 브로커에 어떤 동작을 하는지, 현재 자격증명이 어느 파이프라인과 런타임에 존재하는지를 정리합니다. 이때 “키 하나”가 아니라 “권한이 필요한 요청 하나”를 단위로 잡아야 합니다. 그래야 공용 키를 분리할 때 권한 과잉을 함께 줄일 수 있습니다.

둘째는 발급 규칙을 작고 읽기 좋게 만드는 것입니다. 서비스 계정, 네임스페이스, 이미지 서명, 클러스터 같은 속성 중 실제 위협 모델에 필요한 것만 선택합니다. 규칙이 너무 넓으면 이름만 신원 기반이고, 너무 복잡하면 배포 실패를 사람이 수동 승인으로 우회하게 됩니다. 발급자와 수신자 모두가 같은 신뢰 도메인·audience·만료 정책을 이해하도록 계약을 문서화해야 합니다.

셋째는 회전을 배포가 아닌 정상 운영으로 만드는 것입니다. 인증서 파일 변경, Workload API 응답 갱신, 연결 재수립, 오류율 변화를 측정하고 실제 만료 전의 리허설을 반복합니다. 만료를 앞당긴 스테이징 환경에서 연결 풀·장기 실행 배치·캐시된 신뢰 번들이 어떻게 반응하는지 먼저 확인하면, 운영에서의 첫 회전이 실험이 되는 일을 피할 수 있습니다.

정적 시크릿을 없애는 일은 화려한 보안 기능 하나를 더하는 일이 아닙니다. 배포가 남긴 과거의 값보다 현재 실행 중인 소프트웨어가 더 강한 증거가 되게 만드는 전환입니다. 이 전환이 잘되면 사고가 나도 회수 범위가 작아지고, 팀은 “키를 바꿨는가”가 아니라 “누가 어떤 조건에서 이 권한을 써야 하는가”를 논의할 수 있습니다. 신원·회전·재로딩·관측을 함께 설계할 때에만 짧은 수명은 위험이 아니라 운영 가능한 경계가 됩니다.

참고: SPIFFE Concepts, SPIFFE Workload API, Kubernetes ServiceAccount Token Projection