위협 모델

위협 모델 (Threat Model)

Cilium의 위협 모델을 설명하는 문서예요. Cilium 아키텍처의 보안적 의미, 데이터를 보호하는 통제, 프로덕션 환경 운영을 위한 권장 통제를 다뤄요.

출처: Threat Model

본문

이 섹션은 Cilium의 위협 모델을 제시해요. 이 위협 모델은 관심 있는 당사자가 다음을 이해할 수 있게 해 줘요.

  • Cilium 아키텍처의 보안 관련 의미
  • Cilium의 다양한 구성 요소를 통해 흐르는 데이터를 보호하기 위해 마련된 통제
  • 프로덕션 환경에서 Cilium을 실행하기 위한 권장 통제

범위와 전제 조건 (Scope and Prerequisites)

이 위협 모델은 프로덕션 환경에서 실행되는 최신 버전의 Cilium에 영향을 줄 수 있는 가능한 공격을 고려해요. Cilium의 아키텍처나 보안 태세에 큰 변화가 있을 때 갱신돼요.

이 모델은 공급망 공격, 예를 들어 악의적인 기여자가 의도적으로 취약한 코드를 Cilium에 주입하는 공격은 고려하지 않아요. 공급망 공격에 관심이 있는 사용자를 위해, Cilium의 보안 감사는 SLSA 프레임워크에 대해 Cilium의 공급망 통제를 평가했어요.

단순화를 위해 이 모델은 단일 클러스터 아키텍처를 다뤄요. Cluster Mesh를 사용할 때는 연결된 모든 클러스터가 단일 신뢰 도메인을 형성해요. 자세한 내용은 Cluster Mesh security model을 참고하세요.

다음 위협 모델을 이해하려면 독자는 기본 Kubernetes 개념에 익숙하고, Cilium의 아키텍처와 구성 요소에 대한 높은 수준의 이해가 필요해요.

방법론 (Methodology)

이 위협 모델은 일반적인 배포 스택의 서로 다른 위치에 배치된 8가지 유형의 위협 행위자를 고려해요. 주로 Kubernetes를 예로 사용하지만, 다른 오케스트레이션 시스템으로 배포하거나 Kubernetes 외부에서 Cilium을 실행할 때도 위협 모델은 정확해요. 공격자들은 서로 다른 수준의 초기 권한을 가지며, 이는 위협의 성격과 이전 침해의 범위에 따라 Cilium이 제공할 수 있는 보안 보장에 대한 광범위한 개요를 제공해요.

각 위협 행위자에 대해 이 가이드는 STRIDE 방법론을 사용해 가능한 공격을 평가해요. STRIDE 집합의 한 공격 유형이 다른 공격으로 이어질 수 있는 경우(예: 변조가 서비스 거부로 이어짐), 가장 큰 영향을 미치는 공격 유형 아래에 공격 경로를 설명했어요. 식별된 잠재적 공격에 대해 클러스터를 침해하는 식별된 공격의 위험을 줄이는 데 사용할 수 있는 통제를 권장해요. 권장 통제를 적용하는 것은 프로덕션에서 Cilium을 안전하게 실행하기 위해 강력히 권장돼요.

참조 아키텍처 (Reference Architecture)

이해를 돕기 위해 아래 그림과 같이 Cilium을 실행하는 단일 Kubernetes 클러스터를 고려해 보세요.

위협 표면 (The Threat Surface)

위 시나리오에서 Cilium 보안 통제의 목표는, Cilium이 직면한 위협 행위자의 능력을 고려해 가능한 범위 내에서 Cilium 플랫폼의 모든 구성 요소가 올바르게 동작하도록 보장하는 거예요. 보호해야 할 핵심 구성 요소는 다음과 같아요.

  • Kubernetes 파드, 호스트 프로세스 또는 전체 가상 머신으로서 노드에서 실행되는 Cilium 에이전트
  • Cilium 상태(CRD 또는 etcd 같은 외부 키-값 저장소로 저장)
  • Cilium이 커널에 로드한 eBPF 프로그램
  • Cilium이 관리하는 네트워크 패킷
  • Cilium이 수집하고 Hubble이 저장하는 관측성 데이터

위협 모델 (The Threat Model)

