네트워크 정책

네트워크 정책 (Network Policies)

IP 주소나 포트 수준(OSI 레이어 3 또는 4)에서 트래픽 흐름을 제어하고 싶다면, NetworkPolicy를 사용해 클러스터 안, 그리고 Pod와 외부 세계 사이의 트래픽 흐름 규칙을 지정할 수 있어요. 클러스터는 NetworkPolicy 적용을 지원하는 네트워크 플러그인을 사용해야 합니다.

TCP, UDP, SCTP 프로토콜에 대해 IP 주소나 포트 수준에서 트래픽 흐름을 제어하려면, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 NetworkPolicies를 고려해 볼 수 있어요. NetworkPolicies는 애플리케이션 중심 구조로, [pod]가 네트워크를 통해 다양한 네트워크 "엔티티"와 어떻게 통신할 수 있는지 지정할 수 있게 해줍니다 (여기서 "엔티티"라는 단어를 쓰는 것은 "endpoints"나 "services" 같은 더 일반적인 용어의 의미를 과부하시키는 것을 피하기 위해서예요. 이 용어들은 쿠버네티스에서 특정한 뜻을 가집니다). NetworkPolicies는 한쪽 또는 양쪽 끝에 pod가 있는 연결에 적용되며, 다른 연결에는 관련이 없어요.

Pod가 통신할 수 있는 엔티티는 다음 세 가지 식별자의 조합으로 식별됩니다.

허용되는 다른 Pod들 (예외: pod는 자신에 대한 접근을 차단할 수 없어요)
허용되는 네임스페이스
IP 블록 (예외: Pod가 실행 중인 노드에서 오고 가는 트래픽은 Pod나 노드의 IP 주소와 무관하게 항상 허용됩니다)

pod 기반 또는 namespace 기반 NetworkPolicy를 정의할 때는 [셀렉터]를 사용해 셀렉터와 일치하는 Pod에 대해 어떤 트래픽이 허용되는지 지정합니다.

한편 IP 기반 NetworkPolicies를 만들 때는 IP 블록(CIDR 범위)을 기준으로 정책을 정의합니다.

전제 조건 (Prerequisites)

네트워크 정책은 [네트워크 플러그인]에 의해 구현됩니다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야 해요. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 만드는 것은 효과가 없습니다.

두 종류의 pod 격리 (The two sorts of pod isolation)

pod에는 egress(e 나가는) 격리와 ingress(들어오는) 격리 두 종류가 있어요. 이것들은 어떤 연결이 수립될 수 있는지에 관한 것입니다. 여기서 "격리"는 절대적인 것이 아니라 "일부 제한이 적용된다"는 뜻이에요. 반대로 "$방향에 대해 비격리(non-isolated)"는 해당 방향에 어떤 제한도 적용되지 않는다는 뜻입니다. 이 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 한 pod에서 다른 pod로의 연결에 둘 다 관련됩니다.

기본적으로 pod는 egress에 대해 비격리입니다. 모든 나가는 연결이 허용됩니다. pod를 선택하고 policyTypes에 "Egress"를 가진 NetworkPolicy가 있으면 그 pod는 egress에 대해 격리됩니다. 이런 정책이 egress에 대해 pod에 적용된다고 말해요. pod가 egress에 대해 격리되면, pod에서 허용되는 유일한 연결은 egress에 대해 pod에 적용되는 어떤 NetworkPolicy의 egress 목록이 허용하는 것뿐입니다. 허용된 연결에 대한 응답 트래픽도 암묵적으로 허용됩니다. 이 egress 목록의 효과는 가산적으로 결합됩니다.

기본적으로 pod는 ingress에 대해 비격리입니다. 모든 들어오는 연결이 허용됩니다. pod를 선택하고 policyTypes에 "Ingress"를 가진 NetworkPolicy가 있으면 그 pod는 ingress에 대해 격리됩니다. 이런 정책이 ingress에 대해 pod에 적용된다고 말해요. pod가 ingress에 대해 격리되면, pod로 허용되는 유일한 연결은 pod의 노드에서 오는 것과 ingress에 대해 pod에 적용되는 어떤 NetworkPolicy의 ingress 목록이 허용하는 것입니다. 허용된 연결에 대한 응답 트래픽도 암묵적으로 허용됩니다. 이 ingress 목록의 효과는 가산적으로 결합됩니다.

네트워크 정책은 충돌하지 않습니다. 가산적이에요. 주어진 방향에서 주어진 pod에 어떤 정책이나 정책들이 적용된다면, 그 방향에서 그 pod가 허용하는 연결은 적용되는 정책들이 허용하는 것의 합집합입니다. 따라서 평가 순서는 정책 결과에 영향을 주지 않습니다.

