제로 트러스트 네트워크 모델 도입하기

원문 보기 위키 갱신 2026.10.11

제로 트러스트 네트워크 모델 도입하기 (Adopt a zero trust network model for security)

이 문서는 Calico 오픈 소스로 Kubernetes 워크로드와 호스트에 제로 트러스트(zero trust) 네트워크 모델을 도입하는 방법을 설명해 드릴게요. 클라우드 네이티브 환경에서 네트워크 접근을 통제하기 위한 다섯 가지 요구 사항부터, Calico와 Istio가 이를 어떻게 구현하는지, 그리고 실제 정책 작성·운영 방법까지 차근차근 살펴볼게요.

출처: 문서

본문

큰 그림 (Big picture)

제로 트러스트 네트워크 모델을 도입하는 것은 클라우드 네이티브 전략에서 워크로드와 호스트를 보호하기 위한 모범 사례예요.

가치 (Value)

제로 트러스트 네트워크는 공격자가 애플리케이션이나 인프라를 침해하는 데 성공하더라도 여전히 탄력적으로 동작해요. 공격자가 측면 이동(lateral movement)을 하기 어렵게 만들고, 정찰(reconnaissance) 활동을 더 쉽게 발견할 수 있게 해 줘요.

이 하우투(How-To)에서 소개하는 변경 관리(change control) 모델을 받아들이는 조직은 애플리케이션 혁신에 부담을 주지 않으면서도 네트워크를 촘촘하게 보호할 수 있어요. 보안 팀은 장애물이 아니라 비즈니스 가치를 만들어 내는 조력자가 될 수 있어요.

개념 (Concepts)

네트워크는 언제나 적대적이다 (The network is always hostile)

**제로 트러스트 네트워킹(Zero Trust Networking)**은 네트워크를 항상 적대적인 것으로 가정한다는 원칙으로 묶인 네트워크 보안 접근 방식이에요. 이는 세계를 신뢰할 수 있는 세그먼트와 신뢰할 수 없는 세그먼트로 나누는 데 초점을 맞추는 경계(perimeter) 방식이나 "세그멘테이션(segmentation)" 방식과 정면으로 대비되는 개념이에요.

왜 네트워크를 적대적인 것으로 가정할까요? 많은 공격 시나리오에서 실제로 그렇기 때문이에요.

공격자는 네트워크 인프라의 "신뢰할 수 있는" 부분, 즉 라우터, 스위치, 링크 등을 침해할 수 있어요.
고의든 실수든 잘못된 설정이 민감한 트래픽을 공용 인터넷처럼 신뢰할 수 없는 네트워크로 라우팅할 수 있어요.
"신뢰할 수 있는" 네트워크의 다른 엔드포인트도 침해되었을 수 있어요. 여러분의 애플리케이션은 수천 대의 다른 서버, 수만 개의 다른 컨테이너, 수천 대의 개인 노트북과 휴대폰과 네트워크를 공유할 수 있어요.

대규모 침해 사고는 보통 컴포넌트 하나 정도의 사소한 침해로 시작하지만, 공격자는 이후 네트워크를 이용해 고가치 표적, 즉 회사나 고객의 데이터를 향해 측면으로 이동해요. 존(zone) 또는 경계(perimeter) 모델에서는 공격자가 엔드포인트 하나를 침해하면 경계나 존 내부를 자유롭게 움직일 수 있어요. 제로 트러스트 네트워크는 모든 네트워크 연결에 강력한 암호학적 인증과 접근 제어를 강제하기 때문에 이런 위협에 탄력적이에요.

제로 트러스트 네트워크의 요구 사항 (Requirements of a Zero Trust Network)

제로 트러스트 네트워크는 다음과 같은 특정 요구 사항을 갖춘 네트워크 접근 제어에 의존해요:

요구 사항 1: 모든 네트워크 연결이 강제(enforcement) 대상이어야 해요. (존 경계를 넘는 연결만이 아니라요.)

