Service Mesh와 NetworkPolicy, L4와 L7 보안을 완벽하게 조합하는 실전 가이드

마이크로서비스 아키텍처(MSA)가 대세가 되면서, 애플리케이션의 복잡성은 기하급수적으로 늘어났습니다. 수십 개의 서비스가 서로 통신하는 환경에서, '누가', '어떤 경로로', '어떤 조건으로' 통신하는지 제어하는 것은 단순한 네트워크 관리를 넘어 생존에 직결되는 문제입니다.

우리는 보통 보안을 위해 방화벽을 떠올립니다. 하지만 쿠버네티스 환경에서 보안은 단일 방화벽만으로는 절대 완성될 수 없습니다. 여기에는 두 가지 강력하지만 역할이 다른 보안 메커니즘이 존재합니다. 바로 NetworkPolicy와 Service Mesh입니다.

이 글은 이 두 기술의 작동 원리 차이점(L4 vs L7)을 명확히 이해하고, 충돌 없이 가장 강력한 보안 아키텍처를 구축하는 최적의 조합 사용법을 실무 관점에서 깊이 있게 다룹니다.

네트워크 레벨의 방화벽: NetworkPolicy (Layer 4)의 역할

NetworkPolicy는 쿠버네티스 네이티브 기능으로, 가장 기본적인 네트워크 접근 제어(Access Control)를 담당합니다. 이는 마치 전통적인 방화벽 규칙과 유사합니다.

작동 원리: NetworkPolicy는 IP 주소와 포트 번호를 기반으로 트래픽의 흐름 자체를 차단하거나 허용합니다. 즉, "이 파드(Pod)는 오직 8080 포트로의 TCP 통신만 허용한다"와 같은 규칙을 정의합니다. 이 계층은 애플리케이션의 내용(Payload)을 전혀 들여다보지 않습니다.

적합한 사용 사례:

• 특정 서비스가 외부 인터넷이나 다른 네임스페이스의 특정 포트 접근 자체를 원천적으로 막아야 할 때.
• 최소한의 네트워크 연결만 허용하는 '최소 권한 원칙'을 가장 낮은 레벨에서 강제하고 싶을 때.

💡 실습 예시: 포트 8080 접근 차단 (L4)

만약 backend-service가 오직 내부의 auth-service의 8080 포트에서만 접근 가능하도록 제한하고 싶다면, NetworkPolicy를 사용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-backend-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: auth-service # 오직 이 레이블을 가진 파드만 허용
    ports:
    - protocol: TCP
      port: 8080 # 8080 포트만 허용

애플리케이션 레벨의 트래픽 제어: Service Mesh (Layer 7)의 힘

Service Mesh는 서비스 간 통신(Service-to-Service Communication)을 위한 인프라 계층을 제공합니다. 대표적인 구현체로는 Istio나 Linkerd가 있으며, 이들은 Sidecar 패턴을 활용하여 각 파드 옆에 프록시(예: Envoy) 컨테이너를 배포합니다.

Sidecar 패턴의 마법: 이 Sidecar 프록시는 모든 인바운드/아웃바운드 트래픽을 가로채서(Intercept) 처리합니다. 이 프록시가 트래픽을 검사할 때, 단순히 포트만 보는 것이 아니라 HTTP 헤더, HTTP 메서드, 요청 경로 등 애플리케이션이 이해하는 수준의 정보를 바탕으로 제어를 수행할 수 있게 됩니다. 이것이 바로 L7 제어의 핵심입니다.

적합한 사용 사례:

• "GET 요청만 허용하고 POST 요청은 무조건 거부해야 한다."
• "특정 헤더(X-Client-ID)가 포함된 요청만 처리해야 한다."
• 서비스 간 통신에 대한 인증(mTLS)을 자동으로 적용하고 싶을 때.

💡 실습 예시: HTTP 메서드 제한 (L7)

user-api 서비스로 들어오는 요청이 오직 GET 메서드만 허용되도록 제한하고 싶다면, Service Mesh의 AuthorizationPolicy를 사용합니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: restrict-get-method
  namespace: default
spec:
  selector:
    matchLabels:
      app: user-api
  action: ALLOW
  rules:
  - http:
      method: GET # 오직 GET 메서드만 허용
      paths: ["/users"]

L4 vs L7: 무엇이 더 강력하며, 어떻게 조합해야 할까?

가장 중요한 질문입니다. "둘 중 무엇이 더 강력한가요?"라는 질문에 대한 답은 "둘 다 필요하며, 역할이 다릅니다." 입니다.

🛡️ 방어 깊이(Defense in Depth)를 위한 최적 조합 전략

보안 아키텍처의 목표는 **'방어 깊이(Defense in Depth)'**를 확보하는 것입니다. 이는 단 하나의 보안 장치에 의존하지 않고, 여러 계층의 방어선을 구축하는 것을 의미합니다.

1. 최외곽 방어선 (L4 - NetworkPolicy):

   • 목표: 외부에서 들어오는 트래픽이나, 완전히 잘못된 포트로의 접근 자체를 원천 차단합니다.
   • 예시: "이 서비스는 8080 포트만 열어줄 것이고, 22 포트는 막는다."

2. 내부 통신 제어 (L7):

   • 예시: "8080 포트로 들어왔더라도, 이 요청이 POST /api/v1/admin 경로로 오면 무조건 거부한다."

결론: L4로 기본적인 접근 통제를 하고, L7에서 비즈니스 로직 수준의 접근 제어까지 수행해야 가장 안전합니다.

🚀 요약 및 실전 적용 가이드

이러한 다층적 방어(Defense in Depth) 전략을 통해, 한 계층이 뚫리더라도 다음 계층의 보안 장치가 막아주는 강력한 시스템을 구축할 수 있습니다.