Hubble TLS 구성

Hubble TLS 구성 (Configure TLS with Hubble)

이 페이지는 환경에 맞게 Hubble을 TLS와 함께 구성하는 방법을 안내해요. Hubble을 활성화하는 방법은 각 Cilium Getting Started 가이드에 함께 제공됩니다.

출처: Configure TLS with Hubble

본문

Hubble API에 TLS 활성화

Hubble Relay가 배포되면 Hubble은 호스트 네트워크의 TCP 포트에서 수신합니다. 이를 통해 Hubble Relay가 클러스터의 모든 Hubble 인스턴스와 통신할 수 있어요. Hubble 인스턴스와 Hubble Relay 사이의 연결은 기본적으로 상호 TLS(mTLS)로 보호됩니다.

TLS 인증서는 자동으로 생성하거나 수동으로 제공할 수 있어요.

TLS 인증서를 자동으로 구성할 수 있는 옵션은 다음과 같아요:

각 방법은 인증서 회전 방식을 다르게 처리하지만, 최종 결과는 키 쌍을 담은 secret이 갱신된다는 점에서는 같아요. Hubble server와 Hubble Relay는 CA 인증서를 포함한 TLS 인증서를 핫 리로드(hot reload)하므로 기존 연결은 중단되지 않습니다. 새 연결은 Hubble server나 Hubble Relay를 재시작하지 않고도 자동으로 새 인증서를 사용해 설정돼요.

CronJob (certgen)

certgen을 사용하면 설치 시점에 TLS 인증서가 생성되고, (만료일과 무관하게) 갱신을 위해 Kubernetes CronJob이 스케줄됩니다. certgen 방식은 cert-manager보다 구현하기 쉽지만 유연성은 떨어져요.

다음 Helm 값으로 certgen을 구성합니다:

hubble:
  tls:
    auto:
      # enable automatic TLS certificate generation
      enabled: true
      # auto generate certificates using cronJob method
      method: cronJob
      # certificates validity duration in days (default 3 years)
      certValidityDuration: 1095
      # schedule for certificates re-generation (crontab syntax)
      schedule: "0 0 1 */4 *"

cert-manager

이 방법은 TLS 인증서 생성을 위해 cert-manager에 의존해요. cert-manager는 Kubernetes에서 TLS 인증서를 관리하는 사실상 표준(de facto) 방법이며, 다른 문서화된 방법들에 비해 다음과 같은 장점이 있습니다:

설치 단계:

  1. 먼저 cert-manager를 설치하고 issuer를 설정하세요. issuer가 cilium.io 도메인 이름 아래에서 인증서를 만들 수 있는지 확인하세요.
  2. 다음 Helm 값으로 Cilium을 설치하거나 업그레이드하세요:
hubble:
  tls:
    auto:
      # enable automatic TLS certificate generation
      enabled: true
      # auto generate certificates using cert-manager
      method: certmanager
      # certificates validity duration in days (default 3 years)
      certValidityDuration: 1095
      certManagerIssuerRef:
        # Reference to cert-manager's issuer
        group: cert-manager.io
        kind: ClusterIssuer
        name: ca-issuer

첫 Cilium 설치 동안에는, Cilium이 Certificate 리소스를 만들 때 cert-manager의 webhook이 아직 준비되지 않았을 수 있어요. 그런 경우 트러블슈팅을 참고하세요.

Helm

Helm을 사용하면 Cilium을 설치하거나 업그레이드할 때마다 TLS 인증서가 (재)생성돼요.

다음 Helm 값으로 Helm 인증서 생성을 구성합니다:

hubble:
  tls:
    auto:
      # enable automatic TLS certificate generation
      enabled: true
      # auto generate certificates using helm method
      method: helm
      # certificates validity duration in days (default 3 years)
      certValidityDuration: 1095

