IngressLink TLS – Secret, BIG-IP Reference와 F5 CIS Multi-Cluster

이번 포스트에서는 BIG-IP CIS의 Custom Resource인 IngressLink 의 TLS 옵션이 어떤 역할을 하는지 살펴보겠습니다.

IngressLink의 TLS 옵션은 IngressLink를 통해 생성되는 BIG-IP Virtual Server에 적용될 SSL Profile을 정의하는 설정입니다. 해당 옵션은 CIS를 멀티 클러스터로 구성한 경우에 유효하며, BIG-IP가 HTTPS 트래픽을 직접 처리하고 제어하기 위한 구성 요소로 사용됩니다.

본 포스트는 OpenShift 기반의 2개의 클러스터 환경에서 진행되며, BIG-IP CIS가 Standalone Default Mode로 구성되어 있고 각 클러스터에 NGINX Plus Ingress Controller가 배포되어 있다고 가정합니다.

기본적인 환경 구성 및 설치 과정은 아래 포스트를 참고하시기 바랍니다.

• NGINX Ingress Operator 활용 OpenShift에 Ingress Controller 배포
• Standalone CIS Default Mode – BIG-IP CIS Multi-Cluster 구성
• IngressLink 활용 멀티 클러스터 Blue-Green 트래픽 전환 – BIG-IP CIS 환경

목차

1. IngressLink TLS 옵션이란?
2. 환경/버전 정보
3. 사전 준비
 3-1. NGINX Plus Ingress Controller VirtualServer 구성
 3-2. 인증서 Kubernetes Secret 생성
4. IngressLink TLS – Secret Reference 구성
5. IngressLink TLS – BIG-IP Reference 구성
6. 결론

1. IngressLink TLS 옵션이란?

IngressLink는 BIG-IP CIS와 NGINX Ingress Controller를 연동하기 위한 Kubernetes Custom Resource입니다. 기본적으로 BIG-IP는 L4 로드밸런서 역할을 수행하고, HTTP/HTTPS 기반의 라우팅은 NGINX Ingress Controller가 담당하는 구조로 동작합니다.

단일 클러스터 환경에서 IngressLink는 L4 Passthrough 방식으로 동작하기 때문에 별도의 TLS 옵션을 구성할 필요가 없습니다. 이 경우 BIG-IP는 암호화된 트래픽을 그대로 전달하며, 외부 클라이언트가 확인하는 인증서는 NGINX Ingress Controller에 적용된 인증서가 됩니다.

멀티 클러스터 환경에서 IngressLink는 여러 클러스터에 배포된 NGINX Ingress Controller를 클러스터별로 개별 Pool로 구성하며, BIG-IP의 iRule을 통해 각 Pool 간 트래픽을 분산합니다. 이 과정에서 weight 기반 트래픽 분산과 장애 발생 시 재시도 로직이 함께 수행됩니다. 이러한 트래픽 제어를 위해서는 BIG-IP가 백엔드의 HTTP 응답(예: 5xx)을 직접 확인할 수 있어야 합니다. 그러나 L4 Passthrough 방식으로 동작할 경우 암호화된 트래픽을 그대로 전달하기 때문에 HTTP 응답 내용을 확인할 수 없습니다.

따라서 BIG-IP는 클라이언트와의 TLS를 종단(Terminate)하고, 필요한 처리를 수행한 뒤 NGINX Ingress Controller 방향으로 다시 암호화하는 Re-encrypt 방식으로 동작해야 하며, 이를 위해 IngressLink의 TLS 옵션을 사용합니다.

이때 clientSSLs는 클라이언트와 BIG-IP 간 TLS를 종단하기 위한 SSL Profile을 의미하며, serverSSLs는 BIG-IP와 NGINX Ingress Controller 간 트래픽을 다시 암호화하기 위한 SSL Profile을 의미합니다.

tls:
  clientSSLs:
    - <인증서 Secret 이름 또는 BIG-IP SSL Profile 경로>
  serverSSLs:
    - <인증서 Secret 이름 또는 BIG-IP SSL Profile 경로>
  reference: secret  # 또는 bigip

clientSSLs와 serverSSLs는 배열 형태로 정의되며, 여러 개를 지정할 수 있어 멀티 도메인 환경에도 대응 가능합니다.

reference 값에 따라 TLS 구성 방식은 다음과 같이 나뉩니다.

