Cilium으로 TLS 암호화 연결 검사

네트워크 보안 팀이 Cilium을 사용해 TLS 암호화 연결을 투명하게 검사하는 방법을 소개하는 문서예요. 내부 CA 생성, 인증서 배포, TLS 인지 egress 정책 적용까지 전체 과정을 다뤄요.

출처: Inspecting TLS Encrypted Connections with Cilium

본문

이 문서는 네트워크 보안 팀이 Cilium을 사용해 TLS 암호화 연결을 투명하게 검사하는 방법에 대한 소개예요. 이 TLS 인지 검사는 클라이언트에서 서버로의 통신이 TLS로 보호되는(예: 클라이언트가 HTTPS로 API 서비스에 접근할 때) 연결에서도 Cilium이 API 인지 가시성과 정책을 기능하게 해 줘요. 이 기능은 전통적인 하드웨어 방화벽으로 가능한 것과 유사하지만, 전적으로 Kubernetes 워커 노드의 소프트웨어로 구현되며 정책 기반이라 선택된 네트워크 연결만 대상으로 검사할 수 있어요. 이런 유형의 가시성은 주어진 애플리케이션이 어떤 S3 버킷에 접근하는지 이해하는 것처럼 외부 API 서비스가 어떻게 사용되는지 모니터링하는 데 매우 가치가 있어요.

Cilium 설치 (Setup Cilium)

아직 Cilium을 설치하지 않았다면, Cilium Quick Installation 가이드에 따라 Kubernetes 클러스터를 빠르게 부트스트랩하고 Cilium을 설치하는 방법을 따라 해 보세요. 고민된다면 minikube 방식을 고르면 5분 안에 준비를 마칠 수 있어요.

TLS 인증서 모델 개요 (A Brief Overview of the TLS Certificate Model)

TLS는 HTTP 같은 다른 프로토콜을 "감싸는" 프로토콜로, 클라이언트와 서버 간 통신이 기밀성(의도된 수신자 외에는 아무도 데이터를 읽을 수 없음), 무결성(수신자가 데이터가 전송 중 변조되지 않았다는 것을 확인할 수 있음), 인증(송신자가 의도된 목적지와 대화하고 있다는 것을 확인할 수 있음)을 갖도록 보장해요. 이 문서에서는 매우 단순화된 TLS 개요를 제공하지만, 전체 세부 사항은 https://en.wikipedia.org/wiki/Transport_Layer_Security를 참고하세요.

인증 관점에서 TLS 모델은 주어진 네트워크 서비스(예: www.cilium.io)가 자신이 주장하는 존재임을 증명하는 것을 만드는 데 신뢰되는 엔티티인 "인증 기관"(CA, Certificate Authority)에 의존해요. 목표는 클라이언트와 서버 사이의 네트워크에서 악의적인 당사자가 트래픽을 가로채 목적지 서버인 척하는 것을 막는 거예요.

네트워크 보안 모니터링을 위한 "친화적 가로채기"의 경우, Cilium은 TLS 검사 기능이 있는 전통적인 방화벽과 유사한 모델을 사용해요. 네트워크 보안 팀이 외부 목적지에 대한 대체 인증서를 만드는 데 사용할 수 있는 자체 "내부 인증 기관"을 만들어요. 이 모델은 각 클라이언트 워크로드도 이 새 인증서를 신뢰해야 해요. 그렇지 않으면 클라이언트의 TLS 라이브러리가 연결을 유효하지 않은 것으로 거부해요. 이 모델에서 네트워크 방화벽은 내부 CA가 서명한 인증서를 사용해 목적지 서비스인 것처럼 행동하며 TLS 연결을 종료해요. 이는 방화벽이 애플리케이션 계층 데이터를 검사하고 심지어 수정한 다음, 실제 목적지 서비스로 또 다른 TLS 연결을 시작할 수 있게 해 줘요.

TLS의 CA 모델은 암호화 키와 인증서에 기반해요. 위 모델을 실현하려면 네 가지 주요 단계가 필요해요.

