Claude의 정적 API 키가 필요 없어지는 Workload Identity Federation GA

sk-ant-...로 시작하는 긴 문자열을 CI의 시크릿이나 .env에 둔 채로 운영하는 팀은 많다. 그것은 한 번 만들면 기본적으로 실효되지 않는다. 리포지토리에 실수로 커밋되어도, 유출되었다는 사실을 아무도 모른 채 몇 달 동안 유효한 상태로 남는다. LLM 애플리케이션 사고 보고에서 가장 자주 보이는 원인이 바로 이 정적인 API 키의 유출이다.

그 전제를 깨뜨리는 메커니즘이 6월 17일에 Claude Platform에서 정식 제공(GA)되었다. Anthropic이 Workload Identity Federation(WIF)이라고 부르는 것으로, 한마디로 말하면 "워크로드(Workload)가 Claude API를 호출할 때, 보관해 둔 비밀키를 사용하지 않는" 방식이다.

키를 보관하는 것을 그만두고, 그때마다 발행한다

WIF의 발상 자체는 새롭지 않다. AWS의 IAM 역할(Role)이나 각 클라우드 기업의 Workload Identity Federation과 같은 사고방식을 Claude API 인증에 도입한 것이다. 이미 당신의 워크로드는 실행 중인 환경에서 신원을 증명할 수단을 가지고 있다. GitHub Actions의 러너에는 발행되는 OIDC 토큰이 있고, Kubernetes의 Pod에는 투영된 서비스 어카운트(Service Account) 토큰이 있으며, AWS·GCP·Azure의 실행 환경에는 각각 메타데이터를 통해 가져올 수 있는 서명된 신원 정보가 있다.

WIF는 이 "이미 가지고 있는 신원"을 사용한다. 워크로드가 IdP(Identity Provider, 신원 프로바이더)가 서명한 JWT를 Anthropic에 제시하면, Anthropic이 사전에 설정한 신뢰 규칙과 대조하여 일치할 경우 단기 액세스 토큰(sk-ant-oat01-...)을 반환한다. 이 토큰으로 /v1/messages를 호출한다. 키를 만들고, CI에 두고, 돌리고, 유출하는 사이클 자체가 사라진다. 공식 문서의 표현을 빌리자면 다음과 같다.

There are no static secrets to mint, store in CI, rotate, or leak.

기존 API 키와의 차이점을 나열하면 명확해진다.

구분	정적 API 키 (`sk-ant-...`)	WIF 토큰 (`sk-ant-oat01-...`)
유효 기간	사실상 없음 (수동으로 실효시키기 전까지)	기본 1시간, 최단 60초 (설정에 따라 60~86400초)
보관 장소	CI 시크릿·환경 변수·`.env`	어디에도 보관하지 않음. 실행 시점에 발행
로테이션	수동 작업	SDK가 만료 전에 자동으로 재취득
신원의 입도	키를 공유 = 누가 사용했는지 불명	서비스 어카운트 단위로 ID·감사 로그

마지막 행이 미미해 보이지만 효과적이다. API 키는 "그 자체로 자격 증명"이지만, 서비스 어카운트는 "자격 증명을 그때마다 발급받는 주체"다. 어떤 워크로드가 어떤 서비스 어카운트로 동작했는지가 감사 로그에 남는다.

설정의 정체는 3가지 리소스

콘솔에서 설정하는 것은 3종류의 오브젝트이며, 이를 이해하면 전체상을 파악할 수 있다. 이 세 가지를 합치면 "발행자 X가 서명하고, 클레임(Claim)이 Y로 보이는 토큰은 서비스 어카운트 Z로서 행동해도 좋다"라는 선언이 된다.