Helm 방식의 단점은 인증서가 자동으로 생성되지만 자동으로 갱신되지는 않는다는 점이에요. 따라서 인증서가 만료되기 전에(즉, 구성된 hubble.tls.auto.certValidityDuration 이전에) helm upgrade를 실행해야 합니다.

사용자 제공 인증서 (User Provided Certificates)

자체 TLS 인증서를 제공하려면 hubble.tls.auto.enabled을 false로 설정하고, 인증서를 담은 secret을 Cilium이 설치된 네임스페이스(보통 kube-system)에 만들고, secret 이름을 Helm에 제공해야 해요.

인증서의 **Common Name (CN)**과 **Subject Alternative Name (SAN)**은 다음과 같이 설정해야 합니다. <cluster-name>은 cluster.name으로 정의된 클러스터 이름을 가리켜요(기본값 default):

  • Hubble server: *.<cluster-name>.hubble-grpc.cilium.io
  • Hubble Relay: *.hubble-relay.cilium.io
  • Hubble UI: *.hubble-ui.cilium.io
  • Hubble metrics: <cluster-name>.hubble-metrics.cilium.io

인증서를 발급했으면 대상 네임스페이스에 secret을 만드세요.

각 secret은 다음 키를 포함해야 해요:

  • tls.crt: 인증서 파일.
  • tls.key: 개인 키 파일.
  • ca.crt: CA 인증서 파일.

다음 예제는 secret을 생성하는 방법을 보여줘요.

hubble server 인증서 secret을 생성하세요:

$ kubectl -n kube-system create secret generic hubble-server-certs --from-file=hubble-server.crt --from-file=hubble-server.key --from-file=ca.crt

hubble-relay가 활성화되어 있다면 다음 secret들을 생성해야 해요:

$ kubectl -n kube-system create secret generic hubble-relay-server-certs --from-file=hubble-relay-server.crt --from-file=hubble-relay-server.key --from-file=ca.crt
$ kubectl -n kube-system create secret generic hubble-relay-client-certs --from-file=hubble-relay-client.crt --from-file=hubble-relay-client.key --from-file=ca.crt

hubble-ui가 활성화되어 있다면 다음 secret을 생성해야 해요:

$ kubectl -n kube-system create secret generic hubble-ui-client-certs --from-file=hubble-ui-client.crt --from-file=hubble-ui-client.key --from-file=ca.crt

마지막으로 Hubble metrics API가 활성화되어 있다면 다음 secret을 생성해야 해요:

$ kubectl -n kube-system create secret generic hubble-metrics-certs --from-file=hubble-metrics.crt --from-file=hubble-metrics.key --from-file=ca.crt

secret을 생성한 후, 다음 Helm 값으로 secret 이름을 Helm에 제공하고 자동 인증서 생성을 비활성화하세요:

hubble:
  tls:
    auto:
      # Disable automatic TLS certificate generation.
      enabled: false
    server:
      existingSecret: hubble-server-certs
  relay:
    tls:
      server:
        # Enable TLS on Hubble Relay (optional).
        enabled: true
        existingSecret: hubble-relay-server-certs
      client:
        existingSecret: hubble-relay-client-certs
  ui:
    tls:
      client:
        existingSecret: hubble-ui-client-certs
  metrics:
    tls:
      # Enable TLS on the Hubble metrics API (optional).
      enabled: true
      server:
        existingSecret: hubble-metrics-certs
  • hubble.relay.tls.server.existingSecret과 hubble.ui.tls.client.existingSecret은 hubble.relay.tls.server.enabled=true(기본값 false)일 때만 제공하면 돼요.
  • hubble.ui.tls.client.existingSecret은 hubble.ui.enabled(기본값 false)일 때만 제공하면 돼요.
  • hubble.metrics.tls.server.existingSecret은 hubble.metrics.tls.enabled(기본값 false)일 때만 제공하면 돼요.

Hubble metrics API를 TLS로 구성하는 자세한 내용은 Hubble Metrics TLS 및 인증을 참고하세요.

트러블슈팅 (Troubleshooting)

