정책에서 서비스 계정 규칙 사용하기

원문 보기 위키 갱신 2026.10.12

Calico 네트워크 정책에서 Kubernetes 서비스 계정(service account)을 매칭 기준으로 쓸 수 있다는 사실을 알고 계셨나요? 서비스 계정 기반 규칙은 워크로드의 신원을 검증하고, RBAC으로 통제되는 방식으로 정책을 적용할 수 있게 해 줘요. 이 문서는 서비스 계정 이름과 레이블로 ingress 트래픽을 제한하는 방법과, Kubernetes RBAC으로 레이블 할당 자체를 통제하는 방법을 다뤄요.

출처: 문서

본문

큰 그림

Calico 네트워크 정책으로 Kubernetes 서비스 계정에 대한 트래픽을 허용하거나 거부할 수 있어요.

가치

Calico 네트워크 정책을 사용하면 Kubernetes 서비스 계정과 RBAC을 결합해, 클러스터에서 정책이 어떻게 적용되는지 유연하게 통제할 수 있어요. 예를 들어 보안 팀은 다음과 같은 RBAC 권한을 가질 수 있어요:

개발자 팀이 네임스페이스 안에서 사용할 수 있는 서비스 계정을 통제하기
그 서비스 계정들을 위한 고우선순위 네트워크 정책 작성하기 (개발자 팀이 덮어쓸 수 없음)

네트워크 보안 팀은 보안에 대한 완전한 통제권을 유지하면서, 합리적인 경우에만 개발자 작업을 선별적으로 허용할 수 있어요.

Istio 사용 애플리케이션을 Calico 네트워크 정책과 함께 사용하면, 서비스 계정에 연결된 암호화 신원이 (네트워크 신원과 함께) 검증되어 이중 인증(two-factor authentication) 효과를 얻어요.

개념

필요한 최소 권한만 사용하기

서비스 계정에 대한 작업은 RBAC으로 통제되므로, 서비스 계정을 생성·수정·삭제할 수 있는 권한을 신뢰할 수 있는 주체(코드 및/또는 사람)에게만 부여할 수 있어요. 워크로드에서 어떤 작업이든 수행하려면 클라이언트는 Kubernetes API 서버에 인증해야 해요.

pod에 서비스 계정을 명시적으로 지정하지 않으면, 해당 네임스페이스의 기본 ServiceAccount를 사용해요.

네임스페이스의 기본 서비스 계정에 광범위한 권한을 부여하면 안 돼요. 애플리케이션에 Kubernetes API 접근이 필요하다면, 필요한 최소 권한만 갖춘 별도의 서비스 계정을 만드세요.

서비스 계정 레이블

다른 모든 Kubernetes 오브젝트처럼 서비스 계정에도 레이블이 있어요. 레이블을 사용하면 서비스 계정의 '그룹'을 만들 수 있어요. Calico 네트워크 정책에서는 다음 두 가지 방식으로 서비스 계정을 기준으로 워크로드를 선택할 수 있어요:

서비스 계정 이름의 정확한 일치
서비스 계정 레이블 셀렉터 표현식

시작하기 전에...

애플리케이션마다 고유한 Kubernetes 서비스 계정을 구성하세요.

서비스 계정 이름으로 워크로드의 ingress 트래픽 제한하기

다음 예제에서는 서비스 계정이 api-service 또는 user-auth-service와 일치하는 워크로드로부터의 ingress 트래픽을 허용해요.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: demo-calico
  namespace: prod-engineering
spec:
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          names:
            - api-service
            - user-auth-service
  selector: 'app == "db"'

서비스 계정 레이블로 워크로드의 ingress 트래픽 제한하기

다음 예제에서는 서비스 계정이 레이블 셀렉터 app == web-frontend와 일치하는 워크로드로부터의 ingress 트래픽을 허용해요.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-web-frontend
  namespace: prod-engineering
spec:
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          selector: 'app == "web-frontend"'
  selector: 'app == "db"'

Kubernetes RBAC으로 서비스 계정 레이블 할당 통제하기

네트워크 정책은 엔드포인트 자체의 레이블, 엔드포인트의 네임스페이스 레이블, 또는 엔드포인트의 서비스 계정 레이블과 일치하는 셀렉터로 엔드포인트에 적용할 수 있어요. 엔드포인트의 서비스 계정 기반 셀렉터를 사용하면, Kubernetes RBAC으로 누가 서비스 계정에 레이블을 할당할 수 있는지 통제할 수 있어요. 이를 통해 pod를 배포할 수 있는 그룹과 서비스 계정에 레이블을 할당할 수 있는 그룹을 분리할 수 있어요.

다음 예제에서는 intern 서비스 계정을 사용하는 pod는 role: intern 레이블이 붙은 서비스 계정을 사용하는 pod와만 통신할 수 있어요.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: restrict-intern-access
  namespace: prod-engineering
spec:
  serviceAccountSelector: 'role == "intern"'
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          selector: 'role == "intern"'
  egress:
    - action: Allow
      destination:
        serviceAccounts:
          selector: 'role == "intern"'

추가 리소스

더 알아보기 (Learn more)

서비스 계정 기반 정책은 "pod를 띄울 수 있는 사람"과 "정책을 정의할 수 있는 사람"을 분리하는 데 특히 유용해요. 애플리케이션마다 전용 서비스 계정을 두는 습관이 이 패턴의 출발점이에요.