• reference: bigip: BIG-IP에 사전 생성된 SSL Profile을 직접 지정하며, CIS가 별도의 리소스를 생성하지 않습니다.
• reference: secret: Kubernetes Secret에 저장된 인증서를 CIS가 읽어 BIG-IP에 SSL Profile을 자동으로 생성합니다.

2. 환경/버전 정보

3. 사전 준비

3-1. NGINX Plus Ingress Controller VirtualServer 구성

NGINX Plus Ingress Controller가 HTTPS 트래픽을 수신하고 백엔드 Pod로 라우팅할 수 있도록, NGINX Ingress Controller의 Custom Resource인 VirtualServer를 두 클러스터 모두에 배포합니다.
와일드카드 인증서를 Secret으로 생성하여 TLS 옵션에 적용했습니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: tls-backend-vs
  namespace: default
spec:
  host: tls-ocp-apps.devopssong.site
  tls:
    secret: tls-secret   # 와일드카드 인증서 Secret (*.devopssong.site)
  upstreams:
    - name: backend-upstream
      service: backend-svc
      port: 80
      connect-timeout: 5s
      read-timeout: 30s
      send-timeout: 30s
  routes:
    - path: /
      action:
        proxy:
          upstream: backend-upstream

$ oc apply -f tls-backend-vs.yaml
virtualserver.k8s.nginx.org/tls-backend-vs created
------
$ oc get virtualservers.k8s.nginx.org -n default
NAME             STATE   HOST                           IP    PORTS   AGE
tls-backend-vs   Valid   tls-ocp-apps.devopssong.site                 9s

이 구성에서 외부 클라이언트와 통신 시 사용되는 인증서는 NGINX Ingress Controller의 tls-secret이 됩니다. 이후 IngressLink에 tls 옵션을 구성하면, 클라이언트와 BIG-IP 간에는 IngressLink에 지정한 인증서가 사용되고, BIG-IP와 NGINX 간에는 Re-encrypt가 이루어지는 구조로 변경됩니다.

3-2. TLS 인증서 Kubernetes Secret 생성

IngressLink의 TLS 옵션을 구성하기 위해, BIG-IP에서 사용할 SSL Profile에 적용될 인증서를 Kubernetes Secret으로 생성합니다. 이 포스트에서는 앞서 구성한 VirtualServer에 적용된 tls-secret에 사용된 동일한 인증서를 사용했습니다.

IngressLink가 배포될 nginx-ingress 네임스페이스에 Secret을 생성합니다.

$ oc create secret tls wc-secret \
    --cert=wildcard.crt \
    --key=wildcard.key \
    -n nginx-ingress
secret/wc-secret created

4. IngressLink TLS – Secret Reference 구성

IngressLink TLS 옵션에서 reference: secret을 사용하면 Kubernetes Secret에 저장된 인증서를 CIS가 읽어 BIG-IP에 SSL Profile을 자동으로 생성합니다.

clientSSLs와 serverSSLs에 앞서 생성한 Secret 이름을 지정하고, reference: secret으로 설정합니다.

apiVersion: cis.f5.com/v1
kind: IngressLink
metadata:
  name: nginx-ingress
  namespace: nginx-ingress
spec:
  iRules:
    - /Common/Proxy_Protocol_iRule
  partition: ocp-cluster-1
  selector:
    matchLabels:
      app: ingresslink
  virtualServerName: cluster1-ingress
  virtualServerAddress: 192.168.40.229
  multiClusterServices:
    - clusterName: cluster1-1
      namespace: nginx-ingress
      service: npic-nginx-ingress-controller
      weight: 100
    - clusterName: cluster1-2
      namespace: nginx-ingress
      service: npic-nginx-ingress-controller
      weight: 0
  tls:
    reference: secret        # Kubernetes Secret 참조
    clientSSLs:
      - wc-secret            # nginx-ingress 네임스페이스의 Secret 이름
    serverSSLs:
      - wc-secret

$ oc apply -f ingresslink-secret-ref.yaml
ingresslink.cis.f5.com/nginx-ingress created
------
$ oc get ingresslinks.cis.f5.com -n nginx-ingress
NAME            IPAMVSADDRESS    AGE
nginx-ingress   192.168.40.229   43s

IngressLink 배포 후 BIG-IP GUI에서 생성된 Virtual Server를 확인합니다. HTTPS 트래픽을 수신하는 443 포트로 구성된 VirtualServer의 이름을 클릭하여 정보를 확인합니다.

IngressLink TLS 설정으로 인해 자동으로 구성된 SSL Profile을 확인할 수 있습니다.

