NGINX를 사용하여 Kubernetes에서 Multi-Tenancy 및 Namespace를 격리하는 방법

조직이 확장됨에 따라 Kubernetes의 개발 및 운영 워크플로(workflows)는 더욱 복잡해집니다. 일반적으로 각 팀이 자체 클러스터를 가져오는 것보다 팀이 Kubernetes 클러스터 및 리소스를 공유하는 것이 더 비용 효율적이고 더 안전할 수 있습니다. 그러나 팀이 해당 리소스를 안전하고 안전한 방식으로 공유하지 않거나 해커가 구성을 악용하는 경우 배포에 심각한 손상을 줄 수 있습니다.

네트워크 및 리소스 수준에서 Multi-tenancy 방식과 Namespace 격리를 통해 팀은 Kubernetes 리소스를 안전하게 공유할 수 있습니다. 또한 테넌트 기반으로 애플리케이션을 격리하여 침해의 규모를 크게 줄일 수 있습니다. 이 방법은 특정 팀이 소유한 애플리케이션의 하위 섹션만 손상될 수 있고 다른 기능을 제공하는 시스템은 그대로 유지되기 때문에 복원력을 높이는 데 도움이 됩니다.

NGINX Ingress Controller는 다중 multi-tenancy 모델을 지원하지만 두 가지 기본 패턴이 있습니다. 인프라 서비스 제공자 패턴은 일반적으로 물리적 격리가 있는 여러 NGINX Ingress Controller 배포를 포함하는 반면 엔터프라이즈 패턴은 일반적으로 Namespace 격리와 함께 공유 NGINX Ingress Controller 배포를 사용합니다. 이 섹션에서는 엔터프라이즈 패턴을 심층적으로 탐색합니다.

목차

1. NGINX Ingress Controller를 통한 위임
2. Full Self-Service 구현
3. Restricted Self-Service 구현
  3-1. 제한된 셀프 서비스 모델에서 Kubernetes RBAC 활용
4. 정책 추가

1. NGINX Ingress Controller를 통한 위임

NGINX Ingress Controller는 표준 Kubernetes Ingress 리소스와 사용자 지정 NGINX Ingress 리소스를 모두 지원하므로 보다 정교한 트래픽 관리와 구성 제어 권한을 여러 팀에 위임할 수 있습니다. 사용자 지정 리소스는 VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer 및 Policy입니다.

NGINX Ingress Controller를 통해 클러스터 관리자는 VirtualServer 리소스를 사용하여 외부 트래픽을 Backend 애플리케이션으로 라우팅하는 Ingress 도메인(호스트 이름) 규칙을 프로비저닝하고 VirtualServerRoute 리소스를 사용하여 특정 URL 관리를 애플리케이션 소유자 및 DevOps 팀에 위임합니다.

Kubernetes 클러스터에서 multi-tenancy를 구현할 때 선택할 수 있는 두 가지 모델(full self-service 및 restricted self-service)이 있습니다.

2. Full Self-Service 구현

Full Self-Service 모델에서 관리자는 NGINX Ingress Controller 구성에 대한 일상적인 변경에 관여하지 않습니다. NGINX Ingress Controller 배포를 외부에 노출하는 Kubernetes 서비스만 담당합니다. 그런 다음 개발자는 관리자의 개입 없이 할당된 Namespace 내에서 애플리케이션을 배포합니다. 개발자는 TLS 비밀을 관리하고, 도메인 이름에 대한 로드 밸런싱 구성을 정의하고, VirtualServer 또는 표준 Ingress 리소스를 생성하여 애플리케이션을 노출할 책임이 있습니다.

이 모델을 설명하기 위해 다음 다이어그램과 같이 두 개의 하위 도메인인 a.bookinfo.com과 b.bookinfo.com이 있는 샘플 bookinfo 애플리케이션(원래 Istio에서 생성)을 복제합니다. 관리자가 nginx-ingress 네임스페이스(녹색으로 강조 표시)에 NGINX Ingress Controller를 설치 및 배포하면 DevA(분홍색) 및 DevB(보라색) 팀이 자체 VirtualServer 리소스를 만들고 Namespace(각각 A 및 B) 내에서 격리된 애플리케이션을 배포합니다.

