[Cilium Study] Cilium Security

 

Cilium 공식 문서에서 제공하는 Cilium 보안에 대한 내용이다.

Cilium 에서는 3 종류의 보안기능을 제공한다.

• Identity-Based (Layer 3)
• Port level (Layer 4)
• Application protocol level (Layer 7)

출처 : https://docs.cilium.io/en/stable/security/network/identity/

 

 

• 보안 정책은 세션 기반 프로토콜에 대해 상태 저장 정책이 적용되어, 응답 패킷은 자동으로 허용된다.
• 보안 정책은 수신 or 송신 시 적용된다.
• 기본 보안 정책
  • 정책이 로드 되지 않은 경우, 정책 적용이 명시적으로 활성화되지 않는 한 모든 통신을 허용하는 것이 기본동작이다.
  • 첫 번째 정책 규칙이 로드되는 즉시 정책 적용이 자동으로 활성화되며, 모든 통신은 허용 목록에 추가되어야 하며, 그렇지 않으면 관련 패킷이 삭제된다.
  • 마찬가지로, 엔드포인트에 L4 정책이 적용되지 않으면 모든 포트와 통신이 허용된다.
  • 엔드포인트에 하나 이상의 L4 정책을 연결하면 명시적으로 허용되지 않는 한 포트에 대한 모든 연결이 차단된다.
• Envoy Proxy

출처 : https://docs.cilium.io/en/stable/security/network/proxy/envoy/

• 투명한 암호화 : IPSec or WireGuard 로 Cilium을 관리하는 호스트 트래픽과 엔드 포인트 간 트래픽의 투명한 암호화 지원
  • IPSec : Limit (BPF 홋트 라우팅에서는 미동작, IPSec 터널 당 단일 CPU 코어로 제한)
  • WireGuard : 터널 모드는 두 번 캡슐화 됨

 

Identity

모든 엔드포인트에 ID가 할당. ID는 Labels와 클러스터 내에 유일한 ID로 구성

• 엔드포인트에는 Security Relevant Labels에 일치하는 ID가 할당된다.
• 엔드포인트들이 동일한 Security Relevant Labels 사용 시 동일한 ID를 공유

kubectl get ciliumendpoints.cilium.io -n kube-system
kubectl get ciliumidentities.cilium.io

 

Identity가 뭔가?

• 엔드포인트의 ID는 엔드포인트에서 파생된 Pod 또는 Container와 연관된 레이블을 기반으로 결정된다.
• Pod 또는 Container가 시작되면 Cilium은 컨테이너 런타임에서 수신한 이벤트를 기반으로 네트워크에서 Pod 또는 Container를 나타내는 엔드 포인트를 생성한다.
• 다음 단계로 Cilium은 생성된 엔드포인트의 ID를 확인한다. Pod 또는 Container의 레이블이 변경될 때마다 ID가 재확인되고 필요에 따라 자동으로 수정된다.

# kubesystem 
kubectl get ciliumidentities.cilium.io 44818 -o yaml | yq
kubectl exec -it -n kube-system ds/cilium -- cilium identity list
kubectl get pod -n kube-system -l k8s-app=kube-dns --show-labels

 

위 kube-system namespace 에 있는 pod 목록에서 coredns pod가 2개 있고 같은 Security IDENTITY를 가지는 것을 확인했다.

해당 IDENTITY를 가지는 Namespace 의 속성, Identity list, Labels 를 출력해본 결과이다.

두개의 Pod가 같은 LABELS를 가지는 것을 확인

 

기동 중인 Pod에 Label 추가 후 Cilium id(Security label)에 반영이 되나?

kubectl label pods -n kube-system -l k8s-app=kube-dns study=8w
kubectl exec -it -n kube-system ds/cilium -- cilium identity list

study=8w 이라는 Label을 추가했더니 Security Identity가 변경된 것을 확인

kubectl edit deploy -n kube-system coredns
...
  template:
    metadata:
      labels:
        app: testing
        k8s-app: kube-dns
...

kubectl exec -it -n kube-system ds/cilium -- cilium identity list
...

여기서도 app: testing을 추가하니 security identity가 변경되는 것을 확인했다.

• Cilium은 pod update 이벤트를 watch하므로, labels 변경 시 endpoint가 waiting-for-identity상태로 전환되어 새로운 identity를 할당받는다.
• 이로 인해 security labels와 관련된 네트워크 정책도 자동으로 재적용된다.
• 예시: 간단한 pod(simple pod)를 생성하면 초기 security identity(ex: 12345)가 할당된다.
• 이후 kubectl label pod/simple-pod run=not-simple-pod --overwrite로 labels를 변경하면, kubectl get ciliumendpoints 명령에서 identity가 새 값(예: 8710)으로 업데이트된 것을 확인할 수 있습니다. 이는 policy enforcement에 즉시 반영된다.
• 다만, 대규모 클러스터에서 자주 labels를 변경하면 identity할당이 빈번해져 성능 저하가 발생할 수 있으며, identity-relevant labels 를 제한하는 것이 권장된다.

Special Identities

• Cilium에서 관리하는 모든 엔드포인트에는 ID가 할당된다.
• Cilium에서 관리하지 않는 네트워크 엔드포인트와의 통신을 허용하기 위해 이러한 엔드포인트를 나타내는 특수 ID가 존재한다.
• 특별히 예약된 ID는 reserved 문자열 접두사가 붙는다.