Local Traffic > Profiles > SSL > Client 메뉴에서는 CIS가 Secret을 읽어 자동으로 생성한 Client SSL Profile을 확인할 수 있습니다.

Local Traffic > Profiles > SSL > Server 메뉴에서는 동일한 방식으로 생성된 Server SSL Profile을 확인할 수 있습니다.

5. IngressLink TLS – BIG-IP Reference 구성

IngressLink TLS 옵션에서 reference: bigip를 사용하면 BIG-IP에 이미 존재하는 SSL Profile을 직접 지정합니다. CIS가 별도의 리소스를 생성하지 않으며, BIG-IP에 사전 등록된 인증서와 Profile을 그대로 활용합니다.

이 방식은 사전에 BIG-IP에 SSL Profile이 구성되어 있어야 하며, 여러 리소스에서 공통으로 사용할 수 있도록 /Common 파티션에 생성하는 것이 일반적으로 권장됩니다.

clientSSLs와 serverSSLs에 BIG-IP 내 Profile의 전체 경로를 지정하고, reference: bigip으로 설정합니다.

# ingresslink-bigip-ref.yaml
apiVersion: cis.f5.com/v1
kind: IngressLink
metadata:
  name: nginx-ingress
  namespace: nginx-ingress
spec:
  iRules:
    - /Common/Proxy_Protocol_iRule
  partition: ocp-cluster-1
  selector:
    matchLabels:
      app: ingresslink
  virtualServerName: cluster1-ingress
  virtualServerAddress: 192.168.40.229
  multiClusterServices:
    - clusterName: cluster1-1
      namespace: nginx-ingress
      service: npic-nginx-ingress-controller
      weight: 100
    - clusterName: cluster1-2
      namespace: nginx-ingress
      service: npic-nginx-ingress-controller
      weight: 0
  tls:
    reference: bigip                        # BIG-IP SSL Profile 직접 참조
    clientSSLs:
      - /Common/wc-devopssong-cert          # BIG-IP에 등록된 Client SSL Profile 경로
    serverSSLs:
      - /Common/devopssong-ssl-profile      # BIG-IP에 등록된 Server SSL Profile 경로

$ oc apply -f ingresslink-bigip-ref.yaml
ingresslink.cis.f5.com/nginx-ingress configured
------
$ oc get ingresslinks.cis.f5.com -n nginx-ingress
NAME            IPAMVSADDRESS    AGE
nginx-ingress   192.168.40.229   2m10s

이전과 같이 Virtual Server의 상세 정보를 확인하면, reference: secret 방식과 동일하게 443 포트로 구성되고 Client SSL / Server SSL Profile이 연결된 것을 확인할 수 있습니다.

다만 이번에는 CIS가 새로운 SSL Profile을 생성하지 않고, 지정한 BIG-IP 기존 Profile(/Common/wc-devopssong-cert, /Common/devopssong-ssl-profile)이 그대로 적용됩니다.

6. 결론

이번 포스트에서는 IngressLink 의 TLS 옵션의 역할과 함께, reference: secret과 reference: bigip 두 가지 구성 방식을 비교해보았습니다.

IngressLink TLS 옵션은 단순한 SSL 설정이 아니라, 멀티 클러스터 환경에서 BIG-IP가 HTTPS 트래픽을 직접 처리하고 제어하기 위한 필수 구성 요소입니다. 특히 클러스터 간 트래픽 분산 및 장애 시 재시도 로직을 수행하기 위해서는 BIG-IP가 HTTP 응답을 확인할 수 있어야 하며, 이를 위해 Re-encrypt 구성이 필요합니다.

reference 설정에 따른 차이는 다음과 같습니다.

– Secret Reference: Kubernetes Secret 기반으로 CIS가 SSL Profile을 자동 생성 및 관리
– BIG-IP Reference: BIG-IP에 사전 구성된 SSL Profile을 직접 참조

두 방식은 동작 자체는 동일하며, 차이는 SSL 인증서와 Profile을 어디에서 관리하느냐에 있습니다.

Kubernetes 중심으로 인증서를 관리하는 환경에서는 Secret Reference 방식이 적합하며, BIG-IP에서 인증서 및 보안 정책을 중앙 관리하는 환경에서는 BIG-IP Reference 방식이 더 적합합니다.

BIG-IP CIS와 F5 NGINX Ingress Controller를 활용하여 Kubernetes/OpenShift 환경의 트래픽을 통합 관리하고 싶으시다면 NGINX STORE를 통해 문의하세요.