CA 개인 키와 CA 인증서를 생성해 내부 인증 기관을 만든다.
TLS 검사가 원하는 모든 목적지(아래 예제의 httpbin.org)에 대해, 목적지 DNS 이름과 일치하는 common name으로 개인 키와 인증서 서명 요청을 생성한다.
CA 개인 키를 사용해 서명된 인증서를 만든다.
TLS 검사가 이루어지는 모든 클라이언트가 해당 CA가 서명한 모든 인증서를 신뢰하도록 CA 인증서를 설치했는지 확인한다.
Cilium이 클라이언트로부터의 초기 TLS 연결을 종료하고 목적지로의 새 TLS 연결을 만들기 때문에, 목적지 서비스로의 새 TLS 연결을 검증할 때 신뢰해야 할 CA 집합을 Cilium에 알려야 한다.

참고: 데모가 아닌 환경에서는 위 개인 키를 안전하게 보관하는 것이 극히 중요해요. 이 개인 키에 접근하는 사람은 누구든 TLS 암호화 트래픽을 검사할 수 있기 때문이에요(반면 인증서는 공개 정보이며 전혀 민감하지 않아요). 아래 가이드에서 CA 개인 키는 Cilium에 전혀 제공할 필요가 없어요(오프라인으로 수행할 수 있는 인증서 생성에만 사용되기 때문) 그리고 개별 목적지 서비스의 개인 키는 Kubernetes 시크릿으로 저장돼요. 이 시크릿은 Cilium이 접근할 수 있지만 일반 목적의 워크로드가 접근할 수 없는 네임스페이스에 저장해야 해요.

TLS 검사가 동작하는 방식 (How TLS Inspection works)

모든 TLS 검사는 수락될 인증서로 출발 연결을 종료한 다음, 필요하다면 클라이언트 인증서를 사용해 새 TLS 연결을 시작하는 데 의존해요. 이 때문에 네트워크 정책은 terminatingTLS와 선택적으로 originatingTLS 스탠자를 구성해야 해요. 네트워크 정책이 이 세부 내용을 포함하면, Cilium은 TLS 연결을 Envoy로 리다이렉트하고, TLS 핸드셰이크를 완료하고 구성된 네트워크 정책을 통과하는 연결을 허용해요.

구성에서 가장 중요한 부분 중 하나는 인증서가 Envoy에 어떻게 전달되는지예요. 현재 버전에서 Cilium은 NPDS(원래 버전)와 SDS(새롭고 더 나은 버전) 두 가지 옵션이 있어요.

네트워크 정책 검색 서비스 (NPDS, Network Policy Discovery Service)

이 버전에서 인증서와 키는 Cilium 소유의 Network Policy Discovery Service 전용 필드에 Base64 인코딩 텍스트로 인라인 전송돼요. 이는 구축하기가 간단하다는 장점이 있었지만 큰 단점이 따랐어요. TLS 가로채기를 수행하는 각 네트워크 정책 규칙이 Envoy의 NPDS 구성에 각 시크릿의 사본을 자체적으로 인라인으로 유지해요. 따라서 (큰 설치에서 그럴 가능성이 있듯이) 같은 시크릿을 여러 번 재사용한다면(예: 많은 SAN에 대해 종료할 인증서 하나를 생성하지만 그 인증서를 사용하는 규칙이 여러 개인 경우, 또는 originatingTLS 구성에 유효한 루트 인증서 번들을 포함하는 경우), 인증서의 여러 사본이 Envoy의 메모리에 저장돼요. 이 메모리 사용은 대규모 설치에서 정말 늘어날 수 있어요. 또한 시크릿을 SDS(Secret Discovery Service)로 보낼 때 보호하기 위해 수행된 작업의 이점도 얻지 못해요.

시크릿 검색 서비스 (SDS, Secret Discovery Service)

위의 두 가지 이유 때문에 Envoy는 Cilium 1.17부터 네트워크 정책 시크릿에 대한 SDS를 지원해요. 이 구성에서 Cilium은 구성된 시크릿 네임스페이스에서 관련 시크릿을 읽고, 핵심 Envoy SDS API를 사용해 그 시크릿을 Envoy에 노출해요. 그런 다음 그 시크릿은 Base64 인코딩 텍스트로 직접 포함되는 대신 이름으로 네트워크 정책 필터를 구성하도록 Envoy에 보내지는 NPDS 구성에서 참조돼요. 이는 Envoy가 Ingress나 Gateway API 구성의 시크릿과 같은 방식으로 NPDS용 SDS 시크릿을 조회한다는 뜻이에요. 이 방법은 본질적으로 값으로 전달되는 대신 참조로 전달되므로 Envoy가 시크릿의 저장을 중복 제거할 수도 있게 해 줘요. 이전 NPDS 방법보다 이러한 이점 때문에 SDS는 Cilium 1.17 기준 새 Cilium 설치의 기본값이에요.

