둘의 관계

- SPIFFE는 "스펙(표준)"
- SPIRE는  "스펙을 구현한 소프트웨어"

[ EX ] 
 - OCI 스펙 <-> Docker, containerd (구현체)
 - JPA 스펙 <-> Hibernate
 
[ 추가 ]
- SPIRE만이 유일한 구현체는 아님
- Istio의 Citadel도 SPIFFE 호환 인증서를 발급 받음

SPIFFE

설명

- 분산 시스템에서 "서비스 간 신원(identity)을 표준화"하기 위한 오픈소스 프레임워크

- CNCF graduated 프로젝트이며, "Zero Trust 네트워크의 핵심 구성요소"

핵심 개념

[ 문제 인식 ]
- MSA 환경에서 "이 요청이 정말 서비스 A에서 온 것인가?"를 어떻게 검증할건가?

[ 문제 해결. SPIFFE ID ]
- 서비스 신원을 "URI 형식으로 표현"
		- spiffe://trust-domain/workload-identifier
			spiffe://mycompany.com/payment-service
			spiffe://mycompany.com/ns/production/sa/order-api

[ 문제 해결. SVIC(SPIFFE Verifiable Identity Document) ]
- "SPIFFE ID를 증명"하는 실제 문서
- 주로 X.509 인증서 또는 JWT 형태로 발급
- 서비스가 이 SVID를 제시하면 상대방이 신원을 검증 가능

SPIRE - SPIFFE의 구현체

동작 흐름

핵심

- 기존의 mTLS 과정에서 서버가 CA에 CSR를 전송해서 인증서(공개키 + 서버 정보 + CA 서명)을
	받아오는 작업을 Spire Server와 Agent가 "자동으로 생성 및 갱신"해줌
- 이때, "Node <-> Pod" 통신 시 Unix Domain Socket(로컬 통신)으로 네트워크를 타지 않
	

- 자세하게는
		1. 키쌍 생성 -> 갱신 시마다 새 공개키/개인키 쌍 생성
		2. CSR 제출 + 인증서 발급 -> Agent가 Server에 요청, Server가 서명
		3. 인증서 배포 -> Agent가 워크로드에게 인증서 전달
		4. 만료 전 갱신 -> TTL 끝나기 전에 위 과정 자동 반복