TLS를 활성화한 후 문제가 발생하면 다음 지침으로 문제를 진단할 수 있어요.

cert-manager

Cilium이나 cert-manager를 설치하는 동안 다음 오류가 발생할 수 있어요:

Error: Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp x.x.x.x:443: connect: connection refused

이것은 Certificate의 CRD 리소스를 검증하는 데 사용되는 cert-manager의 webhook을 사용할 수 없을 때 발생해요. 해결 방법은 여러 가지가 있습니다. 다음 옵션 중 하나를 선택하세요.

먼저 CRD 설치 — Cilium과 cert-manager 전에 cert-manager CRD를 설치하세요 (kubectl로 CRD 설치에 관한 cert-manager 문서 참고):

$ kubectl create -f cert-manager.crds.yaml

그런 다음 cert-manager를 설치하고 issuer를 구성한 뒤 Cilium을 설치하세요.

Cilium 업그레이드 — TLS가 비활성화된 설치에서 Cilium을 업그레이드하세요:

$ helm install cilium cilium/cilium \
    --set hubble.tls.enabled=false \
    ...

그런 다음 cert-manager를 설치하고 issuer를 구성한 뒤 TLS를 활성화해서 Cilium을 업그레이드하세요:

$ helm install cilium cilium/cilium --set hubble.tls.enabled=true

webhook 비활성화 — cert-manager 검증을 비활성화하세요 (Cilium이 kube-system 네임스페이스에 설치되었다고 가정):

$ kubectl label namespace kube-system cert-manager.io/disable-validation=true

그런 다음 Cilium, cert-manager를 설치하고 issuer를 구성하세요.

호스트 네트워크 webhook — cert-manager가 호스트 네트워크 네임스페이스 안에서 webhook을 노출하도록 구성하세요:

$ helm install cert-manager jetstack/cert-manager \
        --set webhook.hostNetwork=true \
        --set 'webhook.tolerations[0].operator=Exists'

그런 다음 issuer를 구성하고 Cilium을 설치하세요.

Helm

Helm을 사용하면 인증서가 자동으로 갱신되지 않아요. 만료된 인증서 문제가 발생하면 helm upgrade를 실행해 인증서를 수동으로 갱신할 수 있습니다.

인증서 문제가 발생하면 인증서와 키를 디코딩해서 확인할 수 있어요:

$ kubectl -n kube-system get secret hubble-server-certs -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout
$ kubectl -n kube-system get secret hubble-server-certs -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -text -noout
$ kubectl -n kube-system get secret hubble-server-certs -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -text -noout

같은 명령을 다른 secret에도 사용할 수 있어요.

User Provided Certificates

hubble-relay가 활성화되었지만 응답하지 않거나 파드가 readiness probe에 실패한다면, 인증서를 확인하고 클라이언트 인증서가 hubble-server-certs secret에 지정된 CA(ca.crt)에 의해 발급되었는지 확인하세요.

또한 Hubble server용 인증서의 **Common Name (CN)**과 **Subject Alternative Name (SAN)**은 반드시 *.{cluster-name}.hubble-grpc.cilium.io로 설정해야 하며, 여기서 {cluster-name}은 cluster.name으로 정의된 클러스터 이름(기본값 default)이에요.

설치 검증 (Validating the Installation)

다음 섹션은 Hubble에 TLS가 활성화되어 있고 Hubble Relay와 Hubble Server 사이의 연결이 mTLS로 세션을 보호하는지 검증하는 방법을 안내해요. 또한 아래 명령은 TLS 구성에 문제가 있을 때 진단하는 데 사용할 수 있습니다.

시작하기 전에 다음 명령으로 TLS가 올바르게 구성되었는지 확인하세요:

$ kubectl get configmap -n kube-system cilium-config -oyaml | grep hubble-disable-tls
  hubble-disable-tls: "false"

hubble-disable-tls 구성 옵션이 false로 설정된 것을 확인할 수 있을 거예요.