서비스 어카운트(svac_...): 이메일도 비밀번호도 콘솔 로그인도 가지지 않는, 인간이 아닌 ID. 토큰이 "누구로서" 행동할지의 실체.
페더레이션 발행자(fdis_...): 신뢰하는 OIDC 프로바이더의 등록. JWT의 iss 클레임(예: https://token.actions.githubusercontent.com)과 서명 검증용 공개키(JWKS)의 취득 방법을 가짐.
페더레이션 규칙(fdrl_...): 양자를 잇는 다리. "발행자 X의 JWT가 이러한 클레임 조건을 만족하면 서비스 어카운트 Z의 토큰을 발행한다"라는 대응 관계와, 부여할 스코프(Scope)·토큰 수명을 정의함.

매칭 조건은 subject_prefix(system:serviceaccount:prod:worker와 같은 접두사 일치), audience의 완전 일치, 클레임 값의 맵, 복잡한 논리를 작성하는 CEL 식 등을 조합할 수 있다. 운영 EKS 클러스터, 스테이징, GitHub Actions는 각각 별도의 발행자로 등록하는 것이 표준적인 사용법이며, 팀이나 네임스페이스(Namespace)별로 규칙을 나누어 권한을 제한할 수 있다.

실제 교환은 이렇게 동작한다

토큰 획득은 RFC 7523의 jwt-bearer 그랜트(Grant)를 사용하여, POST /v1/oauth/token으로 요청을 보낸다. 내용을 살펴보면 수행하는 작업은 단순하다.

# 1. IdP가 발행한 JWT를 취득 (취득 방식은 환경마다 다름)
JWT=$(cat /var/run/secrets/anthropic.com/token)
# 2. JWT를 수명이 짧은 Anthropic 액세스 토큰(Access Token)으로 교환
...

실무에서는 이를 직접 작성하지 않고 SDK에 맡긴다. 클라이언트에는 api_key를 전달하지 않고, 페더레이션(Federation) 자격 증명을 전달하기만 하면 된다. SDK가 교환 및 재취득 루프를 알아서 처리한다.

from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile
client = Anthropic(
    credentials=WorkloadIdentityCredentials(
        ...
    )
)

인자 없이 클라이언트를 생성하고, ANTHROPIC_FEDERATION_RULE_ID 등의 환경 변수를 환경별로 주입하는 방식이 운영 환경(Production)을 위한 권장 패턴으로 되어 있다. 동일한 컨테이너 이미지를 어디서든 실행할 수 있기 때문이다. 재취득은 만료 120초 전 선행 리프레시(Pre-refresh), 30초 전 필수 리프레시(Mandatory refresh)라는 2단계 구조로 되어 있으며, botocore를 따른 설계로 되어 있다. 발행되는 토큰의 수명은 규칙의 token_lifetime_seconds와 "원래 JWT의 남은 수명의 2배" 중 더 짧은 값(하한 60초)으로 설정되어, Anthropic 측의 토큰이 상위의 신원(Identity)보다 더 오래 유지되지 않도록 되어 있다.

내가 가장 활용처가 명확하다고 느끼는 것은 GitHub Actions이다. 리포지토리의 시크릿(Secret)에 ANTHROPIC_API_KEY를 두는 운영 방식을 OIDC 토큰 교환으로 대체하면, CI로부터 수명이 긴 키를 일소할 수 있다.

이행 시의 함정은 정밀도의 함정

이행 시 가장 많이 걸리는 부분은 SDK 자격 증명의 우선순위다. ANTHROPIC_API_KEY는 페더레이션보다 우선된다. 즉, 오래된 키가 환경 변수에 남아 있으면 WIF를 설정했더라도 자신도 모르게 API 키가 계속 사용된다. "이행이 완료된 것처럼 착각하는" 사고가 발생하는 지점임을 문서에 명시해 둔 것은 양심적이며, ant auth status를 통해 어떤 자격 증명이 선택되었는지 확인할 수 있다. 절차로는, 페더레이션을 병행 설정 → ANTHROPIC_API_KEY를 모든 곳(컨테이너 환경, CI 시크릿, 셸 프로필)에서 제거 → 선택된 자격 증명이 전환되었는지 확인 → 마지막으로 키를 무효화하는 순서로 진행된다.

이것으로 전부 해결되는 것은 아니다

냉정하게 효과를 가늠해 본다면, WIF가 보호하는 것은 Claude API에 대한 인증뿐이다. 독립적인 검증으로서, 인증 기반 벤더인 Aembit가 WIF의 한계를 정리한 기사를 내놓았다. 지적은 타당하며, 현실의 워크로드(Workload)는 Claude뿐만 아니라 데이터베이스나 사내 서비스, 타사의 AI API에도 액세스한다. 각각에 대해 별도의 자격 증명 관리가 필요한 상태로 남아 있으며, 그 작업은 앱 개발자 측으로 분산되기 쉽다. 게다가 페더레이션의 강도는 서명하는 IdP의 강도를 넘지 못한다. Kubernetes의 서비스 어카운트(Service Account)나 GitHub Actions의 OIDC 설정을 잘못하면, 잘못된 워크로드에도 유효한 토큰이 발급될 수 있다. Anthropic 스스로도 문서에서 "이것 단독으로는 완결된 보안 시나리오가 아니다(not a complete security story on its own)"라고 기술하고 있으며, 상위 IdP 측의 조건부 액세스(Conditional Access)나 감사 로그(Audit Log)와 결합하여 다층 방어를 구축해야 한다는 점이 양측의 일치된 견해다.

그럼에도 불구하고, LLM 기반의 인증이 드디어 클라우드 IAM의 상식에 따라잡았다는 의미에서 이는 환영할 만한 변화라고 생각한다. 새롭게 Claude API로 운영 워크로드를 구축한다면, 처음부터 정적 키를 발행하지 않는 설계로 만들 수 있다. 기존 시스템에서도 우선 CI의 ANTHROPIC_API_KEY를 삭제하는 것부터 시작할 가치는 충분하다. 유출되면 곤란한 비밀은 애초에 보관하지 않는 것이 가장 강력하다.