각 공격자 유형에 대해 그들이 사용할 수 있는 그럴듯한 공격 유형, Cilium이 이러한 공격으로부터 보호하는 방법, Cilium이 제공하는 보안 통제를 고려해요. Cilium이 요구하는 높은 권한의 결과로 발생할 수 있는 공격에 대해서는 사용자가 환경을 보호하기 위해 적용해야 할 완화책도 제안해요.

Kubernetes 워크로드 공격자 (Kubernetes Workload Attacker)

첫 번째 시나리오로, Kubernetes 파드에 접근해 컨테이너 안에서 임의 코드를 실행할 수 있게 된 공격자를 고려해 보세요. 예를 들어 취약한 서비스가 네트워크에 외부적으로 노출된 경우 발생할 수 있어요. 이 경우 피해 파드가 (Kubernetes 또는 호스트에서) 상승된 권한을 가지지 않고 호스트 파일에 직접 접근할 수 없다고 가정해요.

이 시나리오에서 Cilium 스택을 침해할 가능성은 없어요. 실제로 Cilium은 사용자가 그러한 공격의 범위를 제한할 수 있는 여러 기능을 제공해요.

  • Cilium의 네트워크 정책은 Kubernetes 워크로드 사이, 그리고 Kubernetes 워크로드와 Kubernetes 클러스터 외부 또는 워커 노드에서 실행되는 "외부" 엔드포인트 사이에 최소 권한 격리를 제공하는 데 사용될 수 있어요. 사용자는 이상적으로 서비스 간 예상 통신만 허용하는 구체적인 allow 규칙을 정의해야 해요.
  • Cilium의 네트워크 연결성은 투명 암호화를 사용하지 않더라도 공격자가 다른 워크로드를 위한 트래픽을 관찰하거나 다른 파드의 신원을 "스푸핑"하는 트래픽을 보내는 것을 방지해요. 파드는 출처 IP 사용 제한과 터널링 트래픽 전송 제한 때문에 다른 파드를 "스푸핑"하는 트래픽을 보낼 수 없어요.
  • Cilium의 Hubble flow-event 관측성은 공격자의 L3/L4 및 L7 네트워크 연결에 대한 신뢰할 수 있는 감사를 제공하는 데 사용될 수 있어요.
권장 통제 (Recommended Controls)
  • Kubernetes 워크로드에는 정의된 resource limits가 있어야 해요. 이는 클러스터의 잘못된 배포로 인해 Cilium이 리소스를 굶지 않도록 보장하는 데 도움이 돼요.
  • Cilium은 Kubernetes, cgroups 또는 기타 통제를 통해 시스템 리소스에 우선 접근 권한을 부여할 수 있어요.
  • Tetragon 같은 런타임 보안 솔루션을 배포해 컨테이너 침해가 발생할 때 감지되도록 해야 해요.

제한 권한 호스트 공격자 (Limited-privilege Host Attacker)

이 시나리오에서 공격자는 호스트 PID 또는 네트워크 네임스페이스(또는 둘 다)에 직접 접근해 임의 코드를 실행할 수 있지만, Cilium 구성 요소를 비활성화하거나 Cilium이 의존하는 eBPF 및 기타 커널 상태를 훼손할 수 있는 "root"와 동등한 권한은 없어요. 이러한 접근 수준은 여러 이유로 존재할 수 있어요.

  • "root" 권한이나 capability 없이 호스트 PID 또는 네트워크 네임스페이스에서 실행되는 파드 또는 기타 컨테이너. 여기에는 hostNetwork: true와 hostPID: true 컨테이너가 포함돼요.
  • 노드에 대한 비-"root" SSH 또는 기타 콘솔 접근.
  • 컨테이너 네임스페이스에서 "탈출"했지만 비특권 사용자로 실행되는 컨테이너화된 워크로드.