Hubble 컴포넌트가 실행 중인 네임스페이스(예: kube-system)에 Hubble CLI 파드를 생성하세요:

$ kubectl apply -n kube-system -f https://raw.githubusercontent.com/cilium/cilium/main/examples/hubble/hubble-cli.yaml

새로 생성된 파드 안에서 hubble watch peers를 실행해 Hubble 서버를 나열하세요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- \
hubble watch peers --server unix:///var/run/cilium/hubble.sock

PEER_ADDED   172.18.0.2 kind-worker (TLS.ServerName: kind-worker.default.hubble-grpc.cilium.io)
PEER_ADDED   172.18.0.3 kind-control-plane (TLS.ServerName: kind-control-plane.kind.hubble-grpc.cilium.io)

첫 번째 peer의 IP와 서버 이름을 다음 단계를 위해 환경변수로 복사하세요:

Note

출력에 TLS.ServerName이 없다면 Hubble server에 TLS가 활성화되지 않은 것이므로 다음 단계가 동작하지 않아요. 그렇다면 이전 섹션을 참고해 TLS를 활성화하세요.

$ IP=172.18.0.2
$ SERVERNAME=kind-worker.default.hubble-grpc.cilium.io

Hubble Relay 클라이언트 인증서로 첫 번째 peer에 연결해, Hubble server가 올바른 인증서를 제시하는 클라이언트의 연결을 받는지 확인하세요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- \
hubble observe --server tls://${IP?}:4244 \
    --tls-server-name ${SERVERNAME?} \
    --tls-ca-cert-files /var/lib/hubble-relay/tls/hubble-server-ca.crt \
    --tls-client-cert-file /var/lib/hubble-relay/tls/client.crt \
    --tls-client-key-file /var/lib/hubble-relay/tls/client.key

Dec 13 08:49:58.888: 10.20.1.124:60588 (host) -> kube-system/coredns-565d847f94-pp8zs:8181 (ID:7518) to-endpoint FORWARDED (TCP Flags: SYN)
Dec 13 08:49:58.888: 10.20.1.124:36308 (host) <- kube-system/coredns-565d847f94-pp8zs:8080 (ID:7518) to-stack FORWARDED (TCP Flags: SYN, ACK)
Dec 13 08:49:58.888: 10.20.1.124:60588 (host) <- kube-system/coredns-565d847f94-pp8zs:8181 (ID:7518) to-stack FORWARDED (TCP Flags: SYN, ACK)
...
...

이제 클라이언트 인증서 없이 Hubble server를 조회해 보세요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- \
hubble observe --server tls://${IP?}:4244 \
    --tls-server-name ${SERVERNAME?} \
    --tls-ca-cert-files /var/lib/hubble-relay/tls/hubble-server-ca.crt

failed to connect to '172.18.0.2:4244': context deadline exceeded: connection error: desc = "error reading server preface: remote error: tls: certificate requiredd"
command terminated with exit code 1

TLS 없이 연결을 시도할 수도 있어요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- \
hubble observe --server ${IP?}:4244

failed to connect to '172.18.0.2:4244': context deadline exceeded: connection error: desc = "error reading server preface: EOF"
command terminated with exit code 1

연결을 트러블슈팅하려면 Hubble CLI 파드에 OpenSSL을 설치하세요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- apk add --update openssl

그런 다음 OpenSSL로 Hubble server에 연결해 TLS 핸드셰이크에 대한 자세한 정보를 얻으세요:

$ kubectl exec -it -n kube-system deployment/hubble-cli -- \
openssl s_client -showcerts -servername ${SERVERNAME} -connect ${IP?}:4244 \
-CAfile /var/lib/hubble-relay/tls/hubble-server-ca.crt

CONNECTED(00000004)
depth=1 C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
verify return:1
depth=0 CN = *.default.hubble-grpc.cilium.io
verify return:1
---
Certificate chain
 0 s:CN = *.default.hubble-grpc.cilium.io
   i:C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Aug 15 17:39:00 2024 GMT; NotAfter: Aug 15 17:39:00 2027 GMT
