NGINX를 사용하여 Kubernetes에서 다중 테넌시 및 네임스페이스 격리 활성화

[ 편집자 - 이 게시물은 F5 NGINX를 사용하여 Kubernetes 트래픽 관리라는 포괄적인 eBook에서 발췌한 것입니다. 실용 가이드 오늘 무료로 다운로드하세요 .]

조직의 규모가 커짐에 따라 Kubernetes의 개발 및 운영 워크플로는 더 복잡해집니다. 각 팀이 자체 클러스터를 확보하는 것보다, 팀이 Kubernetes 클러스터와 리소스를 공유하는 것이 일반적으로 더 비용 효율적이며 보안도 더 우수할 수 있습니다. 하지만 팀이 안전하고 보안된 방식으로 리소스를 공유하지 않거나 해커가 구성을 악용하는 경우 배포에 심각한 손상이 발생할 수 있습니다.

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

NGINX Ingress Controller는 여러 가지 멀티 테넌시 모델을 지원하지만 두 가지 기본 패턴이 있습니다. 인프라 서비스 제공자 패턴에는 일반적으로 물리적 격리를 통한 여러 NGINX Ingress Controller 배포가 포함되는 반면, 엔터프라이즈 패턴은 일반적으로 네임스페이스 격리를 통한 공유 NGINX Ingress Controller 배포를 사용합니다. 이 섹션에서는 엔터프라이즈 패턴을 심층적으로 살펴봅니다. 여러 NGINX Ingress 컨트롤러를 실행하는 방법에 대한 자세한 내용은 설명서를 참조하세요.

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 리소스를 생성하여 애플리케이션을 노출해야 합니다.

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

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

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

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

제한된 셀프 서비스 구현

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

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

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

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

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

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

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 정책 리소스는 분산 팀이 다중 테넌시 배포에서 Kubernetes를 구성할 수 있도록 하는 또 다른 도구입니다. 정책 리소스를 사용하면 OAuth 및 OpenID Connect (OIDC)를 사용한 인증, 속도 제한, 웹 애플리케이션 방화벽(WAF)과 같은 기능을 사용할 수 있습니다. 정책 리소스는 Ingress 구성에서 적용되기 위해 VirtualServer 및 VirtualServerRoute 리소스에서 참조됩니다.

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

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

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

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

이 게시물은 포괄적인 eBook인 NGINX를 사용한 Kubernetes 트래픽 관리에서 발췌한 것입니다. 실용 가이드 오늘 무료로 다운로드하세요 .

오늘 30일 무료 평가판을 통해 NGINX Plus 기반 NGINX Ingress Controller를 직접 사용해 보시거나, 사용 사례에 대해 논의하기 위해 저희에게 문의하세요 .