DevA 및 DevB 팀은 외부 연결을 애플리케이션으로 라우팅하도록 도메인에 대한 수신 규칙을 설정합니다.

Team DevA는 다음 VirtualServer 리소스 개체를 적용하여 A 네임스페이스의 a.bookinfo.com 도메인에 대한 애플리케이션을 노출합니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: bookinfo
  namespace: A
spec:
  host: a.bookinfo.com
  upstreams:
  - name: productpageA
    service: productpageA
    port: 9080
  routes:
  - path: /
    action:
      pass: productpageA

마찬가지로 DevB 팀은 다음 VirtualServer 리소스를 적용하여 B 네임스페이스의 b.bookinfo.com 도메인에 대한 애플리케이션을 노출합니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: bookinfo
  namespace: B
spec:
  host: b.bookinfo.com
  upstreams:
  - name: productpageB
    service: productpageB
    port: 9080
  routes:
  - path: /
    action:
      pass: productpageB

3. Restricted Self-Service 구현

restricted self-service 모델에서 관리자는 클러스터에 들어오는 트래픽을 적절한 Namespace로 라우팅하도록 VirtualServer 리소스를 구성하지만 Namespace의 애플리케이션 구성은 담당 개발 팀에 위임합니다. 이러한 각 팀은 VirtualServer 리소스에서 인스턴스화된 애플리케이션 서브라우트에 대해서만 책임을 지며 VirtualServerRoute 리소스를 사용하여 트래픽 규칙을 정의하고 Namepsace 내의 애플리케이션 subroute를 노출합니다.

다이어그램에 표시된 대로 클러스터 관리자는 nginx-ingress 네임스페이스(녹색으로 강조 표시됨)에 NGINX Ingress Controller를 설치 및 배포하고 VirtualServerRoute 리소스 정의를 참조하는 경로 기반 규칙을 설정하는 VirtualServer 리소스를 정의합니다.

이 VirtualServer 리소스 정의는 /productpage-A 및 /productpage-B라는 두 개의 하위 경로에 대한 VirtualServerRoute 리소스 정의를 참조하는 두 개의 경로 기반 규칙을 설정합니다.


apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: example
spec:
  host: bookinfo.example.com
  routes:
  - path: /productpage-A
    route: A/ingress 
  - path: /productpage-B
    route: B/ingress

네임스페이스 A와 B의 앱을 담당하는 개발자 팀은 VirtualServerRoute 리소스를 정의하여 네임스페이스 내의 애플리케이션 하위 경로를 노출합니다. 팀은 네임스페이스로 격리되며 관리자가 프로비저닝한 VirtualServer 리소스에 의해 설정된 애플리케이션 하위 경로 배포로 제한됩니다.

Team DevA(다이어그램에서 분홍색)는 다음 VirtualServerRoute 리소스를 적용하여 /productpage-A에 대해 관리자가 설정한 애플리케이션 하위 경로 규칙을 노출합니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
  name: ingress 
  namespace: A
spec:
  host: bookinfo.example.com
  upstreams:
  - name: productpageA
    service: productpageA-svc
    port: 9080
  subroutes:
  - path: /productpage-A 
    action:
      pass: productpageA

Team DevB(보라색)는 다음 VirtualServerRoute 리소스를 적용하여 /productpage-B에 대해 관리자가 설정한 애플리케이션 하위 경로 규칙을 노출합니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
  name: ingress 
  namespace: B
spec:
  host: bookinfo.example.com
  upstreams:
  - name: productpageB
    service: productpageB-svc
    port: 9080
  subroutes:
  - path: /productpage-B 
    action:
      pass: productpageB

VirtualServer 및 VirtualServerRoute 리소스에서 구성할 수 있는 기능에 대한 자세한 내용은 NGINX Ingress Controller 설명서를 참조하세요.