-----BEGIN CERTIFICATE-----
MIICNzCCAd2gAwIBAgIUAlgykDuc1J+mzseHS0pREX6Uv3cwCgYIKoZIzj0EAwIw
aDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDVNhbiBGcmFuY2lzY28xCzAJBgNVBAcT
AkNBMQ8wDQYDVQQKEwZDaWxpdW0xDzANBgNVBAsTBkNpbGl1bTESMBAGA1UEAxMJ
Q2lsaXVtIENBMB4XDTI0MDgxNTE3MzkwMFoXDTI3MDgxNTE3MzkwMFowKjEoMCYG
A1UEAwwfKi5kZWZhdWx0Lmh1YmJsZS1ncnBjLmNpbGl1bS5pbzBZMBMGByqGSM49
AgEGCCqGSM49AwEHA0IABGjtY50MM21TolEy5RUrBa6WqHsw7PjNB3MhYLCsuJmO
aQ1tIy6J2e7a9Cw2jmBlyj+dL8g0YLhRQX4n+leItSSjgaIwgZ8wDgYDVR0PAQH/
BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0O
BBYEFCDf5epVs8yyyZCdtBzc90HrQzpFMB8GA1UdIwQYMBaAFDKuJMmhNPJ71FvB
AyHEMztI62NbMCoGA1UdEQQjMCGCHyouZGVmYXVsdC5odWJibGUtZ3JwYy5jaWxp
dW0uaW8wCgYIKoZIzj0EAwIDSAAwRQIhAP0kyl0Eb7FBQw1uZE+LWnRyr5GDsB3+
6rA/Rx042XZgAiBZML3lOW60tWMI1Pyn4cR4trFbzZpsUSwnQmOAb+paEw==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.default.hubble-grpc.cilium.io
issuer=C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
---
Acceptable client certificate CA names
C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1106 bytes and written 437 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
08EBFFFFFF7F0000:error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required:ssl/record/rec_layer_s3.c:1605:SSL alert number 116
command terminated with exit code 1

출력을 분석해 보면:

  • Server Certificate: 서버가 제시하는 서버 인증서.
  • Acceptable client certificate CA names: 서버가 클라이언트 인증서에 대해 수락하는 CA 이름들.
  • SSL handshake has read 1108 bytes and written 387 bytes: 핸드셰이크에 대한 세부 정보. 오류가 발생했다면 여기에 표시돼요.
  • Verification: OK: 서버 인증서가 유효함.
  • Verify return code: 0 (ok): 서버 인증서가 성공적으로 검증됨.
  • error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required: 서버가 클라이언트 인증서를 요구함. 클라이언트 인증서를 제공하지 않았으므로 연결이 실패했어요.

올바른 클라이언트 인증서와 키를 제공하면 연결이 성공해야 해요:

$ kubectl exec -i -n kube-system deployment/hubble-cli -- \
openssl s_client -showcerts -servername ${SERVERNAME} -connect ${IP?}:4244 \
  -CAfile /var/lib/hubble-relay/tls/hubble-server-ca.crt \
  -cert /var/lib/hubble-relay/tls/client.crt \
  -key /var/lib/hubble-relay/tls/client.key

CONNECTED(00000004)
depth=1 C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
verify return:1
depth=0 CN = *.default.hubble-grpc.cilium.io
verify return:1
---
Certificate chain
 0 s:CN = *.default.hubble-grpc.cilium.io
   i:C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Aug 15 17:39:00 2024 GMT; NotAfter: Aug 15 17:39:00 2027 GMT