요구 사항 2: 원격 엔드포인트의 신원 확인은 강력한 암호학적 신원 증명을 포함한 여러 기준에 근거해야 해요. 특히 IP 주소와 포트 같은 네트워크 수준 식별자는 적대적인 네트워크가 스푸핑(spoofing)할 수 있기 때문에 그것만으로는 충분하지 않아요.

요구 사항 3: 예상되고 허용된 모든 네트워크 흐름은 명시적으로 허용되어야 해요. 명시적으로 허용되지 않은 연결은 거부돼요.

요구 사항 4: 침해된 워크로드는 정책 강제를 우회할 수 없어야 해요.

요구 사항 5: 많은 제로 트러스트 네트워크는 네트워크 트래픽을 스누핑(snooping)하며 민감한 데이터를 훔쳐 보는 적대적 개체에게 정보가 노출되지 않도록 트래픽 암호화에도 의존해요. 네트워크에서 개인 데이터를 주고받지 않는다면 이것은 절대적인 요구 사항은 아니지만, 제로 트러스트 네트워크의 기준에 맞으려면 암호화가 필요한 이상 모든 네트워크 연결에 사용되어야 해요. 제로 트러스트 네트워크는 신뢰할 수 있는 링크·경로와 신뢰할 수 없는 링크·경로를 구분하지 않아요. 또한 데이터 프라이버시를 위해 암호화를 사용하지 않는 경우에도 신원 확인을 위해 암호학적 진위 증명은 여전히 사용된다는 점에 유의하세요.

Calico와 Istio가 제로 트러스트 네트워크 요구 사항을 구현하는 방법 (How Calico and Istio implement Zero Trust Network requirements)

Calico는 Istio 서비스 메시와 협력해서 Kubernetes 클러스터에 제로 트러스트 네트워크를 구축하는 데 필요한 모든 것을 구현해요.

다중 강제 지점 (Multiple enforcement points)

Istio와 함께 운영할 때 워크로드로 들어오는 요청은 두 개의 서로 다른 강제 지점을 거쳐요:

호스트 리눅스 커널. Calico 정책은 iptables를 사용해 리눅스 커널의 L3-L4에서 강제돼요.
Envoy 프록시. Calico 정책은 Envoy 프록시의 L3-7에서, 암호학적으로 인증된 요청에 대해 강제돼요. Dikastes라는 가벼운 정책 결정 사이드카가 이 강제를 돕기 위해 Envoy를 보조해요.

이러한 다중 강제 지점은 여러 기준에 근거해 원격 엔드포인트의 신원을 확인해요 (요구 사항 2). 호스트 리눅스 커널 강제는 워크로드 파드가 침해되고 Envoy 프록시가 우회되더라도 여러분의 워크로드를 보호해요 (요구 사항 4).

Calico 정책 저장소 (Calico policy store)

Calico 데이터 저장소의 정책은 허용된 흐름의 허용 목록(allow-list)을 인코딩해요 (요구 사항 3).

Calico 네트워크 정책은 다양한 보안 패러다임에 맞출 수 있도록 유연하게 설계되었기 때문에, 예를 들어 제로 트러스트 네트워크 스타일의 허용 목록과 존(zone) 같은 레거시 패러다임을 모두 표현할 수 있어요. 여러 정책 문서를 조합하면 이 두 접근 방식을 유지보수 꼬임 없이 겹겹이 쌓을 수도 있어요.

이 문서의 하우투(How To) 섹션에서는 특히 제로 트러스트 네트워크 스타일로 정책을 작성하는 방법을 설명해요. 개념적으로는 모든 네트워크 흐름을 기본적으로 거부하는 것에서 시작한 다음, 애플리케이션을 구성하는 특정 예상 흐름을 허용하는 규칙을 추가하게 돼요. 작업을 마치면 정당한 애플리케이션 흐름만 허용되고 나머지는 모두 거부돼요.

Calico 컨트롤 플레인 (Calico control plane)