TLS 가로채기 구성 (Configuring TLS Interception)

1.17 이후 버전에서 Cilium을 사용하는 방법은 세 가지가 있어요.

SDS를 사용해, 네트워크 정책에서 참조된 시크릿은 클러스터 어디에나 위치할 수 있고, Cilium Operator에 의해 구성된 네임스페이스(기본 cilium-secrets)로 복사된 다음 거기서 SDS로 동기화되고 그 이름으로 NPDS에서 참조돼요. 이것이 새 클러스터의 기본값이며 권장 운영 방법이에요.
시크릿은 클러스터 어디에나 위치할 수 있고, Cilium Agent는 클러스터의 모든 시크릿에 대한 읽기 접근 권한을 부여받을 수 있어요. 이 경우 시크릿은 Cilium Agent가 원래 위치에서 직접 읽어 NPDS에 인라인으로 보내져요. 이 배포 방법은 이전 버전과의 호환성을 위해 포함됐으며, 에이전트의 보안 범위를 크게 확장하므로 권장되지 않아요.
시크릿을 cilium-secrets 네임스페이스에 직접 추가한 다음 그 네임스페이스에서 네트워크 정책으로 참조할 수 있어요. 이것도 이 기능이 실제로 어떻게 사용됐는지에 대한 사용자 피드백에 기반한 이전 버전과의 호환성을 위해 포함됐어요. 설정을 구성하지 않았고 Helm의 upgradeCompatibility 설정을 1.16 이하로 사용하는 업그레이드된 클러스터의 기본값이에요.

TLS 가로채기에 영향을 주는 Helm의 설정 세 가지가 있어요.

tls.secretsNamespace.name - 기본값 cilium-secrets. Policy 시크릿에 사용될 시크릿 네임스페이스를 구성해요. 이는 기본적으로 Ingress, Gateway API, BGP 구성의 유사한 설정과 같은 값으로 설정되지만 다른 값으로 설정할 수 있다는 점을 유의하세요.
tls.readSecretsOnlyFromSecretsNamespace - 기본값 true. 이 설정은 Cilium Agent가 구성된 Secrets 네임스페이스에서만 시크릿을 읽어야 하는지, 아니면 클러스터 내 위치에서 직접 시크릿을 읽으려 시도해야 하는지를 Helm 차트와 Cilium에 알려줘요. 이전 버전의 Cilium은 local(Secrets 네임스페이스에서만 읽음을 의미) 또는 k8s(모든 네임스페이스에서 읽음을 의미)로 설정할 수 있는 tls.secretsBackend 항목을 사용했지만, 그 이름이 기능과 분리됐기 때문에 그 필드는 이제 폐기됐어요. tls.secretsBackend를 k8s로 설정한 기존 설치물은 대신 tls.readSecretsOnlyFromSecretsNamespace를 false로 설정하도록 마이그레이션해야 하며, 이 설정은 Cilium 1.17에는 계속 동작할 거예요. tls.secretsBackend는 향후 Cilium 버전에서 제거될 거예요.
tls.secretSync.enabled - 새 클러스터의 기본값 true. 네트워크 정책 시크릿에 대한 시크릿 동기화와 SDS 사용을 구성해요. SDS 사용에는 이것이 true로 설정되어야 하고, 이 필드가 false로 설정되면 비활성화되어야 하므로, SDS 구성용 추가 필드는 가치가 없었어요.

TLS 가로채기의 세 가지 모드 구성 (Configuring the three available modes for TLS Interception)

SDS 모드 (권장, 새 클러스터 기본값):

Helm Values에 다음 설정을 지정하세요.

tls:
  readSecretsOnlyFromSecretsNamespace: true
  secretsNamespace:
    name: cilium-secrets # This setting is optional, as it is the default
  secretSync:
    enabled: true

클러스터의 모든 시크릿 읽기 모드 (권장되지 않음):

Helm Values에 다음 설정을 지정하세요.

tls:
  readSecretsOnlyFromSecretsNamespace: false
  secretSync:
    enabled: false

시크릿 네임스페이스에서만 읽기, SDS 없음 (업그레이드된 클러스터 기본값):

Helm Values에 다음 설정을 지정하세요.

tls:
  readSecretsOnlyFromSecretsNamespace: true
  secretsNamespace:
    name: cilium-secrets # This setting is optional, as it is the default
  secretSync:
    enabled: false

