Kubernetes에 애플리케이션 서비스 배포, 2부

Kubernetes 애플리케이션 서비스 배포 시리즈의 이전 가이드에서 우리는 애플리케이션 배포, 관리 및 제공 방법을 제어하는 데 DevOps의 영향력이 증가하는 것을 살펴보았습니다. 이것이 NetOps 팀과 충돌을 일으키는 것처럼 보일 수 있지만 기업은 대신 각 팀이 서로 다른 책임, 목표 및 운영 모드를 가지고 있음을 인식해야 합니다. 로드 밸런싱 및 WAF(웹 애플리케이션 방화벽)와 같은 애플리케이션 서비스의 위치를 신중하게 선택하는 것이 일부 경우에 중복되는 경우가 있어 전문화 및 운영 효율성의 핵심입니다.

응용 프로그램 서비스를 찾을 위치를 결정할 때 고려해야 할 두 가지 기본 기준이 있습니다.

1. 배포하려는 서비스가 (a) 응용 프로그램이나 비즈니스 라인에만 해당합니까, 아니면 (b) 모든 응용 프로그램에 대해 일반입니까?]
2. 서비스 구성은 (a) DevOps 또는 DevSecOps 또는 (b) NetOps 또는 SecOps가 소유합니까?

(a) 쪽으로 기울면 서비스를 필요로 하는 애플리케이션 가까이에 서비스를 배포하고 해당 애플리케이션의 운영을 책임지는 DevOps 팀에 제어권을 부여하는 것이 좋습니다.

(b) 쪽으로 기울어지면 일반적으로 전체 플랫폼의 성공적인 운영을 책임지는 NetOps 팀이 관리하는 인프라의 정문에 서비스를 배포하는 것이 가장 좋습니다.

또한 타협이 필요한 경우에 대비하여 기술적 적합성을 고려해야 합니다. DevOps 또는 NetOps 팀이 편안하게 사용할 수 있는 에코시스템 도구를 사용하여 서비스를 배포하고 운영할 수 있습니까? 적절한 도구가 필요한 기능, 구성 인터페이스 및 모니터링 API를 제공합니까?

목차

1. Kubernetes, 추가 선택 사항 도입
2. Front Door에 WAF 배치
3. Ingress Controller에 WAF 배포
4. 서비스별(Per-Service)로 WAF 배포
5. 파드 단위(Per-Pod)로 WAF 배포
  5-1. Service Mesh에 대한 참고 사항
6. 요약(Summary)

1. Kubernetes, 추가 선택 사항 도입

Kubernetes 환경에는 애플리케이션 서비스를 배포할 수 있는 여러 위치가 있습니다.

웹 애플리케이션 방화벽(WAF)을 예로 들어 보겠습니다. WAF 정책은 바람직하지 않은 트래픽을 검사하고 차단하기 위해 고급 보안 조치를 구현하지만 이러한 정책은 종종 오탐 수를 최소화하기 위해 특정 애플리케이션에 대해 미세 조정해야 합니다.

2. Front Door에 WAF 배치

다음 기준에 해당하는 경우 인프라의 front door에서 WAF 및 관련 정책을 배포하는 것을 고려하십시오.

• WAF 정책은 중앙 SecOps 팀에서 만들고 관리합니다.

• WAF는 NetOps 팀이 관리하는 전용 어플라이언스입니다.

• 모든(또는 대부분의) 애플리케이션은 동일한 WAF 정책으로 보호되어야 하며 애플리케이션별 조정은 거의 필요하지 않습니다.

• 보안 및 거버넌스 정책이 충족되고 있음을 명확하게 보여주고 단일 제어 지점을 확보하여 가능한 모든 위반 또는 취약성을 차단할 수 있기를 원합니다.

3. Ingress Controller에 WAF 배포

다음 기준이 true인 경우 Ingress Controller에 WAF 애플리케이션 서비스를 배포하는 것을 고려하십시오.

• WAF 정책의 구현은 DevOps 또는 DevSecOps 팀의 지시에 따릅니다.

• WAF 정책을 개별 애플리케이션에 위임하는 대신 인프라 계층에서 중앙 집중화하려고 합니다.

• Kubernetes API를 광범위하게 사용하여 애플리케이션의 배포 및 운영을 관리합니다.

이 접근 방식은 여전히 중앙 SecOps 팀이 WAF 정책을 정의할 수 있도록 합니다. 그들은 Kubernetes로 쉽게 가져올 수 있는 방식으로 정책을 정의할 수 있으며, Ingress Controller를 담당하는 DevOps 팀은 WAF 정책을 특정 애플리케이션에 할당할 수 있습니다.

NGINX Plus Ingress Controller 릴리스 1.8.0부터 NGINX App Protect WAF 모듈을 Ingress Controller에 직접 배포할 수 있습니다. 모든 WAF 구성은 Kubernetes API를 통해 구성된 Ingress 리소스를 사용하여 관리됩니다.

4. 서비스별(Per-Service)로 WAF 배포