이 경우 공격자는 아래 설명처럼 Cilium의 일부 네트워크 통제를 우회할 수 있게 돼요.

  • 비특권 공격자가 컨테이너 런타임에 접근할 수 있고 Cilium이 컨테이너로 실행되고 있다면, 공격자는 노드에서 실행되는 Cilium 에이전트를 변조할 수 있게 돼요.
  • 호스트에 직접 워크로드를 생성해 서비스 거부도 가능해요.
  • 권한 상승: 공격자가 보낸 트래픽은 더 이상 Kubernetes 또는 컨테이너 네트워킹 Cilium 네트워크 정책의 적용을 받지 않아요. 호스트 네트워킹 Cilium 정책은 계속 적용돼요. 클러스터 내 다른 트래픽은 영향을 받지 않아요.
  • Cilium의 네트워크 연결성은 투명 암호화를 사용하지 않더라도 공격자가 다른 워크로드를 위한 트래픽을 관찰하거나 다른 파드의 신원을 스푸핑하는 트래픽을 보내는 것을 방지해요.
  • Cilium의 Hubble flow-event 관측성은 공격자의 L3/L4 및 L7 네트워크 연결에 대한 신뢰할 수 있는 감사를 제공하는 데 사용될 수 있어요. 공격자가 보낸 트래픽은 특정 Kubernetes 워크로드가 아닌 워커 노드에 귀속돼요.
권장 통제 (Recommended Controls)

Kubernetes Workload Attacker에 대한 권장 통제에 더해:

  • 침해 가능성을 줄이기 위해 컨테이너 이미지를 정기적으로 패치해야 해요.
  • 가능하면 최소 컨테이너 이미지를 사용해야 해요.
  • 가능하면 호스트 수준 권한을 피해야 해요.
  • 컨테이너 사용자가 기본 컨테이너 런타임에 접근할 수 없도록 해야 해요.

Root 동등 호스트 공격자 (Root-equivalent Host Attacker)

"root" 권한 호스트 공격자는 로컬 호스트에서 모든 것을 할 수 있는 완전한 권한을 가져요. 이 접근은 여러 이유로 존재할 수 있어요.

  • Kubernetes 워커 노드에 대한 Root SSH 또는 기타 콘솔 접근.
  • 특권 사용자로서 컨테이너 네임스페이스에서 탈출한 컨테이너화된 워크로드.
  • privileged: true 또는 CAP_BPF, CAP_NET_ADMIN, CAP_NET_RAW, CAP_SYS_ADMIN 같은 중요한 capability로 실행되는 파드.

이 상황에서 STRIDE가 다루는 모든 잠재적 공격이 가능해요. 주목할 점:

  • 공격자는 노드의 eBPF를 비활성화해 Cilium의 네트워크 및 런타임 가시성과 시행을 무력화할 수 있어요. 이후 공격자의 모든 추가 작업은 무제한이며 감사되지 않아요.
  • 공격자는 호스트의 모든 워크로드에 걸친 네트워크 연결을 관찰할 수 있어요.
  • 공격자는 어떤 신원의 파드에서 온 것처럼 보이는 트래픽을 노드에서 스푸핑할 수 있어요.
  • 물리 네트워크가 ARP 포이즈닝을 허용하거나, 어떤 다른 공격이 피해 노드가 다른 노드로 향하는 트래픽을 "끌어들이게" 할 수 있다면, 공격자는 클러스터 전역 사전 공유 키를 사용하므로 IPsec으로 암호화된 트래픽조차도 클러스터의 모든 트래픽을 가로챌 수 있어요.
  • 공격자는 Cilium의 자격 증명을 사용해 Kubernetes API 서버와 Cilium의 etcd 키-값 저장소(사용 중인 경우)를 공격할 수 있어요.
  • 피해 노드가 cilium-operator 파드를 실행 중이라면, 공격자는 노드에서 발견한 cilium-operator 서비스 어카운트 자격 증명을 사용해 다른 노드에 대한 서비스 거부 공격을 수행할 수 있어요.

이 공격 시나리오는 Kubernetes 노드를 보호하고, 컨테이너 워크로드에 사용 가능한 권한을 최소화하며, 노드·컨테이너·API 서버 수준에서 의심스러운 활동을 모니터링하는 것의 중요성을 강조해요.

권장 통제 (Recommended Controls)