참고: 이 모드를 사용한다면, 이 페이지의 검증 지침에서 kube-system에 대한 모든 참조를 cilium-secrets(또는 그 네임스페이스로 설정한 값)로 바꿔야 해요.

옵션을 선택하고 Cilium 설치를 그에 따라 구성했으면, 나머지 지침으로 설치를 검증하세요.

데모 애플리케이션 배포 (Deploy the Demo Application)

TLS 가로채기를 시연하기 위해 DNS 인지 정책 예제에 사용했던 것과 같은 mediabot 애플리케이션을 사용할 거예요. 이 애플리케이션은 HTTPS를 사용해 Star Wars API 서비스에 접근하는데, 일반적으로는 모든 애플리케이션 데이터가 네트워크로 보내지기 전에 TLS로 암호화되므로 Cilium 같은 네트워크 계층 메커니즘이 통신의 HTTP 계층 세부 사항을 볼 수 없다는 뜻이에요.

이 가이드에서 배우게 될 내용은 다음과 같아요.

TLS 가로채기를 가능하게 하기 위해 내부 인증 기관(CA)과 해당 CA가 서명한 관련 인증서를 만드는 것.
DNS 기반 정책 규칙을 사용해 가로챌 트래픽을 선택하는 Cilium 네트워크 정책 사용.
cilium monitor를 사용해 HTTP 요청의 세부 사항을 검사하는 것(Hubble을 통해 이 가시성 데이터에 접근하고 Cilium 네트워크 정책을 적용해 HTTP 요청을 필터/수정하는 것도 가능하지만, 이 간단한 Getting Started 가이드의 범위를 벗어나요).

먼저 단일 파드 mediabot 애플리케이션을 만들 거예요.

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-dns/dns-sw-app.yaml
$ kubectl wait pod/mediabot --for=condition=Ready
$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
pod/mediabot                     1/1     Running   0          14s

TLS 키와 인증서 생성 및 설치 (Generating and Installing TLS Keys and Certificates)

이제 TLS를 이해하고 Cilium을 TLS 가로채기를 사용하도록 구성했으니, openssl 유틸리티를 사용해 적절한 키와 인증서를 생성하는 구체적인 단계를 진행할 거예요.

로컬 시스템에 openssl이 이미 설치되어 있다면 사용할 수 있지만, 그렇지 않다면 간단한 지름길로 kubectl exec을 사용해 어떤 cilium 파드 안에서 /bin/bash를 실행하고, 결과 openssl 명령을 실행하면 돼요. 그 결과 파일을 Kubernetes 시크릿을 만들거나 mediabot 파드로 복사하는 데 사용할 때 kubectl cp로 cilium 파드에서 복사해 내세요.

내부 인증 기관(CA) 만들기 (Create an Internal Certificate Authority (CA))

'myCA.key'라는 CA 개인 키를 생성하세요.

$ openssl genrsa -des3 -out myCA.key 2048

암호를 입력하세요. 나중에 일부 단계에서 기억해야 하니 잊지 마세요. 개인 키에서 CA 인증서를 생성하세요.

$ openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.crt

각 프롬프트에 입력하는 값은 특정 값일 필요도, 정확할 필요도 없어요.

주어진 DNS 이름에 대한 개인 키와 인증서 서명 요청 만들기 (Create Private Key and Certificate Signing Request for a Given DNS Name)

검사를 위해 가로챌 목적지 서비스의 DNS 이름(이 예제에서는 httpbin.org)과 일치하는 common name으로 내부 개인 키와 인증서 서명 요청을 생성하세요. 먼저 개인 키를 만드세요.

$ openssl genrsa -out internal-httpbin.key 2048

다음으로, 프롬프트에서 목적지 서비스의 DNS 이름을 common name 필드에 지정하는 인증서 서명 요청을 만드세요. 다른 모든 프롬프트는 아무 값이나 채울 수 있어요.

$ openssl req -new -key internal-httpbin.key -out internal-httpbin.csr

특정 값이어야 하는 유일한 필드는 Common Name이 클라이언트에 제공될 정확한 DNS 목적지 httpbin.org인지 확인하는 거예요. 이 예제 워크플로는 정책 YAML(아래)의 toFQDNs 규칙도 인증서의 DNS 이름과 일치하도록 갱신하기만 하면 어떤 DNS 이름에도 동작해요.

CA를 사용해 DNS 이름에 대한 서명된 인증서 생성 (Use CA to Generate a Signed Certificate for the DNS Name)