소스 pod에서 대상 pod로의 연결이 허용되려면, 소스 pod의 egress 정책과 대상 pod의 ingress 정책이 모두 그 연결을 허용해야 합니다. 어느 한쪽이 연결을 허용하지 않으면 연결은 발생하지 않아요.

NetworkPolicy 리소스 (The NetworkPolicy resource)

리소스의 전체 정의는 [NetworkPolicy] 참조를 참고하세요.

예시 NetworkPolicy는 다음과 같을 수 있어요.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

참고: 선택한 네트워킹 솔루션이 네트워크 정책을 지원하지 않으면, 이것을 클러스터의 API 서버에 POST해도 효과가 없어요.

필수 필드 (Mandatory Fields): 다른 모든 쿠버네티스 구성과 마찬가지로 NetworkPolicy는 apiVersion, kind, metadata 필드가 필요합니다. 구성 파일 작업에 대한 일반 정보는 [Configure a Pod to Use a ConfigMap]과 [Object Management]를 참고하세요.

spec: NetworkPolicy [spec]에는 주어진 네임스페이스에서 특정 네트워크 정책을 정의하는 데 필요한 모든 정보가 있습니다.

podSelector: 각 NetworkPolicy는 정책이 적용되는 pod 그룹을 선택하는 podSelector를 포함합니다. 예시 정책은 "role=db" 레이블이 있는 pod를 선택해요. 빈 podSelector는 네임스페이스의 모든 pod를 선택합니다.

policyTypes: 각 NetworkPolicy는 Ingress, Egress, 또는 둘 다를 포함할 수 있는 policyTypes 목록을 포함합니다. policyTypes 필드는 주어진 정책이 선택된 pod로의 ingress 트래픽, 선택된 pod로부터의 egress 트래픽, 또는 둘 다에 적용되는지 여부를 나타냅니다. NetworkPolicy에 policyTypes가 지정되지 않으면 기본적으로 Ingress가 항상 설정되고, NetworkPolicy가 egress 규칙을 가지면 Egress가 설정됩니다.

ingress: 각 NetworkPolicy는 허용되는 ingress 규칙 목록을 포함할 수 있습니다. 각 규칙은 from과 ports 섹션을 모두 일치시키는 트래픽을 허용해요. 예시 정책에는 단일 규칙이 있으며, 세 가지 소스 중 하나에서 단일 포트의 트래픽을 일치시킵니다. 첫 번째는 ipBlock으로, 두 번째는 namespaceSelector로, 세 번째는 podSelector로 지정됩니다.

egress: 각 NetworkPolicy는 허용되는 egress 규칙 목록을 포함할 수 있습니다. 각 규칙은 to와 ports 섹션을 모두 일치시키는 트래픽을 허용합니다. 예시 정책에는 단일 규칙이 있으며, 10.0.0.0/24 안의 어떤 목적지로든 단일 포트의 트래픽을 일치시킵니다.

그래서 예시 NetworkPolicy는:

default 네임스페이스의 role=db pod를 ingress와 egress 트래픽 모두에 대해 격리합니다 (아직 격리되지 않았다면)
(Ingress 규칙) default 네임스페이스에서 role=db 레이블이 있는 모든 pod에 대해 TCP 포트 6379로의 연결을 다음에서 허용합니다:
- default 네임스페이스에서 role=frontend 레이블이 있는 모든 pod
- project=myproject 레이블이 있는 네임스페이스의 모든 pod
- 172.17.0.0–172.17.0.255 및 172.17.2.0–172.17.255.255 범위의 IP 주소 (즉, 172.17.1.0/24를 제외한 172.17.0.0/16 전체)
(Egress 규칙) default 네임스페이스에서 role=db 레이블이 있는 모든 pod에서 CIDR 10.0.0.0/24로의 TCP 포트 5978 연결을 허용합니다

더 많은 예시는 [Declare Network Policy] 워크스루를 참고하세요.

`to`와 `from` 셀렉터의 동작 (Behavior of `to` and `from` selectors)

ingress의 from 섹션 또는 egress의 to 섹션에서 지정할 수 있는 셀렉터는 네 가지 종류가 있어요.

podSelector: NetworkPolicy와 같은 네임스페이스에서 ingress 소스 또는 egress 목적지로 허용되어야 하는 특정 Pod를 선택합니다.