Calico 컨트롤 플레인은 Calico 데이터 저장소의 모든 정책 정보를 각 강제 지점으로 배포하는 일을 담당해서, 모든 네트워크 연결이 강제 대상이 되도록 보장해요 (요구 사항 4). 컨트롤 플레인은 고수준 선언적 정책을, 애플리케이션이 수요에 맞춰 확장·축소하고 개발자가 수정할 때마다 바뀌는 상세한 강제 속성으로 변환해요.

Istio Citadel 신원 시스템 (Istio Citadel Identity System)

Calico와 Istio에서 워크로드 신원은 Kubernetes 서비스 어카운트(Service Account)에 기반해요. Citadel이라 불리는 Istio 컴포넌트가 각 서비스 어카운트마다 암호화 키를 발급해서 네트워크에서 자신의 신원을 증명하고 (요구 사항 2) 트래픽을 암호화하게 해 줘요 (요구 사항 5). 덕분에 공격자가 라우터나 링크 같은 네트워크 인프라를 침해하더라도 제로 트러스트 네트워크는 탄력적으로 버틸 수 있어요.

방법 (How to)

이 섹션에서는 Calico와 Istio를 사용해 제로 트러스트 네트워크를 구축하는 방법을 설명해요. 플랫폼·보안 엔지니어 관점에서 작성되었지만, 과정을 이해하고 싶은 개별 개발자에게도 유용할 거예요.

제로 트러스트 네트워크를 만들고 유지하는 일은 애플리케이션 전달 조직 전체의 임무예요. 즉, 네트워크로 연결된 애플리케이션을 최종 사용자에게 전달하는 데 관여하는 모두의 일이에요. 여기에는 다음이 포함돼요:

개발자, DevOps, 운영자(Operators)
플랫폼 엔지니어
네트워크 엔지니어
보안 엔지니어와 보안 실무자

특히 "개발자는 애플리케이션을 만들고, 보안 방법은 다른 사람들에게 맡긴다"는 관점은 제로 트러스트 네트워크 전략과 양립할 수 없어요. 제로 트러스트 네트워크가 올바르게 동작하려면 예상 흐름에 대한 상세한 정보, 즉 개발자만이 가장 잘 알 수 있는 정보가 설정에 반영되어야 해요.

높은 수준에서 보면, 제로 트러스트 네트워크를 구축하기 위해 다음 단계를 수행하게 돼요:

Calico를 설치해요.
Istio를 설치하고 Calico 통합을 활성화해요.
서비스 어카운트를 사용해 워크로드 신원을 확립해요.
각 서비스에 대한 초기 허용 목록 정책을 작성해요.

제로 트러스트 네트워크를 구축한 후에는 이를 유지보수해야 해요.

Calico 설치 (Install Calico)

설치 지침(install instructions)에 따라 클러스터에서 Calico 소프트웨어를 실행하세요.

Istio 설치 및 Calico 통합 활성화 (Install Istio and enable Calico integration)

애플리케이션 계층 정책 활성화(Enable application layer policy) 지침을 따르세요.

지침에는 기능을 빠르게 테스트해 볼 수 있는 Istio "데모" 설치가 포함되어 있어요. 제로 트러스트 네트워크를 지원하는 프로덕션 설치에서는 공식 Istio 설치 지침을 따르는 것이 좋아요. 설치 옵션에서 global.mtls.enabled를 true로 설정해 상호 인증 TLS(mTLS)를 반드시 활성화하세요.

서비스 어카운트로 워크로드 신원 확립하기 (Establish workload identity by using Service Accounts)

최종 목표는 개별적인 예상 네트워크 흐름을 승인하는 접근 제어 정책을 작성하는 거예요. 이 흐름들은 가능한 한 촘촘하게 범위를 한정하고 싶겠죠. Calico 제로 트러스트 네트워크에서 암호학적 신원은 Kubernetes 서비스 어카운트예요. Istio가 암호화 키 관리를 대신 처리해 주기 때문에 각 워크로드가 자신의 서비스 어카운트 신원을 안전한 방식으로 주장할 수 있어요.