또한 Kubernetes 내에서 WAF 보호가 필요한 하나 이상의 특정 서비스 앞에 WAF를 프록시 계층으로 배포할 수 있습니다. 분명히, 이를 위해서는 WAF에 컨테이너 내에서 쉽고 효율적으로 배포할 수 있는 소프트웨어 폼 팩터가 있어야 합니다.

다음 기준에 해당하는 경우 WAF를 서비스별(per-service) 프록시로 배포하는 것이 좋습니다.

• WAF 정책은 DevSecOps 팀의 지시 하에 있으며 소수의 서비스에만 적용됩니다.

• 정책 업데이트는 적절한 컨테이너 인식 API 또는 WAF 프록시 배포를 업데이트하여 관리할 수 있습니다.

• WAF는 Kubernetes 환경에서 적절하게 작동합니다.

예를 들어, App Protect가 포함된 NGINX Plus는 이러한 방식으로 쉽게 배포할 수 있습니다. 다음 작업을 수행하여 보호된 서비스와 이를 호출하는 클라이언트 모두에게 배포를 보이지 않게 할 수 있습니다.

• (예를 들어) WEB-SVC에서 WEB-SVC-INTERNAL로 보호할 서비스의 이름을 바꿉니다.

• WEB-SVC라는 새 Kubernetes 서비스에 WAF 프록시 배포

• WEB-SVC-INTERNAL로 요청을 전달하도록 WAF 프록시 구성

• 선택적으로 Kubernetes 네트워크 정책을 사용하여 WAF 프록시만 WEB-SVC-INTERNAL과 통신할 수 있다고 규정하는 규칙을 시행합니다.

5. 파드 단위(Per-Pod)로 WAF 배포

마지막으로, 파드(Pod)에서 실행되는 애플리케이션에 대한 Ingress 프록시 역할을 하는 파드(Pod)에 WAF를 배포할 수도 있습니다. 이 경우 WAF는 효과적으로 애플리케이션의 일부가 됩니다.

다음 기준에 해당하는 경우 이러한 방식으로 WAF를 배포하는 것이 좋습니다.

• WAF 정책은 애플리케이션에 따라 다릅니다.

• 예를 들어 애플리케이션이 개발 파이프라인의 모든 지점에서 WAF 정책과 함께 배포되도록 정책과 애플리케이션을 밀접하게 바인딩하려고 합니다.

• 애플리케이션이 다른 클러스터에 자주 재배포될 수 있으며 WAF 서비스와 올바른 구성으로 각 클러스터를 ‘prime’하고 싶지 않을 수 있습니다.

이 접근 방식은 특정 보안 정책이 필요한 레거시 애플리케이션이 있고 해당 애플리케이션을 컨테이너 폼 팩터에 패키징하여 배포 및 확장을 더 쉽게 만들고자 할 때 특히 적합합니다.

5-1. Service Mesh에 대한 참고 사항

Pod별 프록시 모델은 Istio, Aspen Mesh, Linkerd, NGINX Mesh 등과 같은 서비스 메시로 대중화된 사이드카(Sidecar) 프록시와 다릅니다.

	파드 단위(Per-Pod) 프록시	사이드카(Sidecar) 프록시
Injected into Pod	빌드 시	배포 시(자동 주입)
Traffic Coverage	Ingress only	Ingress와 egress
Configuration Owner	앱 개발자	DevOps 또는 mesh owner
Features	매우 유능하다	일반적으로 가볍고 단순함
Deployment	그것을 필요로 하는 Pod에 추가됨	메시 인프라를 통해 모든 곳에 배포

WAF를 사용하여 east-west 트래픽을 검사하고 보호해야 할 필요성은 일반적으로 낮고 현재 Service Mesh구현이 없기 때문에 선택한 사이드카(Sidecar) 프록시 내에서 전체 WAF를 쉽게 구성할 수 있습니다. Ingress Controller는 강력한 보안 경계를 제공하며 신뢰할 수 없는 외부 클라이언트(north-south 트래픽)의 Ingress 트래픽을 보호하는 가장 효과적인 장소입니다.

6. 요약(Summary)

WAF와 같은 애플리케이션 서비스를 배포할 위치에 대한 선택의 폭이 넓어지면 Kubernetes 플랫폼의 운영 효율성을 극대화할 수 있는 기회가 더 많아집니다.

	앞문 (Front Door)	Ingress Controller	서비스 단위(Per-Service) 프록시	포드 단위(Per-Pod) 프록시
유효성 (Availability)	NGINX App Protect 또는 기타 WAF 솔루션	NGINX Plus Ingress Controller 1.8.0	NGINX App Protect 또는 유사한 소프트웨어 WAF	NGINX App Protect 또는 유사한 소프트웨어 WAF
Audience	SecOps	SecOps/DevSecOps	DevSecOps	App owner
Scope	Global	Per service/URI	Per service	Per endpoint
비용/효율 (Cost/Efficiency)	좋음/우수(ADC와 같은 다른 서비스와의 통합)	우수(Ingress Controller와 통합)	좋은	낮음(Pod당 전용 WAF)
Configuration	nginx.conf	Kubernetes API	nginx.conf	nginx.conf