Architecture-center: 네트워크 흐름 보안 - 작동 방식

신고해 주셔서 감사합니다. 이 문제는 검토 중입니다. 이것은 Microsoft 내부 DevOps 버그 ID AB#271079입니다.

@melzayet에 연락해 주셔서 감사합니다. 두 트래픽 흐름은 서로 다른 출처에서 발생합니다. 상단(녹색) 흐름은 클러스터의 노드에서 실행되는 클러스터의 워크로드(웹 앱/api 등)로 향하는 HTTP 트래픽입니다. 이러한 요청에 대한 HTTP 응답은 WAF와 클라이언트로 다시 송신됩니다.

하단(주황색) 흐름은 노드가 포함된 서브넷에서 시작된 트래픽입니다. 이것은 외부 컨테이너 레지스트리, Kubernetes API 서버 등으로 나가는 트래픽입니다. 기본적으로 회사 이그레스 방화벽 규칙으로 보호하려는 모든 클러스터 시작 트래픽입니다.

UDR이 관리하는 네트워크 외부에서 트래픽이 발생하고 별도의 서브넷에서 _internal_ 로드 밸런서를 사용하고 있기 때문에 동일한 반환 경로를 사용합니다. UDR 규칙은 해당 범위 내에서 발생하는 트래픽에 적용됩니다.

또한 분명히 하기 위해 제시된 이 솔루션은 송신 잠금(클러스터에서 발생하는 트래픽으로 정의됨)에 대해서만 해결하고 방화벽을 통해 수신 및 송신을 모두 퍼널링하지 않습니다.

나는 당신이 말하는 DNAT 부분 이 AKS 문서( 특히 this )의 이 섹션 에서 나온다고 가정합니다. 이 경우 모든 수신 트래픽도 방화벽을 통과하도록 강제합니다. 그들의 경우, 그들은 인그레스에 _public_ 로드 밸런서를 사용하고 있습니다. 우리 솔루션은 인그레스를 위해 퍼블릭 로드 밸런서를 사용하지 않습니다. 우리는 AAG와 연결하고 있으며, AAG는 전용 수신 서브넷의 _internal_ 로드 밸런서를 통해 라우팅됩니다. 그러면 비대칭 라우팅 문제가 발생하지 않습니다. 공개 로드 밸런서 IP를 통해 서비스를 직접 노출했다면 비대칭 라우팅 문제가 발생했을 것입니다.

더 명확하게 설명하는 데 도움이 될 수 있으면 알려주세요. 이것이 "직관에 어긋나는" 것 같습니다. 참조 구현을 사용하여 자유롭게 배포하십시오. 여정이 끝나면 워크로드 HTTP 트래픽이 수신 경로(클라이언트 -> WAF -> 내부 LB -> 노드 풀 -> WAF -> 클라이언트)를 통해 처리되는 웹 사이트가 있습니다. 클러스터에서 시작된 트래픽(노드 풀 -> FW -> 외부 리소스 -> FW -> 노드 풀)은 이그레스 경로를 통해 처리됩니다.

@ckittel 이에 대한 통찰력을 공유해 주셔서 감사합니다! 나는 당신에게 이 문제를 할당합니다.

@ckittel 상세하고 유익한 답변에 진심으로 감사드립니다. 내 혼란은 비대칭 문제에서 비롯된 것 같은데 아주 잘 설명했습니다. 시간 내주셔서 다시 한번 감사드립니다