제로 트러스트 네트워크 정책을 위한 신원을 할당하는 방식에는 어느 정도 유연성이 있어요. 대부분의 경우에 맞는 적절한 균형점은 애플리케이션의 각 Kubernetes 서비스마다 고유한 신원을 사용하는 거예요 (들어오는 연결을 전혀 받지 않는 워크로드가 있다면 Deployment 기준으로요). 애플리케이션 전체나 네임스페이스에 신원을 할당하는 방식은 아마 너무 성글(coarse) 거예요. 애플리케이션은 보통 접근 요구가 서로 다른 여러 서비스(또는 수십 개의 마이크로서비스)로 이루어져 있거든요.

우연히 같은 것에 접근한다는 걸 알고 있더라도 마이크로서비스마다 고유한 신원을 할당하는 것이 좋아요. 신원이 애플리케이션의 논리적 컴포넌트와 대응하면 정책이 더 읽기 쉬워져요. 같은 권한을 쉽게 부여할 수 있고, 나중에 서로 다른 권한이 필요해지더라도 다루기가 더 쉬워요.

필요한 신원 집합을 정했다면 Kubernetes 서비스 어카운트를 생성하고, 애플리케이션 설정을 수정해서 각 Deployment, ReplicaSet, StatefulSet 등이 올바른 서비스 어카운트를 사용하도록 하세요.

각 서비스에 대한 초기 허용 목록 정책 작성하기 (Write initial allow-list policies for each service)

제로 트러스트 네트워크 구축의 마지막 단계는 네트워크의 각 서비스에 대한 정책을 작성하는 거예요. 애플리케이션 계층 정책 튜토리얼(Application Layer Policy Tutorial)에서 서비스 어카운트 신원에 기반해 트래픽을 허용하는 정책을 설정하는 방법을 개괄적으로 설명해요.

각 서비스에 대해 다음을 수행해요:

그 서비스에 접근해야 하는 다른 신원의 전체 집합을 파악해요.
각 흐름을 허용하는 규칙을 추가해요.

파드가 최소 하나의 정책에 선택되고 나면, 명시적으로 허용되지 않은 트래픽은 모두 거부돼요. 이것이 바로 예상 흐름의 명시적 허용 목록이라는 제로 트러스트 네트워크 패러다임의 구현이에요.

각 서비스에 접근해야 하는 신원의 전체 집합 파악하기 (Determine the full set of identities that should access each service)

서비스에 접근해야 하는 신원 집합을 파악하는 방법은 여러 가지가 있어요. 애플리케이션 개발자와 함께 이 목록을 만들고 올바른지 확인하세요. 한 가지 방법은 애플리케이션 전체의 흐름 다이어그램(flow diagram)을 만드는 거예요. 흐름 다이어그램은 각 신원이 노드이고 각 예상 흐름이 간선인 일종의 그래프예요.

예시 애플리케이션을 살펴볼게요.

zero-trust-app

이 예시에서 최종 사용자의 요청은 모두 api라는 서비스를 거쳐 흐르고, 여기서 백엔드의 다른 서비스를 호출할 수 있어요. 그 서비스들은 다시 다른 서비스를 호출할 수 있어요. 다이어그램의 각 화살표는 예상 흐름을 나타내고, 두 서비스 사이에 연결 화살표가 없다면 두 서비스 사이에 네트워크 통신은 예상되지 않아요. 예를 들어 post 서비스를 호출하는 서비스는 api와 search뿐이에요.

간단한 애플리케이션, 특히 한 팀이 유지보수하는 애플리케이션이라면 개발자가 기억이나 애플리케이션 코드를 훑어보는 것만으로 이 흐름 그래프를 작성할 수 있을 거예요.

기억만으로 작성하기 어렵다면 선택할 수 있는 방법이 몇 가지 있어요.