Identity	숫자 ID	설명
reserved:unknown	0	파생(derivation)할 수 없는 신원
reserved:host	1	로컬 호스트, 로컬 호스트 IP에서 발생하거나 그 IP로 지정된 모든 트래픽
reserved:world	2	클러스터 외부의 모든 네트워크 엔드포인트
reserved:unmanaged	3	Cilium이 관리하지 않는 엔드포인트
reserved:health	4	Cilium 에이전트가 생성하는 상태 점검 트래픽
reserved:init	5	아직 신원이 할당되지 않은 엔드포인트에 부여되는 초기(init) Identity
reserved:remote-node	6	모든 원격 클러스터 호스트의 집합
reserved:kube-apiserver	7	kube-apiserver를 서비스하는 백엔드를 가진 원격 노드
reserved:ingress	8	Ingress 프록시의 연결에서 소스 주소로 사용되는 IP에 부여됨

 

Identity Management in the Cluster

• ID는 전체 클러스터에서 유효하다.
• 즉, 여러 클러스터 노드에서 여러 개의 Pod 또는 Container가 시작되더라도 ID 관련 레이블을 공유하는 경우 모든 Pod 또는 Container가 단일 ID를 확인하고 공유한다.
• 이를 위해서는 클러스터 노드 간의 조정이 필요하다.
• 엔드포인트 ID를 확인하는 작업은 분산 키-값 저장소를 통해 수행된다.
• 분산 키-값 저장소는 다음 값이 이전에 확인되지 않은 경우 새로운 고유 식별자를 생성하는 형태의 원자적 연산을 수행할 수 있도록 한다.
• 이를 통해 각 클러스터 노드는 ID 관련 레이블 하위 집합을 생성한 다음 키-값 저장소를 쿼리하여 ID를 도출할 수 있다.
• 레이블 집합이 이전에 쿼리되었는지 여부에 따라 새 ID가 생성되거나 초기 쿼리의 ID가 반환된다.

Network Policy 3가지 형식

출처 : https://isovalent.com/blog/post/intro-to-cilium-network-policies/

• Pod의 유입 또는 유출 시 L3 및 L4 정책을 지원하는 표진 NetworkPolicy 리소스이다.
• 3~7 계층에서 수신 및 송신 모두에 대한 정책 지정을 지원하는 CustomResourceDefinition 으로 제공되는 확장된 CiliumNetworkPolicy 형식이다.
• CiliumClusterNetworkPolicy 형식은 Cilium에서 적용할 클러스터 전체 정책을 지정하는 클러스터 범위 CustomResourceDefinition이다. 이 사양은 네임스페이스가 지정되지 않는 CiliumNetworkPolicy와 동일하다.

Policy Enformenet Modes by Cilium Network Policy

Enforcement 모드의 3가지 정책

• default
• always
• never

Endpoint default poilicy

• 기본적으로 모든 엔드포인트에 대해 모든 송신 및 수신 트래픽이 허용된다. 네트워크 정책에 다라 엔드포인트가 선택되면 명시적으로 허용된 트래픽만 허용되는 기본 거부 상태로 전환된다. 이 상태는 방향별로 적용된다.
  • 규칙이 엔드포인트를 선택하고 해당 규칙에 수신 섹션이 있는 경우, 엔드포인트는 수신에 대해 기본 거부 모드로 전환된다.
  • 규칙이 엔드포인트르 선택하고 규칙에 송신 섹션이 있는 경우, 엔드포인트는 송신에 대해 기본 거부 모드로 전환된다.
• EnableDefaultDeny 7계층 정책에는 적용되지 않는다.
  • 7계층 모두 허용이 포함되지 않는 7계층 규칙을 추가하면 default-deny 가 명시적으로 비활성화된 경우에도 삭제가 발생한다.

Rule Basics

• 엔드포인트 선택기 / 노드 선택기
  • 정책 규칙이 적용될 엔드포인트 또는 노드를 선택한다. 정책 규칙은 선택기에 지정된 레이블과 일치하는 모든 엔드포인트에 적용된다.
• 입구
  • 엔드포인트의 유입 시, 즉 엔드포인트에 들어오는 모든 네트워크 패킷에 대해 적용해야 하는 규칙 목록
• 출구
  • 엔드포인트의 출구에서 적용되어야 하는 규칙 목록, 즉 엔드포인트를 떠나는 모든 네트워크 패킷에 적용되어야 하는 규칙 목록
• 라벨
  • 라벨은 규칙을 식별하는데 사용된다. 라벨들 사용하여 규칙을 나열하고 삭제할 수 있다.
  • K8S를 통해 가져온 정책 규칙에는 NetworkPolicy 또는 CiliumNetworkPolicy 리소스에 지정된 이름에 해당하는 레이블이 자동으로 io.cilium.k8s.policy.name=NAME 지정됨.

Cilium Endpoint lifecycle

출처 : https://docs.cilium.io/en/stable/security/policy/lifecycle/

• restoring:  Cilium이 시작되기 전에 엔드포인트가 먼저 시작되었으며, Cilium이 그 네트워킹 구성을 복원하고 있는 중이다.
• waiting-for-identity: Cilium이 해당 엔드포인트에 고유한 Identity를 할당하고 있는 중이다.
• waiting-to-regenerate: 엔드포인트가 identity를 할당받았으며, 네트워킹 구성이 생성되기를 기다리는 중이다.
• regenerating: 엔드포인트의 네트워킹 구성이 생성되는 중이다.
• ready: 엔드포인트의 네트워킹 구성이 성공적으로 (재)생성되었다.
• disconnecting: 엔드포인트가 삭제되는 중이다.
• disconnected: 엔드포인트가 삭제되었다.