namespaceSelector: ingress 소스 또는 egress 목적지로 모든 Pod가 허용되어야 하는 특정 네임스페이스를 선택합니다.

namespaceSelector 그리고 podSelector: namespaceSelector와 podSelector를 모두 지정하는 단일 to/from 항목은 특정 네임스페이스 안의 특정 Pod를 선택합니다. 올바른 YAML 구문을 사용하도록 주의하세요. 예를 들어:

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
      podSelector:
        matchLabels:
          role: client
  ...

이 정책은 user=alice 레이블이 있는 네임스페이스에서 role=client 레이블이 있는 Pod로부터의 연결을 허용하는 단일 from 요소를 포함합니다. 그러나 다음 정책은 다릅니다:

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
    - podSelector:
        matchLabels:
          role: client
  ...

이것은 from 배열에 두 개의 요소를 포함하며, 로컬 네임스페이스에서 role=client 레이블이 있는 Pod로부터의 연결 또는 user=alice 레이블이 있는 어떤 네임스페이스의 어떤 Pod로부터의 연결을 허용합니다.

의심스러우면 kubectl describe를 사용해 쿠버네티스가 정책을 어떻게 해석했는지 확인하세요.

ipBlock: ingress 소스 또는 egress 목적지로 허용할 특정 IP CIDR 범위를 선택합니다. Pod IP는 임시적이고 예측할 수 없으므로 이들은 클러스터 외부 IP여야 합니다.

클러스터 ingress와 egress 메커니즘은 종종 패킷의 소스 또는 목적지 IP를 다시 쓰는 것을 요구합니다. 이런 일이 발생하는 경우, NetworkPolicy 처리 전에 발생하는지 후에 발생하는지는 정의되어 있지 않으며, 네트워크 플러그인, 클라우드 프로바이더, Service 구현 등의 조합에 따라 동작이 다를 수 있어요.

ingress의 경우, 어떤 경우에는 실제 원래 소스 IP를 기준으로 들어오는 패킷을 필터링할 수 있지만, 다른 경우에는 NetworkPolicy가 작용하는 "소스 IP"가 LoadBalancer의 IP나 Pod의 노드 IP 등일 수 있다는 뜻입니다.

egress의 경우, 클러스터 외부 IP로 다시 쓰여지는 Service IP로의 pod 연결이 ipBlock 기반 정책의 대상이 될 수도 안 될 수도 있다는 뜻입니다.

기본 정책 (Default policies)

기본적으로 네임스페이스에 정책이 없으면, 그 네임스페이스의 pod로 들어오고 나가는 모든 ingress 및 egress 트래픽이 허용됩니다. 다음 예시들은 그 네임스페이스에서 기본 동작을 변경할 수 있게 해줍니다.

모든 ingress 트래픽 기본 거부 (Default deny all ingress traffic)

모든 pod를 선택하지만 그 pod들로의 ingress 트래픽은 허용하지 않는 NetworkPolicy를 만들어, 네임스페이스에 대한 "기본" ingress 격리 정책을 만들 수 있어요.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

이렇게 하면 다른 어떤 NetworkPolicy에도 선택되지 않은 pod조차도 ingress에 대해 격리됩니다. 이 정책은 어떤 pod의 egress 격리에는 영향을 주지 않습니다.

모든 ingress 트래픽 허용 (Allow all ingress traffic)

네임스페이스의 모든 pod로 들어오는 모든 연결을 허용하려면 명시적으로 허용하는 정책을 만들 수 있어요.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

이 정책이 있으면 추가 정책이 그 pod들로 들어오는 어떤 연결도 거부할 수 없어요. 이 정책은 어떤 pod의 egress 격리에는 효과가 없습니다.

모든 egress 트래픽 기본 거부 (Default deny all egress traffic)

모든 pod를 선택하지만 그 pod들로부터의 egress 트래픽은 허용하지 않는 NetworkPolicy를 만들어, 네임스페이스에 대한 "기본" egress 격리 정책을 만들 수 있어요.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

이렇게 하면 다른 어떤 NetworkPolicy에도 선택되지 않은 pod조차도 egress 트래픽이 허용되지 않습니다. 이 정책은 어떤 pod의 ingress 격리 동작도 바꾸지 않습니다.

주의: 기본 deny-all egress 정책은 DNS 트래픽도 차단합니다. 워크로드가 DNS 해석이 필요하면, 클러스터의 DNS 서비스로의 egress를 허용하는 별도의 NetworkPolicy를 추가해야 해요.

모든 egress 트래픽 허용 (Allow all egress traffic)