내부 CA 개인 키를 사용해 internal-httpbin.crt라는 httpbin.org용 서명된 인증서를 만드세요.

$ openssl x509 -req -days 360 -in internal-httpbin.csr -CA myCA.crt -CAkey myCA.key -CAcreateserial -out internal-httpbin.crt -sha256

다음으로, 목적지 서비스의 개인 키와 서명된 인증서를 모두 포함하는 Kubernetes 시크릿을 만듭니다.

$ kubectl create secret tls httpbin-tls-data -n kube-system --cert=internal-httpbin.crt --key=internal-httpbin.key

내부 CA를 클라이언트 파드의 신뢰 CA로 추가 (Add the Internal CA as a Trusted CA Inside the Client Pod)

CA 인증서가 클라이언트 파드 안에 들어가면, 애플리케이션이 사용하는 TLS 라이브러리가 CA 파일을 인식하도록 해야 해요. 대부분의 Linux 애플리케이션은 Linux 배포판과 함께 번들된 신뢰 CA 인증서 집합을 자동으로 사용해요. 이 가이드에서는 클라이언트로 Ubuntu 컨테이너를 사용하므로 Ubuntu 특정 지침으로 갱신할 거예요. 다른 Linux 배포판은 다른 메커니즘을 가져요. 또한 개별 애플리케이션은 OS 인증서 저장소 대신 자체 인증서 저장소를 활용할 수 있어요. Java 애플리케이션과 aws-cli가 두 가지 일반적인 예예요. 자세한 내용은 애플리케이션 또는 애플리케이션 런타임 문서를 참고하세요.

Ubuntu의 경우 먼저 추가 CA 인증서를 클라이언트 파드 파일시스템에 복사해요.

$ kubectl cp myCA.crt default/mediabot:/usr/local/share/ca-certificates/myCA.crt

그런 다음 이 인증서를 /etc/ssl/certs/ca-certificates.crt의 전역 신뢰 CA 인증서 집합에 추가하는 Ubuntu 특정 유틸리티를 실행해요.

$ kubectl exec mediabot -- update-ca-certificates

이 명령은 WARNING을 발행하지만 무시할 수 있어요.

Cilium에 신뢰 CA 목록 제공 (Provide Cilium with List of Trusted CAs)

다음으로, 보조 TLS 연결을 시작할 때 신뢰해야 할 CA 집합을 Cilium에 제공할 거예요. 이 목록은 여러분 조직이 신뢰하는 표준 전역 CA 집합에 해당해야 해요. 논리적 옵션은 OS가 신뢰하는 표준 CA 집합인데, 이는 TLS 검사 도입 전에 사용되던 CA 집합이기 때문이에요. 단순하게 유지하기 위해 이 예제에서는 mediabot 파드의 Ubuntu 파일시스템에서 이 목록을 복사할 거예요. 하지만 이 신뢰 CA 목록은 특정 TLS 클라이언트나 서버에 특화된 것이 아니므로, TLS 검사에 몇 개의 TLS 클라이언트·서버가 관여하든 이 단계는 한 번만 수행하면 된다는 것을 이해하는 것이 중요해요.

$ kubectl cp default/mediabot:/etc/ssl/certs/ca-certificates.crt ca-certificates.crt

그런 다음 이 인증서 번들을 사용해 Kubernetes 시크릿을 만들어 Cilium이 그 인증서 번들을 읽고 나가는 TLS 연결을 검증하는 데 사용할 수 있게 해요.

$ kubectl create secret generic tls-orig-data -n kube-system --from-file=ca.crt=./ca-certificates.crt

DNS 및 TLS 인지 Egress 정책 적용 (Apply DNS and TLS-aware Egress Policy)

지금까지 TLS 검사를 가능하게 하는 키와 인증서를 만들었지만, 어떤 트래픽을 가로채고 검사할지 Cilium에 알리지 않았어요. 이는 다른 Cilium 네트워크 정책에 사용되는 것과 동일한 Cilium 네트워크 정책 구조로 수행돼요. 다음 Cilium 네트워크 정책은 Cilium이 mediabot 파드와 httpbin.org 사이의 통신에 HTTP 인지 검사를 수행해야 한다는 것을 나타내요.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l7-visibility-tls"
spec:
  description: L7 policy with TLS
  endpointSelector:
    matchLabels:
      org: empire
      class: mediabot
  egress:
  - toFQDNs:
    - matchName: "httpbin.org"
    toPorts:
    - ports:
      - port: "443"
        protocol: "TCP"
      terminatingTLS:
        secret:
          namespace: "kube-system"
          name: "httpbin-tls-data"
      originatingTLS:
        secret:
          namespace: "kube-system"
          name: "tls-orig-data"
      rules:
        http:
        - {}
  - toPorts:
    - ports:
      - port: "53"
        protocol: ANY
      rules:
        dns:
          - matchPattern: "*"