Limited-privilege Host Attacker에 대한 통제에 더해:

  • 권한 있는 접근이 있는 워크로드를 검토해야 해요. 권한 있는 접근은 필수적인 경우에만 배포에 제공해야 해요.
  • 권한 있는 접근이 있는 워크로드로의 연결을 제한하도록 네트워크 정책을 구성해야 해요.
  • Kubernetes 감사 로깅을 활성화하고, 감사 로그를 자동 검토를 위해 중앙화된 외부 위치로 보내야 해요.
  • 의심스러운 활동에 경보하도록 감지를 구성해야 해요.
  • cilium-operator 파드는 일반 워크로드를 실행하는 노드에 스케줄링하면 안 되고, 컨트롤 플레인 노드에서 실행하도록 구성해야 해요.

중간자 공격자 (Man-in-the-middle Attacker)

이 시나리오에서 공격자는 Kubernetes 워커 노드 사이의 기본 네트워크에 접근하지만, Kubernetes 워커 노드 자체에는 접근하지 않아요. 이 공격자는 악성 네트워크 트래픽을 검사·수정·주입할 수 있어요.

이러한 공격자의 위협 매트릭스는 다음과 같아요.

  • 투명 암호화가 없으면 공격자는 오버레이 및 네이티브 라우팅 모드 모두에서 워크로드 간 트래픽을 검사할 수 있어요.
  • 파드 네트워크 구성(파드 IP 주소와 포트 포함)을 아는 공격자는 패킷을 위조해 클러스터에 트래픽을 주입할 수 있어요.
  • 공격자의 동작에 따라 서비스 거부가 발생할 수 있어요.
  • Cilium 구성 요소 간 모든 연결과 다른 목적지로의 데이터 내보내기에는 TLS가 필요하므로 스푸핑이나 변조의 여지가 없어요.
  • 투명 암호화가 없으면 공격자는 네트워크 수준에서 사용 가능한 대로 관측성 데이터를 재현할 수 있어요.
  • 공격자가 Hubble Prometheus 메트릭을 스크랩해 정보 유출이 발생할 수 있어요. 이 메트릭은 기본적으로 비활성화되어 있으며 네트워크 흐름에 대한 민감한 정보를 포함할 수 있어요.
  • 공격자의 동작에 따라 서비스 거부가 발생할 수 있어요.
권장 통제 (Recommended Controls)
  • 워크로드 간 통신의 기밀성을 보장하기 위해 Transparent Encryption을 구성해야 해요.
  • Prometheus 메트릭 엔드포인트와 Prometheus 서버 간의 통신에 TLS를 구성해야 해요.
  • 특히 특정 경우에 Hubble 메트릭을 스크랩하도록 Prometheus 서버만 허용하도록 네트워크 정책을 구성해야 해요.

네트워크 공격자 (Network Attacker)

우리 위협 모델에서 일반 네트워크 공격자는 Kubernetes 워커 노드와 같은 기본 IP 네트워크에 접근하지만, 노드 사이에 인라인으로 있지는 않아요. 이 공격자는 여전히 Kubernetes 워커 노드에 도달하는 IP 계층 트래픽을 보낼 수 있다고 가정해요. 이는 위에서 설명한 중간자 공격의 더 약한 변형으로, 공격자는 워커 노드에만 트래픽을 주입할 수 있고 응답은 볼 수 없어요.

이러한 공격자의 위협 매트릭스는 다음과 같아요.

  • 파드 네트워크 구성(파드 IP 주소와 포트 포함)을 아는 공격자는 패킷을 위조해 클러스터에 트래픽을 주입할 수 있어요.
  • 공격자의 동작에 따라 서비스 거부가 발생할 수 있어요.
  • 공격자의 동작에 따라 서비스 거부가 발생할 수 있어요.
  • 활성화된 특정 메트릭에 따라 공격자가 Cilium 또는 Hubble Prometheus 메트릭을 스크랩해 정보 유출이 발생할 수 있어요.
권장 통제 (Recommended Controls)
  • 워크로드 간 통신의 기밀성을 보장하기 위해 Transparent Encryption을 구성해야 해요.

Kubernetes API 서버 공격자 (Kubernetes API Server Attacker)

이 유형의 공격은 Kubernetes API 서버에 대한 네트워크 접근과 Kubernetes API 요청을 허용하는 자격 증명을 가진 모든 사용자나 코드가 수행할 수 있어요. 이러한 권한은 사용자가 API 서버 상태를 읽거나 조작(예: CRD 변경)할 수 있게 해 줘요.