네임스페이스의 모든 pod에서 모든 연결을 허용하려면, 네임스페이스의 pod로부터 모든 나가는 연결을 명시적으로 허용하는 정책을 만들 수 있어요.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

이 정책이 있으면 추가 정책이 그 pod들로부터의 어떤 나가는 연결도 거부할 수 없어요. 이 정책은 어떤 pod로의 ingress 격리에는 효과가 없습니다.

모든 ingress 및 egress 트래픽 기본 거부 (Default deny all ingress and all egress traffic)

그 네임스페이스에서 다음 NetworkPolicy를 만들어 모든 ingress 및 egress 트래픽을 방지하는 "기본" 정책을 만들 수 있어요.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

이렇게 하면 다른 어떤 NetworkPolicy에도 선택되지 않은 pod조차도 ingress 또는 egress 트래픽이 허용되지 않습니다.

네트워크 트래픽 필터링 (Network traffic filtering)

NetworkPolicy는 레이어 4 연결(TCP, UDP, 선택적으로 SCTP)에 대해 정의됩니다. 다른 모든 프로토콜의 경우 동작은 네트워크 플러그인에 따라 달라질 수 있어요.

참고: SCTP 프로토콜 NetworkPolicies를 지원하는 [CNI] 플러그인을 사용해야 합니다.

deny all 네트워크 정책이 정의되면 TCP, UDP, SCTP 연결만 거부하는 것이 보장됩니다. ARP나 ICMP 같은 다른 프로토콜의 경우 동작은 정의되어 있지 않아요. 허용 규칙에도 동일하게 적용됩니다. 특정 pod가 ingress 소스나 egress 목적지로 허용될 때 (예를 들어) ICMP 패킷에 무슨 일이 일어나는지는 정의되어 있지 않습니다. ICMP 같은 프로토콜은 일부 네트워크 플러그인에서는 허용되고 다른 곳에서는 거부될 수 있어요.

포트 범위 대상 지정 (Targeting a range of ports)

기능 상태: Kubernetes v1.25부터 stable

NetworkPolicy를 작성할 때 단일 포트 대신 포트 범위를 대상으로 지정할 수 있어요.

이것은 다음 예시처럼 endPort 필드를 사용해 달성할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: multi-port-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 32000
          endPort: 32768

위 규칙은 default 네임스페이스에서 role=db 레이블이 있는 모든 Pod가 대상 포트가 32000에서 32768 사이에 있는 경우 TCP를 통해 10.0.0.0/24 범위의 모든 IP와 통신할 수 있게 합니다.

이 필드를 사용할 때 다음 제한이 적용됩니다.

endPort 필드는 port 필드보다 크거나 같아야 합니다.
endPort는 port도 정의된 경우에만 정의할 수 있습니다.
두 포트 모두 숫자여야 합니다.

참고: 클러스터는 NetworkPolicy 사양에서 endPort 필드를 지원하는 [CNI] 플러그인을 사용해야 합니다. [네트워크 플러그인]이 endPort 필드를 지원하지 않는데 그것으로 NetworkPolicy를 지정하면, 정책은 단일 port 필드에 대해서만 적용됩니다.

레이블로 여러 네임스페이스 대상 지정 (Targeting multiple namespaces by label)

이 시나리오에서 Egress NetworkPolicy는 레이블 이름으로 둘 이상의 네임스페이스를 대상으로 합니다. 이렇게 하려면 대상 네임스페이스에 레이블을 지정해야 해요. 예를 들어:

kubectl label namespace frontend namespace=frontend
kubectl label namespace backend namespace=backend

NetworkPolicy 문서의 namespaceSelector 아래에 레이블을 추가하세요. 예를 들어:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-namespaces
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: namespace
          operator: In
          values: ["frontend", "backend"]

참고: NetworkPolicy에서 네임스페이스의 이름을 직접 지정하는 것은 불가능합니다. matchLabels 또는 matchExpressions가 있는 namespaceSelector를 사용해 레이블을 기반으로 네임스페이스를 선택해야 해요.

이름으로 네임스페이스 대상 지정 (Targeting a Namespace by its name)

쿠버네티스 컨트롤 플레인은 모든 네임스페이스에 kubernetes.io/metadata.name이라는 변경 불가능한 레이블을 설정하며, 레이블의 값은 네임스페이스 이름입니다.

NetworkPolicy는 어떤 객체 필드로도 네임스페이스를 이름으로 대상으로 할 수 없지만, 표준화된 레이블을 사용해 특정 네임스페이스를 대상으로 할 수 있어요.

