원문 캡처 · blog.zaita.io
원문 캡처 · blog.zaita.io

WIF-01이 필요한 이유

WIF-01은 ACME(RFC 8555) 클라이언트가 플랫폼에서 이미 제공하는 신원을 이용해 인증서를 받도록 제안된 새 챌린지 유형이다. 별도의 자격 증명을 저장하지 않아도 된다. 이 글은 사람이 작성하고 AI가 교정했으며, WIF-01 챌린지 RFC 제안자가 기술적 배경이 있는 독자를 대상으로 비유를 곁들여 설명한다.

ACME는 X.509 인증서를 발급하는 프로토콜이다. 웹 서버의 HTTPS/TLS 설정을 자동화하기 쉽게 만들 목적으로 개발됐다. ACME에서는 클라이언트가 개인 키를 생성하고 프로토콜을 통해 전송하지 않는다. 클라이언트는 계정 키로 인증하며, 외부 계정 바인딩(External Account Binding, EAB)을 이용해 기존 고객 계정과 연결할 수 있다. 인증 기관(CA)은 인증서를 발급하기 전에 클라이언트가 요청한 대상에 대한 제어 권한을 증명하도록 챌린지를 수행할 수 있다. 이 프로토콜은 완전 자동화를 염두에 두고 설계됐다.

ACME는 원래 Let's Encrypt 인증 기관을 위해 개발됐으며, 현재 공인 인증서 분야 전반에서 널리 쓰이고 사설 인증 기관에서도 점차 사용이 늘고 있다. 하지만 워크로드가 어떤 도메인을 제어하는지가 아니라 누구인지 증명하는 방법, 특히 먼저 자격 증명을 전달받지 않고 신원을 증명하는 방법은 제공하지 않는다. 제안된 WIF-01은 ACME 클라이언트가 플랫폼에서 이미 제공하는 신원으로 어떤 ACME CA에서든 인증서를 받을 수 있도록 표준 방식을 추가한다.

비밀 0과 워크로드 신원 연합

비밀 0(secret zero)은 리소스에 접근하기 위해 처음 필요한 자격 증명, 즉 시스템·플랫폼·비밀 관리자의 부트스트랩 자격 증명이다. 모든 자격 증명은 생성·전달·저장·교체·모니터링해야 하며, 각 과정에서 유출될 수 있다. 현대적인 인증 방식은 비밀 0을 아예 없애는 것을 목표로 한다.

워크로드 신원 연합(Workload Identity Federation, WIF)은 그중 하나다. 워크로드가 장기간 유효한 비밀을 보유하지 않으므로 기업 환경에서 서비스 간 인증에 널리 쓰이고 있다.

WIF를 쓰는 클라이언트는 Kubernetes, CI/CD 시스템, 클라우드 제공자 등 실행 플랫폼에서 여권에 해당하는 JWT를 받는다. 발급자는 플랫폼마다 다르지만, 같은 절차를 따르고 같은 종류의 여권을 발급한다. 여권에는 클라이언트를 식별하는 sub 필드가 들어 있다. 클라이언트는 이 여권을 신원 증명으로 상대방에게 제시한다. 상대방은 해당 발급자를 이미 신뢰하도록 설정돼 있으며, 발급자가 공개한 키로 여권 서명을 확인한다. 여권이 검증되면 인증을 진행할 수 있다.

이 방식에서 여권은 보통 발급 후 몇 분 안에 만료된다. 여권을 받는 쪽은 발급자를 미리 신뢰해야 한다. 또 여권에는 받는 쪽이 제공한 값을 넣을 수 있어, 여권이 새로 발급됐고 해당 수신자만을 위한 것임을 증명할 수 있다.

ACME 인증과 챌린지의 차이

ACME에는 이미 인증과 챌린지가 있다. 사설 환경의 인증에는 보통 EAB를 쓴다. ACME 서버는 키 ID와 HMAC 키를 클라이언트에 발급하는데, 이는 사용자 이름과 비밀번호에 해당한다. 클라이언트는 인증서를 요청하기 전에 이 값으로 ACME 계정을 기존 계정에 연결한다. 이 자격 증명은 비밀 0이다. 클라이언트 환경에 안전하게 만들어 전달하고 저장해야 하며, 필요할 때 교체해야 한다.