이 섹션은 API 서버 접근이 전체든 제한적이든 관계없이 Kubernetes API 서버 접근을 통해 노출될 수 있는 모든 공격을 다루기 위한 거예요.

이러한 공격자의 위협 매트릭스는 다음과 같아요.

  • Cilium이 특권 파드로 실행되므로, Cilium 파드에 kubectl exec 접근이 있는 Kubernetes API 사용자는 사실상 root 동등 호스트 공격자가 돼요.
  • 워크로드 설정을 구성할 권한이 있는 공격자는 사실상 Kubernetes Workload Attacker가 돼요.
  • 클러스터의 Cilium* CustomResourceDefinitions와 Cilium의 모든 CustomResource를 수정할 능력은 다음과 같은 효과를 가질 수 있어요.
    • CiliumIdentity와 CiliumEndpoint 또는 CiliumEndpointSlice 리소스를 만들거나 수정할 능력은 공격자가 파드의 신원을 변조할 수 있게 해 줘요.
    • Kubernetes 또는 Cilium NetworkPolicy를 삭제할 능력은 정책 시행을 제거해요.
    • 많은 수의 CiliumIdentity 리소스를 만들면 서비스 거부가 발생할 수 있어요.
    • 클러스터 외부의 워크로드를 네트워크에 추가할 수 있어요.
    • 워크로드 간 트래픽 라우팅 설정을 수정할 수 있어요.
    • 이러한 행동의 누적 효과는 단일 노드 침해를 다중 노드 침해로 확대시키는 결과를 낳을 수 있어요.
  • Cilium 에이전트 파드에 kubectl exec 접근이 있는 공격자는 eBPF 프로그램을 수정할 수 있어요.
  • 권한 있는 Kubernetes API 서버 접근(Cilium 파드에 대한 exec 접근 또는 Kubernetes 시크릿 보기 접근)은 공격자가 IPsec에 사용되는 사전 공유 키에 접근할 수 있게 해 줄 수 있어요. 중간자 공격자가 사용하면 워크로드 통신의 기밀성과 무결성을 훼손할 수 있어요.
  • 공격자의 접근 수준에 따라 신원을 스푸핑하거나 정책 시행을 변조하는 능력으로 네트워크 데이터를 볼 수도 있어요.
  • 워크로드 설정을 구성할 권한이 있는 사용자는 서비스 거부를 일으킬 수 있어요.
권장 통제 (Recommended Controls)
  • 사용자와 서비스 어카운트에 필요한 권한만 부여하도록 Kubernetes RBAC를 구성해야 해요. 특히 kube-system과 cilium 네임스페이스의 리소스에 대한 접근은 매우 제한되어야 해요.
  • CiliumEnvoyConfig(CEC)와 CiliumClusterwideEnvoyConfig(CCEC) 사용의 보안 영향과 구현 세부 사항을 이해하려면 L7-aware traffic management 문서를 검토하세요.
  • Kubernetes 감사 로그를 사용해 API 서버에 대한 요청을 자동 검토하고, 의심스러운 활동에 경보하도록 감지를 구성해야 해요.

Cilium 키-값 저장소 공격자 (Cilium Key-value Store Attacker)

Cilium은 etcd 같은 외부 키-값 저장소를 사용해 상태를 저장할 수 있어요. 이 시나리오에서 Cilium etcd 엔드포인트에 대한 네트워크 접근과 그 etcd 엔드포인트에 접근할 자격 증명을 가진 사용자를 고려해요. etcd 엔드포인트의 자격 증명은 Kubernetes 시크릿으로 저장되므로, 어떤 공격자도 키-값 저장소에 접근하기 전에 먼저 이 시크릿을 침해해야 해요.

  • etcd에서 Identities 또는 Endpoints를 만들거나 수정할 능력은 공격자가 어떤 파드에든 어떤 신원을 "부여"할 수 있게 해 줘요. 이런 방식으로 신원을 스푸핑하는 능력은 예를 들어 원격 노드에 적용될 ingress 분할 규칙을 훼손할 목적으로 신원을 스푸핑해 단일 노드 침해를 다중 노드 침해로 확대하는 데 사용될 수 있어요.
  • 공격자는 클러스터 내 트래픽 라우팅을 수정할 수 있으며, 그 결과 중간자 공격자의 권한을 얻을 수 있어요.
