정책 티어 시작하기

원문 보기 위키 갱신 2026.10.11

티어(tier)는 정책을 계층으로 묶고 우선순위를 강제하는 Calico의 핵심 개념이에요. 이 문서에서는 티어의 평가 순서, Pass 액션의 동작 방식, 그리고 티어로 워크로드 마이크로세그멘테이션을 지원하는 방법을 배워요. 기본 티어와 kube-admin·kube-baseline 티어가 어떤 역할을 하는지도 함께 이해할 수 있어요.

출처: 문서

본문

매끄러운 네트워크 정책 통합

네트워크 정책은 Kubernetes 네트워크를 보호하는 기본 도구예요. 클러스터에서 원하는 트래픽만 흐르도록 제한할 수 있게 해주죠. Calico는 Kubernetes보다 강력한 정책을 제공하지만, 둘을 매끄럽게 함께 사용할 수도 있어요. Calico는 다음을 지원합니다:

Calico 네트워크 정책 (네임스페이스 단위)
Calico 글로벌 네트워크 정책 (네임스페이스 없음, 글로벌)
Kubernetes 네트워크 정책

티어: 무엇이고 왜 필요할까?

**티어(tier)**는 정책을 그룹으로 묶고, 다른 팀이 우회할 수 없는 높은 우선순위 정책을 강제하기 위한 계층 구조예요. 이 튜토리얼에서 배우겠지만, 티어에는 워크로드 마이크로세그멘테이션을 지원하는 기능이 내장돼 있어요.

모든 Calico 및 Kubernetes 네트워크 정책은 티어 안에 속해요. 팀과 정책 유형별로 그룹을 묶으면 "티어 단위로 생각하기"를 시작할 수 있어요. 예를 들어 다음 세 티어(platform, security, application)를 추천해요.

policy-types

다음으로 티어 안 정책의 우선순위를 정해요(위에서 아래로). 다음 예시에서 platform과 security 티어는 모든 파드에 적용되는 Calico 글로벌 네트워크 정책을 사용하고, 개발자 팀은 Kubernetes 네트워크 정책으로 네임스페이스 안의 파드를 안전하게 관리해요.

policy-tiers

티어 만들기

다음은 security 티어를 만들고 kubectl로 적용하는 YAML 예시예요.

apiVersion: projectcalico.org/v3
kind: Tier
metadata:
  name: security
spec:
  order: 300

kubectl apply -f security.yaml

기본 티어:

기본 티어는 설치 시 만들어지며 order 값이 1,000,000이에요. 이 값은 고정이라 바꿀 수 없어요. 기본 티어의 정책은 가장 마지막에 평가되기를 의도한 값이에요.

기본 티어가 담당하는 것들:

모든 Kubernetes 네트워크 정책을 관리하는 곳
명시적인 티어가 없는 모든 네트워크·글로벌 네트워크 정책이 놓이는 곳
티어 지원이 없는 Project Calico에서 티어를 지원하는 Calico 릴리스로 업그레이드할 때 네트워크·글로벌 네트워크 정책이 놓이는 곳

kube-admin 티어:

이름이 kube-admin인 Tier는 Admin Tier를 가진 모든 Kubernetes ClusterNetworkPolicy 리소스가 속하는 곳이에요. 시작 시 자동으로 만들어지고 order는 1,000, 기본 액션은 Pass예요. 이 값은 고정이라 바꿀 수 없어요.

apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: accept-default
spec:
  tier: Admin
  priority: 100
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: default
  ingress:
  - name: accept-default-ingress
    action: "Accept"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: default

Calico는 spec.tier: Admin이 설정된 Kubernetes ClusterNetworkPolicy 리소스를 kube-admin 티어에서 강제해요.

ClusterNetworkPolicy 리소스 외에도 Calico NetworkPolicy/GlobalNetworkPolicy 리소스를 kube-admin Tier에 추가할 수 있어요. ClusterNetworkPolicy의 priority 필드는 Calico NetworkPolicy/GlobalNetworkPolicy의 order 필드에 매핑되어, 두 종류의 정책을 함께 순서 지정할 수 있어요.

kube-baseline 티어:

이름이 kube-baseline인 Tier는 Baseline 티어를 가진 모든 Kubernetes ClusterNetworkPolicy 리소스가 속하는 곳이에요. 시작 시 자동으로 만들어지고 order는 10,000,000, 기본 액션은 Pass예요. 이 값은 고정이라 바꿀 수 없어요.

apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-all
spec:
  tier: Baseline
  priority: 1
  subject:
    namespaces:
      matchLabels: {}
  ingress:
  - name: deny-all-ingress
    action: "Deny"
    from:
    - namespaces:
        matchLabels: {}

Calico는 위와 같은 spec.tier: Baseline Kubernetes ClusterNetworkPolicy를 kube-baseline 티어에 넣어요.

ClusterNetworkPolicy 리소스 외에도 Calico NetworkPolicy/GlobalNetworkPolicy 리소스를 kube-baseline Tier에 추가할 수 있어요. ClusterNetworkPolicy의 priority 필드는 Calico NetworkPolicy/GlobalNetworkPolicy의 order 필드에 매핑되어, 두 종류의 정책을 함께 순서 지정할 수 있어요.

티어 순서

티어는 order 값 기준으로 정렬되며, 가장 낮은 order(가장 높은 우선순위) 티어부터 시작해요.

정책 처리

정책은 가장 낮은 order(가장 높은 우선순위)부터 가장 높은 order(가장 낮은 우선순위)까지 순차적으로 처리돼요.

티어 정책 전반에서 트래픽 처리 방식을 결정하는 두 가지 메커니즘이 있어요:

레이블과 셀렉터
정책 액션 규칙

각각이 어떤 역할을 하는지 이해하는 게 중요해요.

레이블과 셀렉터

Kubernetes의 네트워크 정책은 IP 주소나 IP 범위 대신 레이블과 셀렉터로 어떤 워크로드가 서로 통신할 수 있는지 판단해요. 워크로드 신원(identity)은 Kubernetes와 Calico 네트워크 정책에서 동일해요. 파드가 동적으로 생겼다 사라져도, 정의한 레이블과 셀렉터 기준으로 네트워크 정책이 적용돼요.

다음 다이어그램은 트래픽 흐름에 영향을 주는 모든 요소의 관계를 보여줘요:

티어는 정책을 묶고 순서를 정해요
정책 액션 규칙은 티어 안팎에서 트래픽을 처리하는 방법을 정의하고, 정책 레이블과 셀렉터는 파드 그룹이 서로, 그리고 다른 네트워크 엔드포인트와 통신할 수 있는 방법을 지정해요
CNI, Calico 컴포넌트, 그리고 하위 데이터 플레인(iptables/eBPF)은 트래픽 라우팅 과정에서 레이블과 셀렉터를 모두 활용해요

tier-funnel

정책 액션 규칙

Calico 네트워크 정책은 액션 규칙으로 트래픽/패킷 처리 방법을 지정해요:

Allow 또는 Deny - 트래픽을 허용하거나 거부하고 패킷을 그에 맞게 처리해요. 이후 규칙은 더 처리하지 않아요.
Pass - 엔드포인트에 적용되는 정책이 있는 다음 티어로 건너뛰고 패킷을 처리해요. 티어가 엔드포인트에 적용되지만 패킷에 대한 액션이 취해지지 않으면 패킷은 드랍돼요.
Log - 로그를 남기고, 평가는 다음 규칙으로 계속 진행돼요

암묵적 기본 거부

다음 다이어그램처럼 각 티어 끝에는 암묵적 기본 거부(implicit default deny)가 있어요. 안전하지 않은 정책을 완화하는 보호 장치예요. 이 보호 장치 때문에 트래픽 평가를 계속 이어가고 싶다면, 티어의 기본 액션을 Pass로 명시적으로 바꾸거나 Pass 액션 규칙을 적용해야 해요. 다음 예시에서 정책의 Pass 액션은 트래픽 평가가 계속되도록 하고 암묵적 기본 거부를 무력화해요.

implicit-deny

높은 우선순위 티어(Platform)에 있는 Dev/Ops 글로벌 네트워크 정책을 볼까요? 이 정책은 셀렉터 env == "stage"에 매칭되는 워크로드의 ingress와 egress 트래픽을 거부해요. 이 정책 이후에도 정책 평가가 계속되도록, ingress와 egress 양쪽에 Pass 액션을 추가했어요.