Pod 수명주기 (Pod lifecycle)

참고: 다음은 준수(conformant) 네트워킹 플러그인과 준수 NetworkPolicy 구현을 가진 클러스터에 적용됩니다.

새 NetworkPolicy 객체가 생성되면 네트워크 플러그인이 새 객체를 처리하는 데 시간이 걸릴 수 있어요. NetworkPolicy의 영향을 받는 pod가 네트워크 플러그인이 NetworkPolicy 처리를 완료하기 전에 생성되면, 그 pod는 보호되지 않은 채 시작될 수 있고, NetworkPolicy 처리가 완료되면 격리 규칙이 적용됩니다.

네트워크 플러그인이 NetworkPolicy를 처리하면,

NetworkPolicy의 영향을 받는 새로 생성된 모든 pod는 시작되기 전에 격리됩니다. NetworkPolicy 구현은 pod 수명주기 전체, 그 pod의 어떤 컨테이너가 시작되는 정확한 첫 순간부터 필터링이 유효함을 보장해야 해요. pod 수준에서 적용되기 때문에 NetworkPolicies는 init 컨테이너, sidecar 컨테이너, 일반 컨테이너에 동일하게 적용됩니다.
허용 규칙은 격리 규칙 후에 적용되거나 (또는 동시에 적용될 수 있습니다). 최악의 경우, 격리 규칙은 이미 적용되었지만 허용 규칙은 아직 적용되지 않았다면 새로 생성된 pod는 처음 시작될 때 네트워크 연결이 전혀 없을 수 있어요.

만들어진 모든 NetworkPolicy는 결국 네트워크 플러그인이 처리하지만, 정확히 언제 그런 일이 일어나는지 쿠버네티스 API로 알 수 있는 방법은 없어요.

따라서 pod는 예상과 다른 네트워크 연결로 시작되는 것에 대해 복원력(resilient)이 있어야 합니다. pod가 시작되기 전에 특정 목적지에 도달할 수 있음을 확인해야 한다면, [init 컨테이너]를 사용해 kubelet이 앱 컨테이너를 시작하기 전에 그 목적지에 도달할 수 있기를 기다릴 수 있어요.

모든 NetworkPolicy는 결국 선택된 모든 pod에 적용됩니다. 네트워크 플러그인이 NetworkPolicy를 분산 방식으로 구현할 수 있기 때문에, pod가 처음 생성될 때나 pod 또는 정책이 변경될 때 pod가 네트워크 정책에 대해 약간 일관되지 않은 관점을 볼 수 있어요. 예를 들어 Node 1의 Pod A와 Node 2의 Pod B에 모두 도달할 수 있어야 하는 새로 생성된 pod는, Pod A에는 즉시 도달할 수 있지만 Pod B에는 몇 초 후에야 도달할 수 있다는 것을 발견할 수 있습니다.

NetworkPolicy와 `hostNetwork` pod (NetworkPolicy and `hostNetwork` pods)

hostNetwork pod에 대한 NetworkPolicy 동작은 정의되어 있지 않지만, 두 가지 가능성으로 제한되어야 합니다.

네트워크 플러그인이 hostNetwork pod 트래픽을 다른 모든 트래픽과 구분할 수 있고 (같은 노드의 서로 다른 hostNetwork pod의 트래픽을 구분하는 것을 포함), hostNetwork pod에 일반 pod-network pod에 적용하는 것과 똑같이 NetworkPolicy를 적용합니다.
네트워크 플러그인이 hostNetwork pod 트래픽을 제대로 구분할 수 없으므로, podSelector와 namespaceSelector를 일치시킬 때 hostNetwork pod를 무시합니다. hostNetwork pod로 오고 가는 트래픽은 노드 IP로 오고 가는 다른 모든 트래픽과 동일하게 취급됩니다. (이것이 가장 일반적인 구현입니다.)

이것은 다음 때 적용됩니다.

hostNetwork pod가 spec.podSelector에 의해 선택되는 경우.

  ...
  spec:
    podSelector:
      matchLabels:
        role: client
  ...

hostNetwork pod가 ingress 또는 egress 규칙의 podSelector 또는 namespaceSelector에 의해 선택되는 경우.

  ...
  ingress:
    - from:
      - podSelector:
          matchLabels:
            role: client
  ...

동시에 hostNetwork pod는 자신이 있는 노드와 같은 IP 주소를 가지므로, 그들의 연결은 노드 연결로 취급됩니다. 예를 들어 ipBlock 규칙으로 hostNetwork Pod로부터의 트래픽을 허용할 수 있어요.