Calico를 사용한 네트워크 정책 시행 옵션 이해

Calico 네트워크 플러그인은 하드웨어 호스트, 가상 머신 및 포드를 보호하기 위한 통합 구문으로 광범위한 네트워크 정책을 제공합니다. 이러한 정책은 네임스페이스 내에 적용되거나 다음에 적용되는 글로벌 네트워크 정책일 수 있습니다. 호스트 엔드포인트 (호스트에서 직접 실행되는 애플리케이션을 보호하기 위해 - 호스트는 서버 또는 가상 머신일 수 있음) 또는 워크로드 엔드포인트 (컨테이너 또는 호스팅된 가상 머신에서 실행되는 애플리케이션을 보호하기 위해) Calico 정책을 사용하면 preDNAT, unraracked 및 applyOnForward와 같은 옵션을 사용하여 패킷 경로의 다양한 지점에 보안 조치를 적용할 수 있습니다. 이러한 옵션의 작동 방식을 이해하면 전체 시스템의 보안과 성능을 향상시키는 데 도움이 될 수 있습니다. 이 기사에서는 패킷 처리 경로(iptabels 체인)에서 발생하는 상황을 강조하면서 호스트 엔드포인트에 적용되는 이러한 Calico 정책 옵션(preDNAT, unraracked 및 applyOnForward)의 본질을 설명합니다.

이 문서에서는 사용자가 Kubernetes 및 Calico 네트워크 정책의 작동 방식을 기본적으로 이해하고 있다고 가정합니다. 그렇지 않다면 시도해 보는 것이 좋습니다 기본 네트워크 정책 튜토리얼 и 호스트 보호 튜토리얼 이 글을 읽기 전에 Calico를 사용해 보세요. 또한 업무에 대한 기본적인 이해도 갖고 계시기를 바랍니다. iptables에 리눅스에서.

옥양목 글로벌 네트워크 정책 레이블을 기준으로 일련의 액세스 규칙을 호스트 및 워크로드/포드 그룹에 적용할 수 있습니다. 이는 가상 머신, 하드웨어에 직접 연결된 시스템, Kubernetes 인프라 등 이기종 시스템을 함께 사용하는 경우 매우 유용합니다. 또한 선언적 정책 세트를 사용하여 클러스터(노드)를 보호하고 수신 트래픽에 네트워크 정책을 적용할 수 있습니다(예: NodePort 또는 외부 IP 서비스를 통해).

기본 수준에서 Calico는 Pod를 네트워크에 연결할 때(아래 다이어그램 참조) 가상 이더넷 인터페이스(veth)를 사용하여 이를 호스트에 연결합니다. 포드에서 전송한 트래픽은 이 가상 인터페이스에서 호스트로 들어오며 물리적 네트워크 인터페이스에서 오는 것과 동일한 방식으로 처리됩니다. 기본적으로 Calico는 이러한 인터페이스의 이름을 caliXXX로 지정합니다. 트래픽은 가상 인터페이스를 통해 발생하므로 마치 포드가 한 홉 떨어진 것처럼 iptables를 통과합니다. 따라서 트래픽이 Pod로 들어오거나 Pod에서 들어오면 호스트의 관점에서 전달됩니다.

Calico를 실행하는 Kubernetes 노드에서는 다음과 같이 가상 인터페이스(veth)를 워크로드에 매핑할 수 있습니다. 아래 예에서는 veth#10(calic1cbf1ca0f8)이 calico-monitoring 네임스페이스의 cnx-manager-*에 연결되어 있는 것을 확인할 수 있습니다.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

Calico가 각 워크로드에 대한 veth 인터페이스를 생성한다는 점을 고려하면 정책을 어떻게 시행합니까? 이를 위해 Calico는 iptables를 사용하여 패킷 처리 경로의 다양한 체인에 후크를 만듭니다.