챌린지는 인증과 다르다. 요청이 들어온 뒤 ACME 서버가 클라이언트의 인증서 발급 권한을 확인하는 절차다. 대표적인 유형은 다음과 같다.

  • HTTP-01: ACME 서버가 클라이언트에게 웹 서버에 지정된 파일을 배치하도록 요청한 뒤, 그 파일을 가져와 서버 제어 권한을 확인한다.
  • DNS-01: ACME 서버가 특정 DNS 레코드를 조회해 도메인 제어 권한을 확인한다.
  • TLS-ALPN-01: ACME 서버가 TLS로 연결해 특별한 챌린지 인증서가 있는지 확인한다. 이를 통해 443 포트의 서버를 제어하는지 증명한다.

이 챌린지들은 공개 웹 서버에는 잘 맞지만, 모두 도메인이나 엔드포인트를 제어하는지를 증명한다. 인증서가 공개 도메인 이름에 쓰이지 않거나 CA가 클라이언트에 접속할 수 없거나, 챌린지를 자동화하는 데 별도 자격 증명이 필요한 경우에는 적합하지 않다. 예를 들어 DNS-01 자동화에는 DNS API 자격 증명이 필요해 비밀 0을 DNS 제공자로 옮길 뿐이다.

WIF-01의 작동 방식

WIF-01은 여권 모델을 ACME에 적용한다.

  • 클라이언트가 필요한 인증서의 ACME 주문을 만든다.
  • ACME 서버가 고유 토큰을 담은 wif-01 챌린지를 제시한다.
  • 클라이언트가 플랫폼에 요청해 대상(audience)이 ACME 서버이고 해당 토큰에 묶인 JWT를 받는다.
  • 클라이언트가 JWT를 ACME 서버에 돌려보낸다.
  • ACME 서버가 신뢰하도록 설정된 발급자의 공개 키로 JWT 서명을 검증하고, JWT가 최신이며 이 챌린지에 묶여 있는지 확인한다.
  • ACME 서버가 정책을 확인한다. 해당 발급자와 주체(subject)가 요청한 식별자에 대한 인증서를 받을 수 있는지 판단한다.
  • 허용되면 인증서를 발급한다.

신뢰 여부는 여섯 번째 단계에서 결정된다. CA 운영자는 어떤 워크로드(발급자와 주체)가 어떤 인증서를 받을 수 있는지 정한다. 예를 들어 “프로덕션 클러스터의 payments 서비스는 payments용 클라이언트 인증서를 받을 수 있다”는 정책을 설정할 수 있다. 워크로드는 CA용 자격 증명을 보유하지 않는다. 신원은 워크로드가 실행되는 환경에서 나온다.

ACME 서버가 JWT 발급자의 공개 키를 가져올 수 있어야 한다는 점도 유의해야 한다. 외부 연결을 엄격히 제한한 환경에서는 CA가 접근할 수 있는 위치에 공개 키를 게시해야 할 수 있다.

기존 도구와의 차이

저장된 자격 증명 없이 인증서를 받는 방법으로는 SPIFFE/SPIRE, JWT 인증을 사용하는 Vault PKI, step-ca의 OIDC 프로비저너, 클라우드 제공자의 사설 CA API 등이 이미 있다. 하지만 각각 별도의 API와 클라이언트, 통합 방식이 필요하다. 현재 많은 인증서는 인증서 수명주기 관리(CLM) 도구를 통해 공급업체별 REST API나 명령줄 도구를 사용해 발급받는다.

WIF-01은 이를 표준화하려는 제안이다. 어떤 ACME 클라이언트든 플랫폼이 이미 제공하는 신원으로 어떤 ACME CA와도 통신할 수 있도록 한다. 새로 익혀야 할 것이 없고 특정 공급업체에 종속되지 않으며, 기존 ACME 클라이언트 생태계를 활용할 수 있다는 것이 제안자의 설명이다.

활용 사례

도메인 제어 증명과 관계없이 자동화의 이점을 얻을 수 있는 X.509 인증서 활용 사례로는 상호 TLS, SSH 인증, 암호화 키 패키징, 임시 환경 생성, 규정 준수 환경이 있다.