-----BEGIN CERTIFICATE-----
MIICNzCCAd2gAwIBAgIUAlgykDuc1J+mzseHS0pREX6Uv3cwCgYIKoZIzj0EAwIw
aDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDVNhbiBGcmFuY2lzY28xCzAJBgNVBAcT
AkNBMQ8wDQYDVQQKEwZDaWxpdW0xDzANBgNVBAsTBkNpbGl1bTESMBAGA1UEAxMJ
Q2lsaXVtIENBMB4XDTI0MDgxNTE3MzkwMFoXDTI3MDgxNTE3MzkwMFowKjEoMCYG
A1UEAwwfKi5kZWZhdWx0Lmh1YmJsZS1ncnBjLmNpbGl1bS5pbzBZMBMGByqGSM49
AgEGCCqGSM49AwEHA0IABGjtY50MM21TolEy5RUrBa6WqHsw7PjNB3MhYLCsuJmO
aQ1tIy6J2e7a9Cw2jmBlyj+dL8g0YLhRQX4n+leItSSjgaIwgZ8wDgYDVR0PAQH/
BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0O
BBYEFCDf5epVs8yyyZCdtBzc90HrQzpFMB8GA1UdIwQYMBaAFDKuJMmhNPJ71FvB
AyHEMztI62NbMCoGA1UdEQQjMCGCHyouZGVmYXVsdC5odWJibGUtZ3JwYy5jaWxp
dW0uaW8wCgYIKoZIzj0EAwIDSAAwRQIhAP0kyl0Eb7FBQw1uZE+LWnRyr5GDsB3+
6rA/Rx042XZgAiBZML3lOW60tWMI1Pyn4cR4trFbzZpsUSwnQmOAb+paEw==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.default.hubble-grpc.cilium.io
issuer=C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
---
Acceptable client certificate CA names
C = US, ST = San Francisco, L = CA, O = Cilium, OU = Cilium, CN = Cilium CA
Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1106 bytes and written 1651 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: 9ADFAFBDFFB876A9A8D4CC025470168D25485FF51929615199E9561F46FBF97B
    Session-ID-ctx:
    Resumption PSK: 58DD7621E7B353BD5C6FC3AAB5A907FF3D3251FAA184D28D2C69560E96806495
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 604800 (seconds)
    TLS session ticket:
    0000 - 55 93 99 70 30 37 6a 77-43 d7 0c 34 9f 24 51 40   U..p07jwC..4.$Q@
    ...
    ...
    0690 - 11 6d 26 ec 99 3a 6e a9-56 c9 ad a0 49 e2 f5 6a   .m&..:V...I..j

ctrl-d를 눌러 TLS 세션을 끝내면 연결이 종료되어야 해요. 세션이 끝난 뒤에는 다음과 유사한 출력이 보일 거예요:

