SPIFFE

#cloud #architecture #cncf/spiffe #security/pki #protocol/tls

개요


Secure Production Identity Framework For Everyone.
모두를 위한 안전한 운영 신원 프레임워크.
한 마디로 말하자면 네트워크 상에서 고유한 신원을 제공하기 위한 프레임워크 정도?

다양한 소프트웨어 시스템 환경에서 동적으로, 일관되게 보안적으로 고유한 신원을 제공하기 위해 개발된 오픈소스 표준이다.
이 표준을 바탕으로 구현체를 만들어 신원 인증용으로 사용하는 다양한 툴이 있는데, 대표적으로 이스티오, 서트 매니저, AWS, Vault 등이 있다.

즉 SPIFFE 자체는 프레임워크라는 것을 명확히 인지해야 한다.
CNCF 툴 중에서는 이를 구현하는 것들이 많다.
(참고로 오픈텔레메트리마냥 이 놈도 CNCF에서 관리되고 있으며 졸업됐다.)

스피페라는 표준을 만든 집단에서 만든 아키텍처 구현체가 [[#SPIRE(SPIffe Runtime Environment)]]인데, 스피페의 방식과 철학을 이해하기에 좋으니 참고하자.

배경

과거 온프레미스에서야 네트워크 환경에서 식별자로 그냥 IP로 쓰더라도 크게 문제가 되지 않았다.
물론 폐쇄망 환경이면 지금도 그냥 DHCP 없이 고정 IP로 신원 관리하는 경우도 있을 것이다
분산 시스템, MSA가 활성화된 클라우드 환경에서 더 이상 IP는 네트워크 신원으로서 사용하기에 적합하지 않다.
아울러 온프레미스와 다양한 클라우드 환경이 나오면서 이질적이고 다양한 환경에서 고유한 신원을 제공하고자 하는 수요가 발생했다.
이렇게 나온 것이 바로 스피페이다!

스피페는 구체적으로 여러 복합적인 환경에서 워크로드에 고유한 신원을 제공하는 것을 목표로 한다.

워크로드?

이때 워크로드는 단일 목적을 가진 소프트웨어의 집합을 말한다.
즉 같은 역할을 하는 여러 웹서버는 하나의 워크로드라고 친다는 것이다.
워크로드 참고.

워크로드의 신원을 부여하기 위해서는 단순히 네트워크 식별자를 사용할 수는 없다.
여기에 실행되는 인스턴스의 고유한 정보를 이용하는 것도 불가능한데, 하나의 워크로드여도 여러 개의 복제본이 다양한 노드에서 실행될 수 있기 때문이다.
이를 위해 스피페에서는 자신만의 특별한 방법을 마련했는데..

개념

SPIFFE ID

그것은 바로 스피페 ID이다.
스피페 ID는 URI의 한 종류로서 네트워크 환경에서 마음대로 지정할 수 있는 하나의 스킴이다.

spiffe://example.org/ns/default/sa/backend

스피페 id는 이렇게 생겼다.
조금 더 구체적인 형식을 보자.

spiffe://{신뢰 도메인}/{워크로드 식별자}

신뢰 도메인(trust domain)은 스피페를 구축한 인프라 전체를 아우르는 도메인을 말한다.
쿠버네티스라면 보통 클러스터 도메인(cluster.local)을 말한다.
같은 도메인으로부터 신원 증명을 발급 받은 모든 워크로드는 같은 도메인으로부터 검증될 수 있다.

워크로드 식별자 부분은 스피페를 구현하는 개체가 마음대로 정할 수 있다.
가령 위에 쿠버네티스 환경에서는 ns/{네임스페이스}/sa/{서비스어카운트}라고 지정한 것처럼 말이다.

참고로, 스피페 ID는 워크로드에 대해 부여되는 게 기본이고 이게 워크로드에서 활용되지만 이를 발급 받는 과정을 위해 노드에 대해서도 부여되긴 한다.

SVID(Spiffe Verifiable Identity Document)

위 스피페 id가 식별자로 쓰이긴 할 텐데, 도대체 어떻게 이걸 통신 간에 적용할 것인가?
스피페에서는 워크로드가 자신의 신원을 증명할 수 있는 증명서를 SVID라는 개념으로 추상화시켰다.
추상화됐다고 하는 이유는 SVID 자체가 어떤 특정한 증명서 형식인 게 아니라 기존에 존재하던 형식을 활용하여 구성되기 때문이다.
스피페 id는 다음의 두 신원 증명 수단으로 제작될 수 있다.

스피페 id가 쏙 들어간 저런 형식들을 그냥 SVID라 부르는 것이다.
그러니 앞으로 SVID를 발급받는다 하면 저것 중에 하나 발급받는 거겠거니 생각하면 된다.
image.png
x509의 경우 그냥 이렇게 X509v3 Subject Alternative Name 하위로 URI로 spiffe ID가 들어가는 식이다.
image.png
이 사이트에 들어가서 x509 인증서를 그대로 갖다 박으면 SVID의 정보를 예쁘게 확인할 수 있게 해준다.

Workload API

SVID라는 것은 결국 흔히 통신 간 신원을 증명하는 수단으로 활용되는 인증서나 토큰에 추가적인 정보가 들어간 형태일 뿐이라는 것인데, 그렇다면 이러한 인증서나 토큰을 어떻게 발급받을 것이냐가 마지막 관건이 된다.
지금까지의 개념을 보자면, 결국 워크로드가 어디로부턴가 SVID를 받아서 활용해야 한다.

스피페에서는 이 방식을 다음과 같은 흐름으로 정리했다.
일단 워크로드는 신뢰 도메인을 기반으로 인증서를 발급해주는 중앙 서버로부터 SVID를 받아야 하는 상황이다.

즉, 워크로드는 에이전트 - 서버를 거쳐서 SVID를 받게 되는 건데 이러한 방식은 워크로드가 스피페의 세부 구현 여부를 몰라도 되도록 추상화한다는 이점이 있다.
스피페는 다양하고 이질적인 환경에서도 통일된 신원을 제공하기 위한 프레임워크라고 했다.
이때 환경마다 복잡하고 세분화될 수 있는 각종 신원 마련 수단을 워크로드 입장에서는 몰라도 되도록 구조를 잡았고, 이제 스피페를 활용하려는 조직에서는 이 워크로드 API에 대해서만 알고 관련한 구현을 하면 된다.
참고로 워크로드 api는 gRPC로 정의된다고 한다.[1]

SPIRE(SPIffe Runtime Environment)

워크로드 api를 읽으면 도대체 어떻게 워크로드가 고유한 식별자를 가지게 된다는 건지 구체적으로 이해되지 않는다.
그러므로 스피페 표준을 지정한 측에서 제정한 방식인 SPIRE를 알아보며 개념을 조금 더 다져보자.

워크로드 인터페이스에 맞춰서 실제 운영 환경에서 사용할 수 있도록 구현체 런타임 환경 중 하나가 바로 SPIRE이다.[2]
SPIRE는 워크로드가 자동으로 신원을 발급받고, 증명하거나 갱신할 수 있도록 세팅된 환경, 아키텍쳐를 말한다.
일단 SPIRE에서 구성되는 컴포넌트는 다음과 같다.

주의사항

SPIRE는 스피페를 지정한 조직이 만들어낸 아키텍쳐이나, 결국 스피페의 설계와 api를 따르는 하나의 구현 방식에 불과하다.
이에 따라 다른 방식으로 구현이 가능하다는 것도 알아두자.
가령 이스티오의 경우 SPIRE의 방식과 일부분을 구현하지만 전체적인 방식에는 차이가 있다.

SPIRE 서버


서버는 스피페 신뢰 도메인을 기반으로 증명 수단인 SVID을 발행하는 역할을 한다.
이때 신뢰 도메인을 세팅하기 위한 인프라, 백엔드 환경과 교신을 하는 것도 이 서버가 담당한다.
서버는 여러 모듈로 구성돼있는데 간단하게만 설명하자면,

SPIRE 에이전트


에이전트는 위에서 봤듯 서버로부터 워크로드가 사용할 SVID를 받아오는 역할을 한다.
보통 노드 별로 세팅이 되며, 위 그림과 같이 쿠버네티스 환경에서는 파드 별로도 세팅될 수 있다.
에이전트도 서버처럼 여러 모듈을 포함하고 있다.

SPIRE 동작 구조

문서에서 예시로 드는 SVID 발급 전체 과정을 잠시 살펴보자.
워크로드가 EC2에서 돌아가고 있는 상황이며, X509 형식의 SVID를 받으려고 하는 상황이다.

SPIRE 서버 기동

일단 SPIRE 서버가 기동될 때 일어나는 일을 먼저 정리하자면,

SPIRE 에이전트 기동

그 다음 에이전트가 워크로드가 돌고 있는 EC2에 기동되는 상황을 정리하자면,

서버가 이렇게 등록한 정보를 보냄으로써, 에이전트는 자신의 노드가 스피페 클러스터 내부에서 어떤 식으로 식별되는지 알 수 있다.
추가적으로 이 노드에서 어떤 워크로드들이 있을 수 있는지에 대한 정보도 알 수 있다.

spiffeID: spiffe://example.org/ns/default/sa/frontend
selectors:
  - type: k8s
    value: pod-label:app=web
parentID: spiffe://example.org/spire/agent/k8s_psat/cluster/node01

대충 이 정도의 정보가 담겨있는데, 에이전트는 이것을 노드에 캐싱할 것이다.
위 예시를 보면 서버는 어떤 노드에 어떤 파드나 워크로드가 뜰 수 있는지까지 알고 있는 것으로 보인다.
정확히 그러하다.
서버는 스피페 환경을 구현한 환경과 긴밀하게 결합돼있고, 등록될 수 있는 워크로드나 관련한 정보를 자동으로 전달받도록 시스템이 구축돼있다.
그게 아니더라도 서버에 미리 워크로드 api를 통해 워크로드를 등록하던가 하는 작업을 통해, 에이전트가 연결될 때 등록 엔트리를 전달할 수 있도록 구성해야 한다.

워크로드 SVID 발급

이제 마지막으로 워크로드가 실제로 SVID를 받는 과정을 살펴보자.

이렇게 전체 동작 흐름을 봤을 때 보이는 스피페의 특징 중 하나는 중앙 서버의 신원 관리에 절대 선조치 후보고가 없다는 것이다.
다양한 환경을 기반으로 설계 됐으니 환경에 맞춰 그때그때 워크로드를 추가하는 방식을 생각할 만한데도, 운영 조직의 설정에 따른 고유한 워크로드 구분과 안전을 위하여 워크로드 등록과 식별은 투명하게 중앙 서버를 통해 이뤄져야 한다.
즉 이미 워크로드가 돌아가는 상태에서 이 워크로드를 확인하고 나서 그제서야 SVID를 만들어 부여하는 게 아니다.
SVID를 부여하기 이전에, 관리자가 직접 세팅하거나, 혹은 스피페를 구현한 소프트웨어의 자동화를 통해 각 노드에 세팅될 수 있는 워크로드 범위를 사전에 등록해두는 작업이 반드시 선행된다.
그 이후에 워크로드에 SVID를 부여할 때는 이미 셀렉터로 식별된 정보를 기반으로 하는 것이다.

kubectl exec -n spire spire-server-0 -- \
    /opt/spire/bin/spire-server entry create \
    -spiffeID spiffe://example.org/ns/default/sa/default \
    -parentID spiffe://example.org/ns/spire/sa/spire-agent \
    -selector k8s:ns:default \

쿠버네티스에서 활용될 때도 방식이 비슷한데, 파드가 배치될 당시 먼저 api서버로부터 정보를 받아 서버에 반영되며 SVID를 발급받을 수 있도록 엔트리 정보가 추가된다.
아니면 위와 같이 직접 등록하는 방식을 거쳐야 한다.[4]

호환 툴

문서 첫 페이지에 대문짝으루 박아뒀다.[5]

일단 이렇게 호환이 된다고 하는데, 정리를 너무 두서 없이 한 게 아닌가 싶긴 하지만 아무튼 웬만한 모든 인증 방식에 호환된다고 보면 되겠다.
image.png
아예 스피페를 사용하는 소프트웨어에 대한 정보도 나와있다.
위에서도 말했듯이, 이것들이 SPIRE와 같은 방식으로 구성된다는 것은 아니니 참고하자.

관련 문서

EXPLAIN - 파생 문서

이름1related생성 일자
istio-csr 사용 실습E-이스티오 메시 스케일링2025-06-09 00:30

기타 문서

Z0-연관 knowledge, Z1-트러블슈팅 Z2-디자인,설계, Z3-임시, Z5-프로젝트,아카이브, Z8,9-미분류,미완
이름4코드타입생성 일자
앰비언트 모드Z0knowledge2025-06-02 14:51
Istio PeerAuthenticationZ0knowledge2025-05-04 20:00
Istio SecurityZ0knowledge2025-05-04 19:58
9W - 앰비언트 모드 구조, 원리Z8published2025-06-07 19:17

참고

  1. https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md ↩︎

  2. https://spiffe.io/docs/latest/spire-about/spire-concepts/ ↩︎

  3. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html ↩︎

  4. https://spiffe.io/docs/latest/deploying/registering/ ↩︎

  5. https://spiffe.io/docs/latest/spiffe-about/overview/ ↩︎