아래 다이어그램은 iptables(또는 netfilter 하위 시스템)의 패킷 처리와 관련된 체인을 보여줍니다. 패킷이 네트워크 인터페이스를 통해 도착하면 먼저 PREROUTING 체인을 통과합니다. 그런 다음 라우팅 결정이 내려지고 이에 따라 패킷은 INPUT(호스트 프로세스로 전달) 또는 FORWARD(팟 또는 네트워크의 다른 노드로 전달)를 통과합니다. 로컬 프로세스에서 패킷은 OUTPUT을 거친 다음 POSTROUTING 체인을 거쳐 케이블로 전송됩니다.

Pod는 iptables 처리 측면에서 (veth에 연결된) 외부 엔터티이기도 합니다. 요약해보자:

• 전달된 트래픽(nat, 라우팅 또는 포드에서/으로)은 PREROUTING - FORWARD - POSTROUTING 체인을 통과합니다.
• 로컬 호스트 프로세스에 대한 트래픽은 PREROUTING - INPUT 체인을 통과합니다.
• 로컬 호스트 프로세스의 트래픽은 OUTPUT - POSTROUTING 체인을 통과합니다.

Calico는 모든 체인에 정책을 적용할 수 있는 정책 옵션을 제공합니다. 이를 염두에 두고 Calico에서 사용할 수 있는 다양한 정책 구성 옵션을 살펴보겠습니다. 아래 옵션 목록의 숫자는 위 다이어그램의 숫자에 해당합니다.

1. 워크로드 엔드포인트(포드) 정책
2. 호스트 엔드포인트 정책
3. ApplyOnForward 옵션
4. PreDNAT 정책
5. 추적되지 않는 정책

먼저 정책이 워크로드 엔드포인트(Kubernetes Pod 또는 OpenStack VM)에 적용되는 방법을 살펴본 다음 호스트 엔드포인트에 대한 정책 옵션을 살펴보겠습니다.

워크로드 엔드포인트

워크로드 엔드포인트 정책(1)

이는 kubernetes 포드를 보호하는 옵션입니다. Calico는 Kubernetes NetworkPolicy 작업을 지원하지만 Calico NetworkPolicy 및 GlobalNetworkPolicy와 같은 추가 정책도 제공합니다. Calico는 각 Pod(워크로드)에 대한 체인을 생성하고 워크로드에 대한 INPUT 및 OUTPUT 체인을 FORWARD 체인의 필터 테이블에 연결합니다.

호스트 엔드포인트

호스트 엔드포인트 정책(2)

CNI(컨테이너 네트워크 인터페이스) 외에도 Calico 정책은 호스트 자체를 보호하는 기능을 제공합니다. Calico에서는 호스트 인터페이스와 필요한 경우 포트 번호의 조합을 지정하여 호스트 엔드포인트를 생성할 수 있습니다. 이 엔터티에 대한 정책 시행은 INPUT 및 OUTPUT 체인의 필터 테이블을 사용하여 수행됩니다. 다이어그램에서 볼 수 있듯이 (2) 노드/호스트의 로컬 프로세스에 적용됩니다. 즉, 호스트 엔드포인트에 적용되는 정책을 생성하면 포드로 들어오고 나가는 트래픽에 영향을 미치지 않습니다. 그러나 Calico 정책을 사용하여 호스트 및 Pod에 대한 트래픽을 차단하기 위한 단일 인터페이스/구문을 제공합니다. 이는 이기종 네트워크에 대한 정책 관리 프로세스를 크게 단순화합니다. 클러스터 보안을 강화하기 위해 호스트 엔드포인트 정책을 구성하는 것은 또 다른 중요한 사용 사례입니다.

ApplyOnForward 정책(3)