상호 TLS(mTLS) 인증서에는 클라이언트 인증에 쓸 수 있도록 clientAuth 플래그가 들어간다. 웹사이트가 아니라 클라이언트를 식별하므로 제어를 증명할 도메인이 없는 경우가 많아 DNS와 HTTP 챌린지가 맞지 않는다. 현대적인 mTLS 구현은 권한 범위가 좁은 CA와 몇 분에서 몇 시간 동안 유효한 단기 인증서를 사용한다. 클라이언트를 인증하는 서버는 사설 CA를 신뢰하도록 설정되며, 이상적으로는 해당 관계만을 위한 CA를 신뢰한다. 서버는 그 CA가 발급한 인증서를 신뢰할 수 있고, 필요하면 개별 필드를 추가로 검증할 수 있다. 인증서 유효기간이 짧으면 자주 갱신해야 하므로 갱신은 완전히 자동화되고 자격 증명 없이 이뤄져야 한다. 제안자는 ACME-WIF가 이 조건에 맞는다고 설명한다.

SSH 인증은 비밀번호에서 개인 키로, 현재는 개인 키에서 단기 인증서로 옮겨가고 있다. mTLS와 마찬가지로 SSH 서버는 범위가 좁은 사설 CA가 발급한 인증서를 신뢰하도록 설정된다. Ansible 같은 자동화 플랫폼은 단기 인증서를 받아 대상 시스템에 인증하고 런북을 실행할 수 있다. 이 방식에서는 Ansible이 비밀이나 자격 증명을 보유하지 않고 모든 것이 임시로 유지된다.

모바일 애플리케이션은 백엔드로 데이터를 보내기 전에 암호화하는 등 공개 키가 필요한 경우가 많다. 사용자가 앱을 최신 버전으로 실행하지 않을 수 있어 키를 관리하고 교체하기 어렵다. 키를 인증서로 제공하면 만료 시점을 지정할 수 있고 앱이 검증할 메타데이터도 함께 담을 수 있다. 이 경우 앱은 사설 CA를 신뢰하도록 설정된다. 키를 보유한 백엔드 서비스나 빌드 파이프라인은 저장된 CA 자격 증명 대신 플랫폼 신원으로 ACME-WIF를 사용해 키의 인증서를 받는다. 인증서는 앱이 가져갈 수 있도록 공개 URL에 게시한다. 앱은 발급 CA를 신뢰하므로 인증서에 담긴 공개 키를 데이터 암호화에 사용할 수 있다.

소프트웨어 개발에서는 자동화로 단기간에 테스트 환경을 만드는 일이 늘고 있다. 이런 환경은 프로덕션과 최대한 비슷하게 구성하는 경우가 많아 HTTPS가 필요한 때가 있다. 환경이 짧게 유지되고 격리되는 경우가 많아 HTTP와 TLS-ALPN 챌린지는 대체로 실용적이지 않다. DNS-01을 쓰면 각 파이프라인에 DNS API 자격 증명을 제공해야 한다. ACME-WIF를 이용하면 환경을 만드는 파이프라인이 CI/CD 플랫폼에서 이미 받은 신원으로 인증서를 얻을 수 있다.

규제가 엄격한 환경에는 외부로 나가는 연결은 허용하지만 외부에서 들어오는 연결은 허용하지 않는 제한이 있는 경우가 많다. CA가 환경 안으로 연결할 수 없으므로 HTTP-01과 TLS-ALPN-01은 사용할 수 없다. DNS-01은 인바운드 연결이 필요하지 않지만, 내부 이름은 공용 DNS에 등록돼 있지 않은 경우가 많다. 또한 자동화하려면 이들 환경이 피하려는 DNS 자격 증명이 필요하다. 이런 환경에는 CA의 신뢰 앵커가 이미 포함돼 있고 내부 서비스에도 HTTPS가 필요하다.

이 환경의 워크로드는 Kubernetes나 클라우드 제공자처럼 JWT를 발급할 수 있는 플랫폼에서 실행되는 경우가 많다. ACME-WIF를 사용하면 외부로 나가는 연결만으로 인증서를 받을 수 있으며, 공급업체의 전체 REST API 대신 ACME 프로토콜만 통합하면 된다는 것이 제안의 설명이다.

제안서와 의견 제출

WIF-01은 현재 제안 단계다. 제안자는 의견이 제안을 표준으로 발전시키는 데 필요하다고 밝혔다. RFC 초안은 공개돼 있다. ACME CA를 운영하거나 ACME 클라이언트를 만들거나, 여기서 다루지 않은 활용 사례가 있는 사람에게 의견을 요청하고 있다.

부록: 원문 예시

text
Published At: 2026-10-15
Summary: The proposed wif-01 challenge type lets ACME (RFC 8555) clients obtain certificates 
using the identity their platform already provides, with no stored credentials
Categories: [acme, rfc8555, workload identity federation, OIDC, openid connect, secret zero, 
tls, x.509 certificate management]