Istio는 어떻게 서비스 간 통신의 보안을 담보하고 있는가?

이 기사에 대하여

이 기사에서는 Istio가 어떤 사고 방식으로 서비스 간 통신 보안을 담보하고,
어떻게 담보하고 있는지를 개관 수준에서 정리한다.

서비스 간 통신으로 담보하고 싶은 것과 기존의 보안 모델

서비스 간 통신으로서 담보하고 싶은 것으로,
통신하는 액세스원을 제어해, 도청이나 스푸핑, 변조 등의 공격으로부터 지키는 것을 들 수 있다.
즉,

man in the middle 공격에 대한 방어

액세스 제어

보안 요구 사항으로 언급됩니다.
기존의 보안 모델로는
사설망을 구축하고 IP 기반으로 액세스원을 제한함으로써 이들을 담보해왔다.
(AWS의 Private VPC와 SG를 이해하기 쉽습니다)

Istio에서는 어떤 접근 방식을 취했습니까?

최근 컨테이너 기반으로 구축되는 시스템에서는 IP 주소는 고주파수로 동적으로 변경되기 때문에 이 접근법이라고 파탄한다.
따라서 Isito는 각 워크로드에 대해 ID를 정의하고 ID 기반 액세스 제어를 수행하기로 결정했습니다.
구체적으로는 어떤 접근인가?

핵심 개념

워크로드에 할당된 ID를 기반으로 TLS 통신함으로써 인증과 암호화 통신을 하고,
인증된 ID에 대한 인가 제어를 실시함으로써 액세스 제어를 실현하고 있다.
이를 위해 다음과 같은 구조를 구현하고 있다.

워크로드에 고유 ID를 할당

ID 인증을위한 인증서 발급, 배포, 회전

이것들은, SPIFFE (Secure Production Identity Framework For Everyone) 라고 불리는 표준 사양으로 정의되고 있어 Istio는 Citadel 컴퍼넌트가 이것을 답습한 구현에 해당한다.
구체적인 SPIFEE의 사양, 흐름은 SPIFFE와 그 구현인 SPIRE에 대하여 에서 알기 쉽게 언급되고 있다.

포인트 즉, 워크로드를 위한 ID, 증명서를 발행해, 등록해 두기 위한 인증국으로서의 역할을 담당한 isdiod(Citadel)가 존재해, 각 노드에 존재하는 istio-agent가, 이 Citadel과 istio proxy 간의 교환을 중개해, 증명서 배포등을 실시하고 있다. (istio proxy의 SDS는이 agent가 담당하고 있습니다) 이것에 의해, Pod가 대량으로 존재하는 대규모 클러스터에서도, Pod 자체는 istio agent에 의해 분할 통치되기 때문에, istiod에 대한 부하를 상당히 억제할 수 있다. 또한 일반적으로 예상되는 TLS와 달리이 인증서의 기한은 매우 짧게 설정되어 자주 회전됩니다. 이것에 의해 공격자는 공격을 계속해 나가기 위해서는 이 증명서를 로테이션될 때마다 체일 도둑질 해야 하고, 공격의 난이도를 올리고 있다. 요약 이와 같이 Istio는 워크로드 레벨에서 인증하고, 각각에 액세스 제어를 마련하고 있다. 이것에 의해 움직이는 플랫폼에 좌우되지 않고, 어떠한 환경에서도 안전한 통신을 실현할 수 있다.