정책을 활성화한 테스트 환경에서 애플리케이션을 실행해요. a. 서비스 로그를 확인해 어떤 연결이 끊겼는지 살펴봐요. b. 그 흐름을 허용하는 규칙을 추가하고 애플리케이션이 정상 동작할 때까지 반복해요. c. 다음 서비스로 넘어가 같은 작업을 반복해요.
실행 중인 애플리케이션 인스턴스에서 흐름 로그를 수집해요. 이를 위해 Calico Enterprise나 Istio에 포함된 Kiali 대시보드를 사용할 수 있어요. a. 흐름 로그를 처리해 흐름의 집합을 도출해요. b. 기록된 흐름을 검토하고 각 예상 흐름에 대한 규칙을 추가해요.
정책에 Calico Enterprise를 사용하고 로깅 전용(logging-only) 모드로 두어요. a. 이 모드에서는 "거부된(denied)" 연결이 드롭되는 대신 기록돼요. b. "거부된" 로그를 검토하고 각 예상 흐름에 대한 규칙을 추가해요.

실행 중인 애플리케이션 인스턴스에서 흐름을 파악할 때는 추가하는 각 규칙을 애플리케이션 개발자와 함께 검토해서 정당하고 예상된 것인지 반드시 확인하세요. 진행 중인 침해가 정책에서 예상 흐름으로 새겨지는 최악의 상황만은 피해야 하니까요!

각 흐름에 대한 허용 규칙이 포함된 정책 작성하기 (Write policies with allow rules for each flow)

각 서비스의 예상 흐름 집합을 파악했다면, 그 흐름들을 허용 목록에 넣고 나머지는 모두 거부하는 Calico 네트워크 정책을 작성할 준비가 된 거예요.

이전 섹션의 예시 흐름 그래프로 돌아가서 post 서비스의 정책을 작성해 볼게요. 예시를 단순하게 하기 위해 애플리케이션의 모든 서비스가 microblog라는 Kubernetes 네임스페이스에서 실행된다고 가정할게요. 흐름 그래프에서 post 서비스에는 api와 search 서비스가 접근하는 걸 볼 수 있어요.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: post-allow-list
  namespace: microblog
spec:
  selector: svc == 'post'
  types:
    - Ingress
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          names: ['api', 'search']
        namespaceSelector: app == 'microblog'
      protocol: TCP
      destination:
        ports:
          - 8080

이 예시에서 주의할 점들이에요:

네임스페이스 (Namespace)

허용 목록 정책인 Calico NetworkPolicy를 서비스와 같은 네임스페이스(microblog)에 만드세요.
```
metadata:
  name: post-allow-list
  namespace: microblog
```
셀렉터 (Selectors)

selector는 어떤 파드에 정책을 적용할지 제어해요. Kubernetes 서비스를 정의할 때 사용한 셀렉터와 동일해야 해요.
```
spec:
  selector: svc == 'post'
```
이름으로 서비스 어카운트 지정 (Service account by name)

source: 셀렉터에서 api와 search를 이름으로 허용해요. 서비스 어카운트를 이름으로 선택하는 대안은 namespaceSelector를 쓰는 거예요 (다음 예시).
```
source:
  serviceAccounts:
    names: ['api', 'search']
```
namespaceSelector로 서비스 어카운트 지정 (Service account by namespaceSelector)

서비스 어카운트는 이름과 네임스페이스로 고유하게 식별돼요. namespaceSelector를 사용해 허용하려는 서비스 어카운트를 완전한 형태(full-qualified)로 한정하세요. 그러면 같은 이름이 다른 네임스페이스에 존재하더라도 그 어카운트는 서비스 접근 권한을 받지 않아요.
```
source:
  serviceAccounts:
    names: ['api', 'search']
  namespaceSelector: app == 'microblog'
```
규칙 (Rules)

규칙은 가능한 한 촘촘하게 범위를 한정하세요. 이 예시에서는 TCP 포트 8080에서의 연결만 허용해요.
```
destination:
  ports:
    - 8080
```