ApplyOnForward 옵션은 호스트가 전달할 트래픽을 포함하여 호스트 엔드포인트를 통과하는 모든 트래픽에 정책을 적용할 수 있도록 Calico 글로벌 네트워크 정책에서 사용할 수 있습니다. 여기에는 로컬 포드나 네트워크의 다른 곳으로 전달되는 트래픽이 포함됩니다. Calico에서는 PreDNAT를 사용하고 추적되지 않는 정책에 대해 이 설정을 활성화해야 합니다. 다음 섹션을 참조하세요. 또한 가상 라우터나 소프트웨어 NAT를 사용하는 경우 ApplyOnForward를 사용하여 호스트 트래픽을 모니터링할 수 있습니다.

호스트 프로세스와 Pod 모두에 동일한 네트워크 정책을 적용해야 하는 경우 ApplyOnForward 옵션을 사용할 필요가 없습니다. 필요한 호스트 엔드포인트와 워크로드 엔드포인트(Pod)에 대한 레이블을 생성하기만 하면 됩니다. Calico는 엔드포인트 유형(호스트엔드포인트 또는 워크로드)에 관계없이 레이블 기반 정책을 시행할 만큼 똑똑합니다.

PreDNAT 정책(4)

Kubernetes에서 서비스 엔터티 포트는 NodePorts 옵션을 사용하거나 선택적으로(Calico를 사용하는 경우) 클러스터 IP 또는 외부 IP 옵션을 사용하여 광고함으로써 외부에 노출될 수 있습니다. Kube-proxy는 DNAT를 사용하여 서비스에 바인딩된 수신 트래픽의 균형을 해당 서비스의 Pod로 조정합니다. 그렇다면 NodePort를 통해 들어오는 트래픽에 대한 정책을 어떻게 시행합니까? 트래픽이 DNAT(호스트:포트와 해당 서비스 간의 매핑)에 의해 처리되기 전에 이러한 정책이 적용되도록 하기 위해 Calico는 "preDNAT: true"라는 globalNetworkPolicy에 대한 매개 변수를 제공합니다.

pre-DNAT가 활성화되면 이러한 정책은 다이어그램의 (4)(PREROUTING 체인의 맹글 테이블)에서 DNAT 직전에 구현됩니다. 이러한 정책의 적용은 트래픽 처리 경로에서 훨씬 더 일찍 발생하므로 여기서는 일반적인 정책 순서를 따르지 않습니다. 그러나 preDNAT 정책은 적용 순서를 존중합니다.

pre-DNAT를 사용하여 정책을 생성할 때는 처리하려는 트래픽에 주의하고 대부분이 거부되도록 허용하는 것이 중요합니다. pre-DNAT 정책에서 '허용'으로 표시된 트래픽은 더 이상 호스트엔드포인트 정책에 의해 확인되지 않는 반면, pre-DNAT 정책에 실패한 트래픽은 나머지 체인을 통해 계속됩니다.
Calico는 정의에 따라 트래픽 대상이 아직 선택되지 않았으므로 preDNAT를 사용할 때 applyOnForward 옵션을 활성화하도록 의무화했습니다. 트래픽은 호스트 프로세스로 전달되거나 포드 또는 다른 노드로 전달될 수 있습니다.

추적되지 않는 정책 (5)

네트워크와 애플리케이션의 동작에는 큰 차이가 있을 수 있습니다. 극단적인 경우에는 애플리케이션이 단기 연결을 많이 생성할 수 있습니다. 이로 인해 conntrack(Linux 네트워킹 스택의 핵심 구성 요소)에 메모리가 부족해질 수 있습니다. 일반적으로 Linux에서 이러한 유형의 애플리케이션을 실행하려면 conntrack을 수동으로 구성 또는 비활성화하거나 conntrack을 우회하도록 iptables 규칙을 작성해야 합니다. Calico의 추적되지 않은 정책은 연결을 최대한 빨리 처리하려는 경우 더 간단하고 효율적인 옵션입니다. 예를 들어 대규모를 사용하는 경우 memcache를 또는 추가 보호 조치로 디 도스.

이것을 읽어보세요 블로그 게시물 (또는 우리의 번역) 추적되지 않은 정책을 사용한 성능 테스트를 포함한 자세한 내용을 확인하세요.

