[cilium] Cilium Network Policy

 

Cilium 의 네트워크 정책은 기본 쿠버네티스에서 제공하는 네트워크 정책과 유사하지만 근본적으로 다른 부분이 존재합니다.

쿠버네티스에서는 네트워크 정책 생성 시 all all allow 인 상황을 감안하고 정책을 생성해야 하지만, cilium 은 all all deny 인 상황에서

정책을 적용합니다. Cilium 의 공식문서를 통해 네트워크 정책을 살펴봅니다.

 

예제 구성 환경

 

cilium 의 network policy 정책을 이해하기 위해서 https://docs.cilium.io/en/stable/gettingstarted/demo/ 에서 제공하는 예제를 살펴봅니다. deathstar, tiefighter, xwing 의 세 가지 마이크로서비스 애플리케이션이 있습니다.

• deathstar 파드는 포트 80 에서 HTTP 웹서비스를 구동하며, 다른 웹 파드의 land 서비스를 제공하고 요청을 처리합니다.
• tiefighter 파드와 xwing 파드는 deathstar 파드로 land 서비스를 요청하는 클라이언트입니다.

아래 명령어로 예제 환경을 구성합니다.

kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.17.6/examples/minikube/http-sw-app.yaml

 

 

현재는 아무런 Network policy 를 적용하지 않았으므로 enable 된 ingress / egress 네트워크 정책들이 존재하지 않습니다.

 

L3 / L4 네트워크 정책 적용

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L3-L4 policy to restrict deathstar access to empire ships only"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

 

같은 empire org 에서 오는 네트워크 패킷만 허용하는 네트워크 정책으로 나머지 패킷들은 모두 드랍되는 정책을 생성하여 적용합니다.

주어진 yaml 파일을 적용하면 아래 그림처럼 deathstar 클래스 레이블이 부착된 파드에 대해 Ingress 정책이 새롭게 생성되었습니다.

(deathstar 클래스 레이블이 적용되어 있는 pod 에 ingress 정책이 enable 되어 있는 것을 볼 수 있습니다.)

 

 

정책 적용이 완료되었으니 테스트를 위해 다른 org(org: alliance) 에 속해 있는 xwing pod에서 통신 시도해봅니다.

 

kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing --connect-timeout 2

dropped 되는 패킷들 hubble-ui 결과 화면

 

핸드쉐이크 과정의 SYN 패킷이 바로 DROP 되는 것을 볼 수 있습니다.

같은 org 에 속해 있는 tiefighter 에서 deathstar 로 통신 시도하면 정상적으로 통신됩니다.

kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

 

L7 Policy 정책 적용

 

이전에 https://g-egg.tistory.com/171 살펴보았듯이 L7 네트워크 정책 적용을 하면 Userspace Proxy 영역을 거쳐 정책이 평가됩니다.

그림 상에서는 userspace 영역까지 올라가서 처리가 되는 것으로 보이지만, k describe ds -n kube-system cilium-envoy 명령어와

소켓 유형을 살펴보면 cilium-envoy 데몬셋이 HostPath 유형의 유닉스 소켓으로 확인할 수 있습니다.

 

 

L7 Policy 정책 예제

 

이번에는 같은 org pod 에서도 /v1/exhaust-port API 같은 인가되지 않은 API 는 제한하려고 합니다.

즉, tiefighter 에서 deathstar 로 요청 시 오직 /v1/request-landing API 요청만 가능해야 합니다.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/request-landing"

 

L7 정책 테스트

tiefighter 에서 deathstar 의 request-landing 서비스로 요청 시, 정상적으로 수행되는지 확인해봅니다.

hubble observe -f --pod deathstar --protocol http

kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

 

정상적으로 포워딩되고 있습니다. tiefighter 에서 인가하지 않은 /v1/exhaust-port API 요청 시 차단되는지 확인해봅니다.

hubble observe -f --pod deathstar --verdict DROPPED

kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port

 

http-request 레벨에서 차단됩니다.

아래 xwing 이 접속했을 때 TCP Level 에서 SYN 패킷이 차단되는 것과 다르게 HTTP 요청에서 차단되는 것을 확인할 수 있습니다.

hubble observe -f --pod xwing

kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing --connect-timeout 2

 

정리

• kubernetes 의 network policy 와 다르게 cilium network policy 는 기본 all all deny 정책이 적용됩니다.
  ( 허용해야 하는 트래픽 유형을 파악하고 cilium network policy 정책에 적용해야 한다. )
• L7 Policy 정책 적용 시에 Cilium-Envoy 데몬셋이 처리합니다.
• Cilium 은 StateFul 연결 추적을 수행합니다. 응답 리턴 패킷은 자동으로 허용합니다.