SPIFE가 해결할 수 있는 사항

개시하다
지난해 SPIFFT 기사를 쓴 이후 SPIFFT 자체도 업데이트된 부분이 있는데, 최신 정보에 맞춰 SPIFFT가 뭘 해결할 수 있을까?간단하게 정리하고 싶은데요.
SPIFE 해결 방법
SPIFFT는 Zero Trust Network의 아이디어를 바탕으로 하는 서비스 간 인증 방법이다.
이것들은 새로운 것이 아니라 2002년 발표된 플랜 9 보안 디자인, 2005년 발표된 구글의 LOAS의 흐름이다.
최근 몇 년 동안 마이크로 서비스화 시스템과 같은workload 간의 통신에서 송신원이 신뢰할 수 있는지, 메시지의 정당성을 믿을 수 있는지의 과제는 어떤 환경(cloud/on-prem,container/VM)이든 각workload는 같은 인터페이스에서 확인할 수 있는 프레임워크의 규격이다.또한 SPIFFT는 도메인 간에 사용할 때 중앙 관리가 필요하지 않습니다.
SPIFFT는 이를 어떻게 실현하는지, 중요한 SVID,Workload API,Federation 등을 정리한다.
SVID
SPIFFT에는 워크로드 아이디어(SPIFT Verifible Identity Docoment)를 증명하는 데이터 형식이 정의되어 있으며, X.509 형식의 TLS 인증서를 사용하는 X.509과 Json Web Token을 사용하는 JWT-SVID 두 가지가 있다.
workload는 API를 통해 Control Plane에서 SVID 및 검증 인증서 번들을 가져옵니다.
또한 워크로드의 identity인 SPIFFT ID는 어떤 SVID든 포함됩니다.
SPIFFE ID
URI 형태로 속한 트러스트 영역과 필요에 따라 움직이는 환경 등을 담아 워크로드를 표현하는 아이디어를 담았다.

spiffe://staging.example.com/payments/web-fe

spiffe://k8s-west.example.com/ns/staging/sa/default

spiffe://example.com/9eebccd2-12bf-40a6-b262-65fe0487d453

X.509-SVID
X.509 인증서SAN 필드에 자체 SPIFFT ID가 설정되어 있습니다.TLS를 종료하는 쪽에서 SAN 값을 기준으로 트래픽 허용 여부를 판단합니다.
JWT-SVID
X.509-SVID는 TLS가 워크로드가 아닌 이전 세그먼트로 끝나는 경우 종단간 상호 인증을 수행할 수 없습니다.JWT-SVID는 이 상황을 덮어쓸 수 있습니다.sub 자신이 보낸 사람의 SPIFFT ID를 aud에 설정하고 하나 이상의 보낸 사람의 SPIFFT ID를 설정합니다.
따라서 데이터를 받는 측은sub의 값에 따라 송신원을 확인하고 aud에 자신을 포함하는지 여부에 따라 의도적인 통신 대상인지 확인할 수 있다.
나머지는 기본적으로 JWT의 규격에 따라 검증하면 된다.
Workload API
Workload API는 자체 인증서나 JWT를 증명하는 데 사용된 워크로드와 해당 데이터를 검증하는 데 사용됩니다.
Workload API는 공급업체 Neutral API로서 어떤 환경(GCP, AWS, VM,...)그러나 워크로드는 같은 방법으로 자신의 Idenitty와 인증서 묶음을 얻을 수 있다.

Federation
Federation은 여러 개의 서로 다른 영역 (예를 들어 k8s의 경우, 예를 들어 단독 집단 등) 에서 공유 인증서를 묶는다.Federation API는 향후 정의될 예정이지만 아직 공개되지 않았으며 다른 API를 확장하여 구현하고 있습니다.
Federation에 따라workload는 서로 다른 영역에서 온 통신에 대해Federation역 사이라면 송신원의 정확성을 확인할 수 있다.

여기에 Workload API와 같은 공급업체의 중성 API는 각 분야가 서로 다른 환경에서 일하더라도 같은 방법으로 SVID와 인증서 묶음을 취득할 수 있다.SPIFFT는 중앙에서 관리하는 구조가 없기 때문에 제어 평면은 각 환경의 실례 관리 구조와 연합하여 workload의 SVID를 생성한다.

SPIFFT를 사용하시겠습니까?
SPIFFT 설치는 다음과 같습니다.

SPIRE

Istio

HashiCorp Consul Connect

현재는 Istio와 Consul Connect가 서로 다른 영역에서 검증할 수 없기 때문에 Federation이 필요할 경우 SPIRE가 선택사항이 된다.
끝맺다
KubCon+Cloud NativeCon North America 2018에서도 SPIFFT 세션이 늘었고, k8s의 SIG-Auth와 Container Identity WG 관련 세션에서도 언급됐다.회의에 참석한 많은 사람들이 k8s에서 사용할 때와 Istio의 차이에 신경을 많이 썼다.더 많은 기능을 가진 아이스티오는 앞으로도 다양한 분야의 인증을 지원하고, 앞으로도 서비스 인증 관련 제품의 동향을 살펴볼 것이라고 생각한다.
내년에 기회가 된다면 SPIFFT 관련 Meetup을 개최하고 싶습니다.