참고: 병합 가능한 Ingress 유형을 사용하여 네임스페이스 간 라우팅을 구성할 수 있지만 제한된 셀프 서비스 위임 모델에서 이 접근 방식은 VirtualServer 및 VirtualServerRoute 리소스에 비해 세 가지 단점이 있습니다.

  1. 덜 안전합니다.
  2. Kubernetes 배포가 커지고 복잡해짐에 따라 병합 가능한 Ingress 유형은 개발자가 네임스페이스 내 호스트 이름에 대한 Ingress 규칙을 설정하는 것을 막지 못하기 때문에 우발적인 수정이 점점 더 쉬워집니다.
  3. VirtualServer 및 VirtualServerRoute 리소스와 달리 병합 가능한 Ingress 유형은 기본(“마스터”) Ingress 리소스가 “minion” Ingress 리소스의 경로를 제어할 수 있도록 설정하지 않습니다.

3-1. 제한된 셀프 서비스 모델에서 Kubernetes RBAC 활용

Kubernetes RBAC(역할 기반 액세스 제어)를 사용하여 사용자에게 할당된 역할을 기반으로 네임스페이스 및 NGINX Ingress 리소스에 대한 사용자의 액세스를 규제할 수 있습니다.

예를 들어 제한된 셀프 서비스 모델에서는 특별한 권한이 있는 관리자만 VirtualServer 리소스에 안전하게 액세스할 수 있습니다. 이러한 리소스는 Kubernetes 클러스터에 대한 진입점을 정의하기 때문에 오용하면 시스템 전체가 중단될 수 있습니다.

개발자는 VirtualServerRoute 리소스를 사용하여 자신이 소유한 애플리케이션 경로에 대한 수신 규칙을 구성하므로 관리자는 개발자가 해당 리소스만 생성할 수 있도록 RBAC 정책을 설정합니다. 개발자 액세스를 더욱 규제해야 하는 경우 특정 네임스페이스에 대한 권한을 제한할 수도 있습니다.

전체 셀프 서비스 모델에서 개발자는 VirtualServer 리소스에 대한 액세스 권한을 안전하게 부여받을 수 있지만 다시 관리자는 해당 권한을 특정 네임스페이스로 제한할 수 있습니다.

RBAC 권한 부여에 대한 자세한 내용은 Kubernetes 설명서를 참조하세요.

4. 정책 추가

NGINX 정책 리소스는 분산된 팀이 다중 테넌시 배포에서 Kubernetes를 구성할 수 있도록 하는 또 다른 도구입니다. 정책 리소스는 OAuth 및 OIDC(OpenID Connect)를 사용한 인증, 속도 제한, WAF(웹 애플리케이션 방화벽)와 같은 기능을 활성화합니다. 정책 리소스는 VirtualServer 및 VirtualServerRoute 리소스에서 참조되어 Ingress 구성에 적용됩니다.

예를 들어 클러스터에서 ID 관리를 담당하는 팀은 Okta를 OIDC IdP(Identity Provider)로 사용하는 JWT(JSON Web Token) 또는 OIDC 정책을 다음과 같이 정의할 수 있습니다.

kind: Policy
metadata:
  name: okta-oidc-policy
  spec:
    oidc:
      clientID: <client_id>
      clientSecret: okta-oidc-secret
      authEndpoint: https://<your_okta_domain>/oauth2/v1/authorize
      tokenEndpoint: https://<your_okta_domain>/oauth2/v1/token
      jwksURI: https://<your_okta_domain>/oauth2/v1/keys

NetOps 및 DevOps 팀은 이 예에서와 같이 VirtualServer 또는 VirtualServerRoute 리소스를 사용하여 해당 정책을 참조할 수 있습니다.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: bookinfo-vs
spec:
  host: bookinfo.example.com
  tls:
    secret: bookinfo-secret
  upstreams:
  - name: backend
    service: productpage
    port: 9080
  routes:
  - path: /
    policies:
    - name: okta-oidc-policy
    action:
      pass: backend

NGINX 정책, VirtualServer 및 VirtualServerRoute 리소스를 함께 사용하면 관리자가 구성을 다른 팀에 쉽게 위임할 수 있는 분산 구성 아키텍처가 가능합니다. 팀은 네임스페이스 전반에 걸쳐 모듈을 어셈블할 수 있고 안전하고 확장 가능하며 관리 가능한 방식으로 정교한 사용 사례로 NGINX Ingress Controller를 구성할 수 있습니다.