위 예시는 post 서비스에 접근이 필요한 신원을 이름으로 나열해요. 이런 스타일의 허용 목록은 서비스를 담당하는 개발자가 누가 자신의 서비스에 접근해야 하는지 명확히 알고 있을 때 가장 잘 동작해요.

하지만 어떤 개발 팀은 누가 자신의 서비스에 접근해야 하는지 명확히 모르고, 알 필요도 없어요. 서비스가 아주 범용적이라 조직의 여러 애플리케이션에서 사용될 수도 있어요. 예컨대 로깅(logging) 서비스 같은 경우예요. 서비스에 접근 권한을 주는 서비스 어카운트를 하나하나 명시적으로 나열하는 대신, 서비스 어카운트를 선택하는 라벨 셀렉터를 사용할 수 있어요.

다음 예시에서는 serviceAccount 절을 바꿨어요. 이름 대신 라벨 셀렉터를 사용해요. selector: svc-post == access 라벨이 post 서비스에 대한 접근을 부여해요.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: post-allow-list
  namespace: microblog
spec:
  selector: svc == 'post'
  types:
    - Ingress
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          selector: svc-post == 'access'
        namespaceSelector: app == 'microblog'
      protocol: TCP
      destination:
        ports:
          - 8080

서비스 접근 권한을 나타내는 라벨을 클러스터에서 정의하세요. 그다음 접근이 필요한 각 신원의 서비스 어카운트를 수정해요. 이 예시에서는 api와 search 서비스 어카운트에 svc-post == access 라벨을 추가하게 되겠죠.

서비스 어카운트를 명시적으로 이름으로 나열할지 라벨 셀렉터를 사용할지는 여러분의 선택이고, 서비스마다 다르게 결정해도 돼요. 명시적 이름은 클라이언트 수가 적은 서비스나, 새로운 무언가가 서비스에 접근하는 것을 허용할 때 서비스 소유자가 결정에 참여하기를 원하는 경우에 가장 잘 맞아요. 다른 팀이 서비스 접근 권한을 원하면 서비스 소유자에게 연락해서 권한을 요청하게 되는 거죠. 반대로 라벨 사용은 더 분산된 통제를 원할 때 좋아요. 서비스 소유자가 서비스 접근을 허용하는 라벨을 정의하고, 접근이 필요할 때 다른 개발 팀이 자기 서비스 어카운트에 라벨을 붙이도록 신뢰하는 방식이에요.

제로 트러스트 네트워크 유지보수하기 (Maintain your zero trust network)

허용 목록 정책은 제로 트러스트 네트워크에서 실행되는 애플리케이션의 정확한 예상 흐름에 촘촘하게 맞춰져 있어요. 이 애플리케이션들이 활발히 개발 중이라면 예상 흐름도 바뀌고, 따라서 정책도 바뀌어야 해요. 제로 트러스트 네트워크를 유지보수한다는 것은 다음을 보장하는 변경 관리 정책을 제도화하는 걸 의미해요:

정책이 애플리케이션 변경 사항을 따라 최신 상태로 유지돼요
정책이 예상 흐름에 촘촘하게 맞춰져 있어요
변경이 애플리케이션 개발 속도를 따라잡아요

마지막 항목이 얼마나 중요한지 아무리 강조해도 지나치지 않아요. 변경 관리 프로세스가 변경량을 감당하지 못하거나 새 기능 배포에 너무 많은 지연을 만든다면, 제로 트러스트 네트워크로의 전환은 아마 실패할 거예요. 경영진이 비즈니스 편의를 선택해 보안 우려를 뒤집거나, 새 버전을 더 빨리 출시하는 경쟁자에게 시장 점유율을 내주게 되는 거죠. 반대로 변경 관리 프로세스가 애플리케이션 개발 속도를 따라간다면 혁신 속도를 희생하지 않으면서 보안 가치를 가져다줄 거예요.