Calico globalNetworkPolicy에서 "doNotTrack: true" 옵션을 설정하면 **추적되지 않는** 정책이 되며 Linux 패킷 처리 파이프라인의 매우 초기에 적용됩니다. 위 다이어그램을 보면 연결 추적(conntrack)이 시작되기 전에 추적되지 않은 정책이 원시 테이블의 PREROUTING 및 OUTPUT 체인에 적용됩니다. 추적되지 않는 정책에 의해 패킷이 허용되면 해당 패킷에 대한 연결 추적을 비활성화하도록 표시됩니다. 그 뜻은:

• 추적되지 않은 정책은 패킷별로 적용됩니다. 연결(또는 흐름)의 개념이 없습니다. 연결 부족은 다음과 같은 몇 가지 중요한 결과를 가져옵니다.
• 요청 및 응답 트래픽을 모두 허용하려면 인바운드 및 아웃바운드 모두에 대한 규칙이 필요합니다. 왜냐하면 Calico는 일반적으로 응답 트래픽을 허용된 것으로 표시하기 위해 conntrack을 사용하기 때문입니다.
• 추적되지 않은 정책은 Kubernetes 워크로드(Pod)에 대해 작동하지 않습니다. 이 경우 Pod에서 나가는 연결을 추적할 방법이 없기 때문입니다.
• 추적되지 않은 패킷에서는 NAT가 올바르게 작동하지 않습니다(커널이 NAT 매핑을 conntrack에 저장하기 때문).
• 추적되지 않는 정책에서 "모두 허용" 규칙을 통과하면 모든 패킷이 추적되지 않는 것으로 표시됩니다. 이는 거의 항상 원하는 결과가 아니므로 추적되지 않는 정책에서 허용되는 패킷을 매우 선택적으로 선택하는 것이 중요합니다(그리고 대부분의 트래픽이 일반 추적 정책을 통과하도록 허용).
• 추적되지 않는 정책은 패킷 처리 파이프라인의 맨 처음에 적용됩니다. 이는 Calico 정책을 작성할 때 이해하는 것이 매우 중요합니다. order:1의 포드 정책과 order:1000의 추적되지 않는 정책이 있을 수 있습니다. 그것은 중요하지 않습니다. 추적되지 않음 정책은 포드 정책보다 먼저 적용됩니다. 추적되지 않은 정책은 정책 간 실행 순서만 존중합니다.

doNotTrack 정책의 목적 중 하나는 Linux 패킷 처리 파이프라인의 매우 초기에 정책을 시행하는 것이므로 Calico는 doNotTrack을 사용할 때 applyOnForward 옵션을 지정하도록 의무화합니다. 패킷 처리 다이어그램을 참조하면 라우팅 결정 이전에 untracked(5) 정책이 적용된다는 점에 유의하세요. 트래픽은 호스트 프로세스로 전달되거나 포드 또는 다른 노드로 전달될 수 있습니다.

결과

Calico의 다양한 정책 옵션(호스트 엔드포인트, ApplyOnForward, preDNAT 및 Untracked)과 이러한 옵션이 패킷 처리 경로를 따라 어떻게 적용되는지 살펴보았습니다. 작동 방식을 이해하면 효과적이고 안전한 정책을 개발하는 데 도움이 됩니다. Calico를 사용하면 레이블(노드 및 Pod 그룹)에 적용되는 글로벌 네트워크 정책을 사용하고 다양한 매개변수로 정책을 적용할 수 있습니다. 이를 통해 보안 및 네트워크 설계 전문가는 Calico 정책과 함께 단일 정책 언어를 사용하여 "모든 것"(엔드포인트 유형)을 한 번에 편리하게 보호할 수 있습니다.

감사의 말: 감사드리고 싶습니다. 션 크램튼 и 알렉사 폴리타 그들의 검토와 귀중한 정보를 위해.

출처 : habr.com