@DONE
    06a0 - bf eb 8b 1d 8d 43 46 2a-07 02 e1 44 35 45 b1 a0   .....CF*...D5E..
    06b0 - 7d bb 27 2f 1a 35 b2 da-0d 00 15 fd 6c 1f 00 3b   }.'/.5......l..;
    06c0 - 9a 6e ff c9 5d ad 6b af-f7 20 39 99 5b ae 72 03   .n..].k.. 9.[.r.
    06d0 - c8 2d 93 7a e5 a7 e0 d5-70 95 8f b5 0b 56 9c      .-.z....p....V.

    Start Time: 1723744378
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

이 OpenSSL 명령의 출력은 이전 출력과 유사하지만 오류 메시지가 없어요.

또한 Post-Handshake New Session Ticket arrived로 시작하는 추가 섹션이 있는데, 이는 클라이언트 인증서가 유효하고 TLS 세션이 수립되었음을 나타내요. 연결이 끝난 후 출력되는 TLS 세션 요약도 수립된 TLS 세션의 지표로 사용할 수 있습니다.

Hubble Metrics TLS 및 인증 (Hubble Metrics TLS and Authentication)

Cilium 1.16부터 Hubble은 Hubble observer API 외에도 Hubble metrics API에 TLS를 구성하는 것을 지원해요.

이는 설치 또는 업그레이드 시점에 이전 섹션에서 설명한 TLS 구성 옵션과 함께 다음 옵션을 Helm에 지정해서 수행할 수 있습니다.

Note

이 섹션은 이미 Hubble metrics를 활성화했다고 가정해요.

Hubble metrics API에 TLS를 활성화하려면 옵션 목록에 다음 Helm 플래그를 추가하세요:

--set hubble.metrics.tls.enabled=true # Enable TLS on the Hubble metrics API

Hubble metrics API에 mTLS를 사용한 인증도 활성화하려면, 먼저 클라이언트 인증서를 검증하는 데 사용할 CA 인증서가 담긴 ConfigMap을 생성하세요:

kubectl -n kube-system create configmap hubble-metrics-ca --from-file=ca.crt

그런 다음 Helm 명령에 다음 플래그를 추가해 mTLS를 활성화하세요:

--set hubble.metrics.tls.enabled=true                       # Enable TLS on the Hubble metrics API
--set hubble.metrics.tls.server.mtls.enabled=true           # Enable mTLS authentication on the Hubble metrics API
--set hubble.metrics.tls.server.mtls.name=hubble-metrics-ca # Use the CA certificate from the ConfigMap

구성이 적용되면 클라이언트는 Hubble metrics API에 접근하기 위해 구성된 CA 인증서로 서명된 인증서로 인증해야 해요.

Note

Hubble metrics API에 TLS를 사용할 때는 tls_config를 설정해서 Prometheus 스크레이프 구성을 HTTPS로 업데이트하고 CA 인증서 경로를 제공해야 해요. mTLS를 사용할 때는 Prometheus가 Hubble metrics API에 인증할 수 있도록 CA 인증서로 서명된 클라이언트 인증서와 키도 제공해야 합니다.

TLS가 활성화된 상태로 Hubble API 접근 (Access the Hubble API with TLS Enabled)

예제는 CLI로 네트워크 흐름 살펴보기에서 가져왔어요.

TLS가 활성화된 상태로 Hubble API에 접근하려면, TLS를 활성화할 때 만들어진 secret에서 CA 인증서를 얻어야 해요. 다음 예제는 CA 인증서를 얻고 이를 사용해 Hubble API에 접근하는 방법을 보여줍니다.

hubble-relay-server-certs secret에서 CA 인증서를 얻으려면 다음 명령을 실행하세요:

$ kubectl -n kube-system get secret hubble-relay-server-certs -o jsonpath='{.data.ca\.crt}' | base64 -d > hubble-ca.crt

CA 인증서를 얻은 후, --tls로 TLS를 활성화하고 --tls-ca-cert-files 플래그로 CA 인증서를 지정할 수 있어요. 또한 Hubble Relay로 포트 포워딩할 때는 --tls-server-name 플래그를 지정해야 합니다:

$ hubble observe --tls --tls-ca-cert-files ./hubble-ca.crt --tls-server-name hubble.hubble-relay.cilium.io --pod deathstar --protocol http
May  4 13:23:40.501: default/tiefighter:42690 -> default/deathstar-c74d84667-cx5kp:80 http-request FORWARDED (HTTP/1.1 POST http://deathstar.default.svc.cluster.local/v1/request-landing)
May  4 13:23:40.502: default/tiefighter:42690 <- default/deathstar-c74d84667-cx5kp:80 http-response FORWARDED (HTTP/1.1 200 0ms (POST http://deathstar.default.svc.cluster.local/v1/request-landing))
May  4 13:23:43.791: default/tiefighter:42742 -> default/deathstar-c74d84667-cx5kp:80 http-request DROPPED (HTTP/1.1 PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port)

이 옵션들을 셸 세션에 유지하려면 다음 환경변수를 설정하세요:

$ export HUBBLE_TLS=true
$ export HUBBLE_TLS_CA_CERT_FILES=./hubble-ca.crt
$ export HUBBLE_TLS_SERVER_NAME=hubble.hubble-relay.cilium.io

더 알아보기 (Learn more)