식별(Identity) 기반 보안
식별(Identity) 기반 보안
Cilium이 라벨에서 파생한 파드의 식별자(Identity)를 기반으로 보안을 어떻게 제공하는지 설명하는 문서예요. 전통적인 IP 주소 필터 방식과 비교해서 무엇이 다른지 이해할 수 있어요.
출처: Identity-Based
본문
Kubernetes 같은 컨테이너 관리 시스템은 각 파드(컨테이너 집합)에 개별 IP 주소를 할당하는 네트워킹 모델을 배포해요. 이 방식은 아키텍처를 단순하게 유지해 주고, 불필요한 네트워크 주소 변환(NAT)을 피하게 해 주며, 각 컨테이너가 전체 포트 번호 범위를 사용할 수 있게 해 줘요. 이 모델의 논리적 결과로, 클러스터 크기와 총 파드 수에 따라 네트워킹 계층이 많은 수의 IP 주소를 관리해야 해요.
전통적으로 보안 시행 아키텍처는 IP 주소 필터에 기반했어요. 간단한 예를 들어볼게요. role=frontend 라벨의 모든 파드가 role=backend 라벨의 모든 파드에 연결을 시작할 수 있어야 한다고 가정해 볼게요. 그러면 role=backend 라벨의 파드를 하나라도 실행하는 모든 클러스터 노드에는, 모든 role=frontend 파드의 IP 주소가 로컬 role=backend 파드의 IP 주소로 연결을 시작할 수 있게 해 주는 필터가 설치돼 있어야 해요. 나머지 연결 요청은 모두 거부돼야 해요. 예를 들면 이렇게 생겼어요. 목적지 주소가 10.1.1.2라면, 출발지 주소가 [10.1.2.2, 10.1.2.3, 20.4.9.1] 중 하나일 때만 연결을 허용해요.
role=frontend나 role=backend 라벨의 새 파드가 시작되거나 중지될 때마다, 그러한 파드를 실행하는 모든 클러스터 노드의 규칙은 허용된 IP 목록에 해당 IP를 추가하거나 제거하는 방식으로 갱신돼야 해요. 규모가 큰 분산 애플리케이션에서는 배포된 파드의 변동(churn)률에 따라 초당 수천 대의 클러스터 노드를 여러 번 갱신해야 할 수도 있어요. 더 나쁜 것은, 새 role=frontend 파드의 연결 시도가 실수로 버려질 수 있기 때문에, 새 파드의 시작을 role=backend 파드를 실행하는 모든 서버가 새 보안 규칙으로 갱신될 때까지 지연시켜야 해요. 이 때문에 효율적으로 확장하기가 어려워져요.
이러한 확장성과 유연성을 제한하는 복잡성을 피하기 위해, Cilium은 보안을 네트워크 주소 지정에서 완전히 분리해요. 대신 보안은 라벨을 통해 파생된 파드의 식별자를 기반으로 해요. 이 식별자는 여러 파드가 공유할 수 있어요. 즉, 첫 번째 role=frontend 파드가 시작될 때 Cilium은 그 파드에 식별자를 할당하고, 이 식별자는 role=backend 파드의 식별자로 연결을 시작할 수 있게 돼요. 이후 추가 role=frontend 파드를 시작할 때는 키-값 저장소(kvstore)에서 이 식별자를 해석하기만 하면 되고, role=backend 파드를 호스팅하는 클러스터 노드에서는 아무 작업도 할 필요가 없어요. 새 파드의 시작은 식별자가 해석될 때까지만 지연시키면 되는데, 이는 나머지 클러스터 노드의 보안 규칙을 갱신하는 것보다 훨씬 단순한 작업이에요.
