NGINX를 활용한 Kubernetes의 멀티테넌시 및 네임스페이스 격리 구현

Amir Rawdat솔루션 엔지니어

[편집자– 이 게시물은 종합 전자책 F5 NGINX를 활용한 Kubernetes 트래픽 관리: 실용 가이드에서 발췌한 내용입니다. 지금 무료로 다운로드하세요.]

조직의 규모가 커질수록 Kubernetes의 개발 및 운영 워크플로는 더욱 복잡해집니다. 일반적으로 각 팀이 자체 클러스터를 사용하는 것보다 여러 팀이 Kubernetes 클러스터와 리소스를 공유하는 편이 비용 효율성이 높으며 보안도 강화할 수 있습니다. 하지만 팀이 이러한 리소스를 안전하게 공유하지 않거나 해커가 구성의 취약점을 악용하면 배포 환경에 심각한 피해가 발생할 수 있습니다.

네트워크 및 리소스 수준에서 멀티테넌시를 적용하고 네임스페이스를 격리하면 팀이 Kubernetes 리소스를 안전하게 공유할 수 있습니다. 또한 테넌트별로 애플리케이션을 격리하여 침해 피해 규모를 크게 줄일 수 있습니다. 이 방법을 사용하면 특정 팀이 소유한 애플리케이션의 일부만 침해될 수 있고 다른 기능을 제공하는 시스템은 온전하게 유지되므로 복원력을 높이는 데 도움이 됩니다.

NGINX Ingress Controller는 여러 멀티테넌시 모델을 지원하지만, 주로 두 가지 패턴이 사용됩니다. 인프라 서비스 제공업체 패턴은 일반적으로 물리적으로 격리된 여러 NGINX Ingress Controller 배포를 포함하는 반면, 엔터프라이즈 패턴은 일반적으로 네임스페이스로 격리된 공유 NGINX Ingress Controller 배포를 사용합니다. 이 섹션에서는 엔터프라이즈 패턴을 자세히 살펴봅니다. 여러 NGINX Ingress Controller를 실행하는 방법은 설명서를 참조하세요.

NGINX Ingress Controller를 사용한 위임

NGINX Ingress Controller는 표준 Kubernetes Ingress 리소스와 사용자 지정 NGINX Ingress 리소스를 모두 지원합니다. 이를 통해 더욱 정교하게 트래픽을 관리하고 여러 팀에 구성 제어 권한을 위임할 수 있습니다. 사용자 지정 리소스에는 VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer, 그리고 Policy가 있습니다.

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

Kubernetes 클러스터에서 멀티테넌시를 구현할 때 선택할 수 있는 모델은 두 가지입니다. 완전한 셀프서비스와 제한된 셀프서비스입니다.

완전한 셀프서비스 구현

완전한 셀프서비스 모델에서는 관리자가 NGINX Ingress Controller 구성의 일상적인 변경에 관여하지 않습니다. 관리자는 NGINX Ingress Controller와 배포를 외부에 노출하는 Kubernetes Service를 배포하는 역할만 담당합니다. 이후 개발자는 관리자의 개입 없이 할당된 네임스페이스 내에 애플리케이션을 배포합니다. 개발자는 TLS 시크릿을 관리하고, 도메인 이름에 대한 부하 분산 구성을 정의하며, VirtualServer 또는 표준 Ingress 리소스를 생성하여 애플리케이션을 노출할 책임이 있습니다.

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

DevA 팀과 DevB 팀은 외부 연결을 해당 애플리케이션으로 라우팅하도록 각자의 도메인에 대한 Ingress 규칙을 설정합니다.

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

코드 예제를 로드하는 중…

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

코드 예제를 로드하는 중…

제한된 셀프서비스 구현

제한된 셀프서비스 모델에서 관리자는 클러스터로 유입되는 트래픽을 적절한 네임스페이스로 라우팅하도록 VirtualServer 리소스를 구성하지만, 네임스페이스 내 애플리케이션 구성은 담당 개발 팀에 위임합니다. 각 팀은 VirtualServer 리소스에 인스턴스화된 자체 애플리케이션 하위 경로만 담당하며, VirtualServerRoute 리소스를 사용하여 트래픽 규칙을 정의하고 해당 네임스페이스 내에서 애플리케이션 하위 경로를 노출합니다.

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

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

코드 예제를 로드하는 중…

네임스페이스 A 및 B의 앱을 담당하는 개발자 팀은 각 네임스페이스 내에서 애플리케이션 하위 경로를 노출하도록 VirtualServerRoute 리소스를 정의합니다. 팀은 네임스페이스별로 격리되며, 관리자가 프로비저닝한 VirtualServer 리소스에 설정된 애플리케이션 하위 경로만 배포할 수 있습니다:

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

  코드 예제를 로드하는 중…

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

  코드 예제를 로드하는 중…

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

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

1. 보안성이 떨어집니다.
2. Kubernetes 배포 규모가 커지고 복잡해질수록 의도치 않은 변경이 발생할 가능성이 높아집니다. 병합 가능한 Ingress 유형은 개발자가 자신의 네임스페이스 내 호스트 이름에 대해 Ingress 규칙을 설정하는 것을 막지 않기 때문입니다.
3. VirtualServer 및 VirtualServerRoute 리소스와 달리, 병합 가능한 Ingress 유형에서는 기본(“마스터”) Ingress 리소스가 “미니언” Ingress 리소스의 경로를 제어할 수 없습니다.

제한된 셀프 서비스 모델에서 Kubernetes RBAC 활용

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

예를 들어 제한된 셀프서비스 모델에서는 특별한 권한이 있는 관리자에게만 VirtualServer 리소스에 대한 액세스를 허용해야 안전합니다. 이러한 리소스는 Kubernetes 클러스터의 진입점을 정의하므로 잘못 사용하면 시스템 전체에 장애가 발생할 수 있습니다.

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

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

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

정책 추가

NGINX Policy 리소스는 분산된 팀이 멀티 테넌시 배포 환경에서 Kubernetes를 구성할 수 있도록 지원하는 또 다른 도구입니다. Policy 리소스는 OAuth 및 OpenID Connect(OIDC)를 사용한 인증, 속도 제한, 웹 애플리케이션 방화벽(WAF) 등의 기능을 제공합니다. Policy 리소스가 Ingress 구성에 적용되도록 하려면 VirtualServer 및 VirtualServerRoute 리소스에서 이를 참조해야 합니다.

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

코드 예제를 로드하는 중…

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

코드 예제를 로드하는 중…

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

Policy 리소스에 대한 자세한 내용은 NGINX Ingress Controller 설명서를 참조하세요.

이 게시물은 당사의 종합 전자책 NGINX로 Kubernetes 트래픽 관리하기: 실용 가이드에서 발췌한 내용입니다. 지금 무료로 다운로드하세요.

NGINX Plus 기반 NGINX Ingress Controller를 30일 무료 평가판으로 지금 직접 사용해 보거나, 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Amir Rawdat솔루션 엔지니어

Amir Rawdat의 다른 블로그 게시물