권장 통제 (Recommended Controls)
  • Cilium 구성을 저장하기 위해 배포된 etcd 인스턴스는 Kubernetes 클러스터 구성의 일부로 보통 배포되는 인스턴스와 독립적이어야 해요. 이 분리는 Cilium etcd 침해가 더 큰 클러스터 전역 영향으로 이어질 위험을 줄여요.
  • Kubernetes 시크릿에 대한 접근을 제한하려면 Kubernetes RBAC 통제를 적용해야 해요.
  • 시크릿 데이터에 대한 접근을 감지하고 그러한 접근이 의심스러우면 경보하려면 Kubernetes 감사 로그를 사용해야 해요.

Hubble 데이터 공격자 (Hubble Data Attacker)

이것은 Hubble 데이터를 저장하거나 노출하는 Kubernetes 워커 노드 또는 기타 시스템에 대한 네트워크 도달 가능성을 가진 공격자로, 잠재적으로 민감한 Hubble 흐름 또는 프로세스 데이터에 접근하는 것이 목표예요.

다음을 올바르게 구성했다면 관측성 데이터에 대한 위협은 없어요.

  • hubble-relay 또는 hubble-ui 서비스에 대한 접근을 제한하는 네트워크 정책
  • cilium, hubble-relay 또는 hubble-ui 파드에 대한 제한된 접근
  • 외부 데이터 내보내기용 TLS
  • 내보낸 데이터의 목적지에서의 보안 통제
권장 통제 (Recommended Controls)
  • 네트워크 정책이 hubble-relay와 hubble-ui 서비스에 대한 접근을 제한해야 해요.
  • Kubernetes RBAC를 사용해 cilium-* 또는 hubble-* 파드에 대한 접근을 제한해야 해요.
  • Hubble Relay API와 Hubble UI에 대한 접근에 TLS를 구성해야 해요.
  • 데이터 내보내기에 TLS를 올바르게 구성해야 해요.
  • 내보낸 데이터의 목적지 데이터 저장소를 보호해야 해요(예: 저장 시 암호화와 클라우드 공급자별 RBAC 통제 적용).

전체 권장 사항 (Overall Recommendations)

Cilium으로 프로덕션 Kubernetes 클러스터를 구성할 때 사용할 권장 통제를 요약하면 다음과 같아요.

  • Kubernetes 역할이 사용자 요구에 맞게 적절히 범위가 지정되고, 파드의 서비스 어카운트 권한이 워크로드의 필요에 맞게 긴밀하게 범위가 지정되도록 보장하세요. 특히 민감한 네임스페이스, exec 동작, Kubernetes 시크릿에 대한 접근은 모두 고도로 통제되어야 해요.
  • 서비스 거부 공격의 가능성을 줄이기 위해 가능하면 워크로드에 resource limits을 사용하세요.
  • 워크로드 권한과 capability는 워크로드 기능에 필수적인 경우에만 부여하고, 워크로드 동작을 제한·모니터링할 특정 통제가 있는지 확인하세요.
  • Kubernetes의 네트워크 트래픽이 분리되도록 네트워크 정책을 사용하세요.
  • 워크로드 간 통신이 보호되도록 Cilium에서 Transparent Encryption을 사용하세요.
  • Kubernetes 감사 로깅을 활성화하고, 감사 로그를 중앙화된 모니터링 플랫폼으로 전달하며, 의심스러운 활동에 대한 알림을 정의하세요.
  • Hubble Relay와 Hubble UI 같은 외부 대면 서비스에 대한 접근에 TLS를 활성화하세요.
  • Kubernetes 클러스터 내 예상치 못한 동작을 신속히 감지하기 위해 런타임 보안 솔루션으로 Tetragon을 사용하세요.
  • toFQDNs 기반 네트워크 정책을 사용한다면, 클러스터 DNS 서비스로의 DNS 트래픽만 가로채는 것을 강력히 선호하세요. 자세한 내용은 워크로드 공격자 표를 참고하세요.

질문, 제안이 있거나 Cilium의 보안 태세 개선에 도움을 주고 싶다면 [email protected]로 연락해 주세요.

더 알아보기 (Learn more)