정책을 자세히 살펴볼게요.

endpointSelector는 이 정책이 class: mediabot, org: empire 라벨의 파드에만 적용돼 egress 접근을 갖는다는 뜻이에요.
첫 번째 egress 섹션은 toFQDNs: matchName 지정을 사용해 httpbin.org로의 TCP 443 포트 egress를 허용해요.
toFQDNs 규칙 아래의 http 섹션은 그러한 연결을 HTTP로 파싱해야 하고, {} 정책은 모든 요청을 허용한다는 것을 나타내요.
terminatingTLS와 originatingTLS 섹션은 TLS 가로채기를 사용해 mediabot으로부터의 초기 TLS 연결을 종료하고 httpbin.org로의 새 아웃바운드 TLS 연결을 시작해야 한다는 것을 나타내요.
두 번째 egress 섹션은 mediabot 파드가 kube-dns 서비스에 접근할 수 있게 해요. rules: dns는 Cilium이 지정된 패턴과 일치하는 DNS 조회를 검사하고 허용하도록 지시한다는 점에 유의하세요. 이 경우 모든 DNS 쿼리를 검사하고 허용해요.

이 정책으로 mediabot은 kube-dns를 제외한 어떤 내부 클러스터 서비스에도 접근할 수 없고, 다른 외부 목적지에도 전혀 접근할 수 없다는 점을 유의하세요. 내부 클러스터 서비스 접근 제어 정책에 대해 자세히 알아보려면 Overview of Network Policy를 참고하세요.

정책을 적용해 볼게요.

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-tls-inspection/l7-visibility-tls.yaml

TLS 검사 시연 (Demonstrating TLS Inspection)

우리가 푸시한 정책이 mediabot에서 httpbin.org로의 모든 HTTPS 요청을 허용하지만, 모든 데이터를 HTTP 계층에서 파싱하므로 cilium monitor가 각 HTTP 요청과 응답을 보고할 거라는 점을 기억하세요. 이를 확인하려면 새 창을 열고 mediabot 파드와 같은 Kubernetes 워커 노드에서 실행 중인 cilium 파드(예: cilium-97s78)의 이름을 식별하는 명령을 실행하세요. 그런 다음 "L7 모드"에서 cilium-dbg monitor를 실행해 Cilium이 보고하는 HTTP 요청을 모니터링하세요.

$ kubectl exec -it -n kube-system cilium-d5x8v -- cilium-dbg monitor -t l7

다음으로 원래 창에서 mediabot 파드로부터 HTTPS로 httpbin.org에 접근할 수 있어요.

$ kubectl exec -it mediabot -- curl -sL 'https://httpbin.org/anything'
...
...

$ kubectl exec -it mediabot -- curl -sL 'https://httpbin.org/headers'
...
...

cilium-dbg monitor 창을 다시 보면 각 HTTP 요청과 응답을 볼 수 있어요. 예를 들면:

-> Request http from 2585 ([k8s:class=mediabot k8s:org=empire k8s:io.kubernetes.pod.namespace=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.cilium.k8s.policy.cluster=default]) to 0 ([reserved:world]), identity 24948->2, verdict Forwarded GET https://httpbin.org/anything => 0
-> Response http to 2585 ([k8s:io.kubernetes.pod.namespace=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.cilium.k8s.policy.cluster=default k8s:class=mediabot k8s:org=empire]) from 0 ([reserved:world]), identity 24948->2, verdict Forwarded GET https://httpbin.org/anything => 200

Cilium L4/L7 네트워크 정책에 대해 자세히 알아보려면 Layer 4 Policies와 Layer 7 Policies를 참고하세요.

정리 (Clean-up)

$ kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-dns/dns-sw-app.yaml
$ kubectl delete cnp l7-visibility-tls
$ kubectl delete secret -n kube-system tls-orig-data
$ kubectl delete secret -n kube-system httpbin-tls-data

Cilium으로 TLS 암호화 연결 검사