Pass 액션 규칙 예시

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: devops.stage-env
spec:
  tier: devops
  order: 255
  selector: env == "stage"
  ingress:
    - action: Deny
      source:
        selector: env != "stage"
    - action: Pass
  egress:
    - action: Deny
      destination:
        selector: env != "stage"
    - action: Pass
  types:
    - Ingress
    - Egress

다른 방법은 티어의 기본 액션을 Pass로 바꿔 암묵적 기본 거부를 무력화하는 거예요.

Pass 기본 액션 티어 예시

apiVersion: projectcalico.org/v3
kind: Tier
metadata:
  name: devops
spec:
  order: 300
  defaultAction: Pass

티어 간 정책 엔드포인트 매칭

티어를 만드는 사람이라면, 정책이 티어 전반에서 어떻게 엔드포인트를 선택하는지도 이해해야 해요. 일반 정책 처리(apply-on-forward, pre-DNAT, do-not-track 제외)에서는 티어 안에 엔드포인트에 적용되는 정책이 없으면 해당 티어를 건너뛰고, 티어의 암묵적 deny 동작도 실행하지 않아요.

다음 예시에서 Security 티어의 policy D는 트래픽 평가가 순서대로 다음 티어로 이어지길 원하기 때문에 Pass 액션 규칙을 포함해요. Platform 티어에는 엔드포인트에 매칭되는 셀렉터가 정책에 없어서, 티어 끝의 deny를 포함해 티어 전체가 건너뛰어져요. 평가는 Application 티어로 계속되고, policy J가 엔드포인트에 매칭되는 첫 번째 정책이에요.

endpoint-match

기본 엔드포인트 동작

또한 티어 관리자는 엔드포인트가 known인지 unknown인지, 그리고 엔드포인트 타입에 따른 기본 동작도 이해해야 해요. 다음 표와 같아요:

Known 엔드포인트 - Felix가 관리하는 Calico 리소스
Unknown 엔드포인트 - 우리 데이터 모델의 일부로 인식되지 않는 인터페이스/리소스

엔드포인트 타입	Known 엔드포인트 기본 동작	Unknown 엔드포인트 기본 동작 (데이터 모델 밖)
Workload, Calico	Deny	Deny
Workload, Kubernetes	동일 Kubernetes 네임스페이스에서의 ingress 허용; 모든 egress 허용	Deny
Host	Deny. 단, 자동 host 엔드포인트는 `default-allow`를 받음.	통과(fall through)해 iptables 규칙 사용

티어 정책 베스트 프랙티스

Calico 티어, 정책, Kubernetes 네트워크 정책에 대한 접근을 제어하고 승인하려면 Kubernetes RBAC을 사용해요. 보안 팀은 우선순위가 높은(lower order) 티어를 무단으로 보거나 수정하는 것을 막으면서도, 개발자나 서비스 소유자가 자기 워크로드 관련 세부 정책을 관리하도록 허용할 수 있어요.

권장 사항:

티어 생성 권한은 Admin 사용자만 갖도록 제한하세요. 티어를 만들고 순서를 바꾸면 정책 처리 워크플로에 영향을 줘요
티어와 정책 관리에 대한 전체 CRUD 작업은 선별된 Admin 사용자로 제한하세요
티어를 추가하거나 순서를 바꿀 때마다 정책 처리를 검토하세요

예를 들어 새 티어 앞뒤 정책의 Pass 액션 규칙을 업데이트해야 할 수 있어요. 엔드포인트에 따라 사이에 낀 티어들의 정책 변경이 필요할 수도 있어요.

추가 리소스

RBAC으로 티어와 정책에 세밀한 접근 제어를 설정하는 방법은 티어 정책을 위한 RBAC 구성을 참고하세요.

더 알아보기 (Learn more)

티어를 운영에 도입하기 전에 RBAC 구성 문서로 권한 설계를 먼저 점검해 보세요. Pass 액션과 암묵적 기본 거부의 상호작용은 트래픽이 갑자기 막히는 흔한 원인이니 꼭 짚고 넘어가세요.