대부분의 조직에서 보안 팀의 규모는 애플리케이션 개발·운영 팀에 비해 상대적으로 작은 편이에요. 다행히 대부분의 애플리케이션 변경은 보안 정책 변경을 요구하지 않지만, 큰 애플리케이션 팀을 다루다 보면 작은 비율의 변경이라도 절대적인 수로는 커질 수 있어요. 그래서 보안 팀 구성원이 모든 정책 변경을 직접 수행하는 건 현실적으로 어려운 경우가 많아요. 대기업의 고전적인 불평이 방화벽 규칙 하나 바꾸는 데 몇 주가 걸린다는 건데, 이는 보통 실제 워크플로가 오래 걸려서가 아니라 보안 팀이 큰 백로그에 파묻혀 있기 때문이에요.

따라서 정책 변경의 작성자는 개발자/DevOps가 되도록 권해요 (즉, 작성 주체가 "왼쪽으로 시프트(shift left)"되어야 해요). 이렇게 하면 변경 관리 프로세스가 애플리케이션과 함께 자연스럽게 확장돼요. 애플리케이션 작성자가 정책 변경이 필요한 변경(예: 새 마이크로서비스 추가)을 할 때, 그와 연관된 네트워크 활동을 승인하는 정책 변경도 함께 만들게 되는 거예요.

다음은 단순화한 애플리케이션 전달 파이프라인 흐름이에요.

zero-trust-app

개발자, DevOps, 운영자는 주로 다이어그램 상단의 아티팩트, 즉 소스 코드와 관련 배포 설정을 변경하는 방식으로 애플리케이션을 변경해요. 이 아티팩트는 소스 관리 시스템(예: git)에 두고, 실행 중인 애플리케이션에 대한 변경 통제는 이 소스 저장소에 대한 커밋으로 관리해요. Kubernetes 환경에서 배포 설정은 보통 Kubernetes API에 나타나는 오브젝트, 즉 Service와 Deployment 매니페스트예요.

여러분이 할 일은 NetworkPolicy를 그 배포 설정 아티팩트의 일부로 포함하는 거예요. 어떤 조직은 이 아티팩트가 소스 코드와 같은 저장소에 있고, 어떤 조직은 별도 저장소에 두지만 원칙은 같아요. 정책 변경 통제를 배포 설정에 대한 커밋으로 관리하는 거예요. 이 설정은 전달 파이프라인을 거쳐 최종적으로 실행 중인 Kubernetes 클러스터에 적용돼요.

처음에는 개발자들이 정책을 올바르게 작성하도록 보안 팀의 교육과 지원이 필요할 거예요. 교육받은 많은 개발자는 네트워크 보안을 고민하는 데 익숙하지 않아요. 네트워크 정책으로 표현되는 논리적 통제는 소스 코드에서 가질 수 있는 유연성에 비하면 단순해요. 그래서 여러분이 제공해야 할 주요 지원은 올바른 보안 마인드와 제로 트러스트 네트워크 원칙 쪽이에요. 클러스터에 기본 거부(default deny) 정책을 적용해서 개발자가 자신의 허용 목록 정책을 적용하는 일을 깜빡하지 못하게 할 수도 있어요.

처음에는 모든 보안 정책 변경 요청(git 워크플로에서 말하는 풀 리퀘스트)을 검토하고 싶을 수 있어요. 그렇다면 검토할 시간을 확보해 두고, 제로 트러스트 네트워크 정책을 애플리케이션이나 서비스 하나씩 점진적으로 도입하는 방식을 고려하세요. 개발 팀이 자신감을 얻으면 물러나서 스스로 검토하게 할 수 있어요. 보안 전문가는 장기적으로 품질이 유지되도록 변경 요청이나 정책 전체에 대한 표본 검사(spot check)를 할 수 있어요.

추가 리소스 (Additional resources)

더 알아보기 (Learn more)

호스트 보호와 글로벌 네트워크 정책 문서를 함께 살펴보면 제로 트러스트 정책을 더 넓은 범위로 확장하는 방법을 이해할 수 있어요. 애플리케이션 계층 정책(ISTIO 통합)을 실습하려면 애플리케이션 계층 정책 튜토리얼을 따라 해 보세요.