# Kubernetes 정책

> **지원 버전**: Kubernetes 1.35 - 1.37
> **마지막 업데이트**: 2026년 2월 22일

Kubernetes에서 정책은 클러스터와 워크로드의 동작을 제어하고 규제하는 규칙 집합입니다. 정책을 통해 보안, 리소스 사용, 네트워크 통신 등 다양한 측면을 관리할 수 있습니다. 이 장에서는 Kubernetes의 다양한 정책 유형과 이를 구현하는 방법, 그리고 Amazon EKS에서의 정책 관리에 대해 알아보겠습니다.

## 실습 환경 설정

이 문서의 예제를 따라하기 위해서는 다음과 같은 도구와 환경이 필요합니다:

### 필수 도구
- API 서버와 마이너 버전 차이가 1 이내인 kubectl
- 작동하는 Kubernetes 클러스터 (EKS, minikube, kind 등)
- Kyverno CLI (선택 사항)
- OPA Gatekeeper (선택 사항)

### 정책 예제 설정

```bash
# 네임스페이스 생성
kubectl create namespace policy-demo

# 리소스 쿼터 생성
kubectl -n policy-demo apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: demo-quota
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    pods: "10"
EOF

# 네트워크 정책 생성
kubectl -n policy-demo apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# 정책 확인
kubectl -n policy-demo get resourcequota,networkpolicy
```

## Kubernetes 정책 아키텍처

![정책 유형(리소스/보안/네트워크/커스텀)이 구현 메커니즘(ResourceQuota·LimitRange, Pod Security Standards, Admission Controllers, NetworkPolicy, OPA Gatekeeper/Kyverno)으로 이어지고, 각 메커니즘이 클러스터·네임스페이스·Pod 수준에 적용되는 3단 구조를 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-0.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-0.html)

## 정책 유형 비교

| 정책 유형 | 구현 메커니즘 | 적용 수준 | 주요 목적 | Kubernetes 버전 지원 |
|----------|--------------|----------|----------|-------------------|
| **리소스 정책** | ResourceQuota, LimitRange | 네임스페이스 | 리소스 사용 제한 및 관리 | 모든 버전 |
| **보안 정책** | Pod Security Standards, Pod Security Admission (PSP 제거됨) | 포드, 네임스페이스 | 보안 컨텍스트 제한 | PSP 제거: 1.25; PSA Stable: 1.25 |
| **네트워크 정책** | NetworkPolicy | 포드 | 네트워크 트래픽 제어 | 1.8+ |
| **커스텀 정책** | OPA Gatekeeper, Kyverno | 클러스터, 네임스페이스, 포드 | 사용자 정의 정책 적용 | 설치한 엔진의 호환 버전에 따라 다름 |

## 리소스 정책

리소스 정책은 Kubernetes 클러스터 내의 컴퓨팅 리소스(CPU, 메모리 등)와 오브젝트 수(포드, 서비스 등)를 제한하고 관리하는 메커니즘입니다.

### ResourceQuota

ResourceQuota는 네임스페이스 내에서 사용할 수 있는 리소스의 총량을 제한합니다.

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    pods: "10"
    services: "5"
    persistentvolumeclaims: "5"
    secrets: "10"
    configmaps: "10"
```

### LimitRange

LimitRange는 컨테이너 요청·제한의 기본값을 설정하고 컨테이너·파드·PVC의 범위를 검증합니다. Pod·PVC 항목은 요청·제한 기본값을 주입하지 않습니다.

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: limit-mem-cpu-per-container
  namespace: dev
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 256Mi
    max:
      cpu: "1"
      memory: 1Gi
    min:
      cpu: 50m
      memory: 128Mi
    type: Container
```

## 목차
1. [정책 개요](#정책-개요)
2. [리소스 할당 정책](#리소스-할당-정책)
3. [포드 보안 정책](#포드-보안-정책)
4. [네트워크 정책](#네트워크-정책)
5. [리소스 쿼터](#리소스-쿼터)
6. [LimitRange](#limitrange)
7. [정책 엔진](#정책-엔진)
8. [Amazon EKS에서의 정책 관리](#amazon-eks에서의-정책-관리)
9. [정책 모범 사례](#정책-모범-사례)
10. [결론](#결론)

## 정책 개요

Kubernetes 정책은 클러스터 관리자가 클러스터 내의 리소스와 워크로드에 대한 제약 조건을 정의하는 방법을 제공합니다. 정책은 다음과 같은 목적으로 사용됩니다:

1. **보안 강화**: 권한이 없는 작업을 방지하고 보안 모범 사례를 적용
2. **리소스 관리**: 리소스 사용량을 제한하고 공정한 리소스 분배를 보장
3. **규정 준수**: 조직의 정책과 규정을 준수하도록 보장
4. **표준화**: 일관된 구성과 배포 관행을 적용

Kubernetes에서는 다양한 유형의 정책을 구현할 수 있으며, 이는 기본 제공 리소스(예: NetworkPolicy, ResourceQuota, LimitRange)나 타사 정책 엔진(예: OPA Gatekeeper, Kyverno)을 통해 구현할 수 있습니다.

## 리소스 할당 정책

리소스 할당 정책은 포드와 컨테이너가 사용할 수 있는 CPU, 메모리 등의 리소스 양을 제어합니다.

![Pod의 리소스 요청·제한 설정이 QoS를 결정하며, 노드 압력 축출은 QoS만의 고정 순서가 아니라 요청 초과 사용과 Pod 우선순위도 평가함을 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-1.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-1.html)

### 리소스 요청과 제한

포드와 컨테이너에 대한 리소스 요청(requests)과 제한(limits)을 설정하여 리소스 사용량을 관리할 수 있습니다:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: resource-demo-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
```

- **requests**: 스케줄링 예약량과 실행 중 리소스 배분 기준이며 실제 사용량은 더 낮을 수 있음
- **limits**: 실행 중 제약: CPU는 스로틀링하고 메모리 초과는 OOM 종료를 유발할 수 있음

리소스 요청과 제한을 설정하면 다음과 같은 이점이 있습니다:

1. **리소스 보장**: 스케줄러가 요청 용량을 반영하며 가용성을 보장하는 것은 아님
2. **리소스 격리**: 한 포드가 다른 포드의 리소스를 독점하는 것을 방지
3. **효율적인 스케줄링**: 스케줄러가 노드의 리소스 용량을 고려하여 포드를 배치

### QoS(Quality of Service) 클래스

Kubernetes는 포드의 리소스 요청과 제한 설정에 따라 자동으로 QoS 클래스를 할당합니다:

1. **Guaranteed**: 컨테이너 수준 구성에서 모든 컨테이너의 CPU·메모리 요청이 각각 제한과 동일한 경우
2. **Burstable**: 적어도 하나의 컨테이너에 리소스 요청이 설정되어 있지만, Guaranteed 조건을 충족하지 않는 경우
3. **BestEffort**: 어떤 컨테이너에도 리소스 요청과 제한이 설정되어 있지 않은 경우

노드 압력 축출은 요청 초과 사용 여부, 파드 우선순위, 상대적 사용량을 반영합니다. 일반적으로 BestEffort가 Guaranteed보다 불리하지만 QoS만으로 고정 순서를 정하지는 않습니다. 파드 수준 리소스도 QoS에 영향을 주므로 [공식 QoS 기준](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/)을 참고하세요.

## 포드 보안 정책

포드 보안 정책(Pod Security Policy, PSP)은 Kubernetes 1.21 버전부터 사용 중단(deprecated)되었으며, 1.25 버전에서 완전히 제거되었습니다. 대신 포드 보안 표준(Pod Security Standards)과 포드 보안 어드미션(Pod Security Admission)이 도입되었습니다.

![네임스페이스 레이블로 지정된 Pod 보안 표준 수준을 Pod 보안 어드미션이 검증하여 Pod 생성 요청을 허용하거나 거부하는 과정을 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-2.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-2.html)

### 포드 보안 표준(Pod Security Standards)

포드 보안 표준은 세 가지 정책 수준을 정의합니다:

1. **Privileged**: 제한 없음, 모든 권한 허용
2. **Baseline**: 알려진 권한 상승 경로 차단
3. **Restricted**: 강력하게 강화된 보안 정책

### 포드 보안 어드미션(Pod Security Admission)

포드 보안 어드미션은 네임스페이스 레이블을 통해 포드 보안 표준을 적용합니다:

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
```

각 레이블의 의미:
- **enforce**: 위반하는 포드의 생성을 차단
- **audit**: 위반 사항을 감사 로그에 기록
- **warn**: 위반 사항에 대한 경고 메시지 표시

## 네트워크 정책

네트워크 정책(Network Policy)은 포드 간의 통신을 제어하는 방법을 제공합니다. 기본적으로 Kubernetes 클러스터의 모든 포드는 서로 통신할 수 있지만, 네트워크 정책을 사용하면 이를 제한할 수 있습니다.

![api-allow NetworkPolicy가 podSelector, policyTypes, ingress·egress 규칙으로 구성되어 API Pod에 적용되고 프론트엔드에서 오는 인바운드와 데이터베이스로 가는 아웃바운드만 허용하며, 규칙의 from/to에 쓰이는 세 가지 선택자 유형을 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-3.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-3.html)

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
```

위 예시에서:
- `app=api` 레이블이 있는 포드에 대한 네트워크 정책을 정의
- `app=frontend` 레이블이 있는 포드에서 8080 포트로의 인바운드 트래픽만 허용
- `app=database` 레이블이 있는 포드의 5432 포트로의 아웃바운드 트래픽만 허용

네트워크 정책을 사용하려면 클러스터의 네트워크 플러그인이 네트워크 정책을 지원해야 합니다. Calico, Cilium, Antrea 등의 CNI 플러그인은 네트워크 정책을 지원합니다.

namespaceSelector가 없는 podSelector는 정책의 네임스페이스 안에서 선택합니다. 표준 NetworkPolicy는 허용 규칙의 합집합이므로 다른 정책이 더 많은 트래픽을 허용할 수 있고 출발지 egress와 목적지 ingress 양쪽이 허용해야 합니다. 이 예시는 클러스터 DNS로의 TCP/UDP 53을 별도 허용하지 않으면 DNS도 차단합니다.

### 네트워크 정책 유형

1. **인그레스(Ingress) 정책**: 포드로 들어오는 트래픽을 제어
2. **이그레스(Egress) 정책**: 포드에서 나가는 트래픽을 제어
3. **인그레스 및 이그레스 정책**: 양방향 트래픽을 모두 제어

### 네트워크 정책 선택자

네트워크 정책은 다양한 선택자를 통해 트래픽을 필터링할 수 있습니다:

1. **podSelector**: 포드 레이블을 기반으로 선택
2. **namespaceSelector**: 네임스페이스 레이블을 기반으로 선택
3. **ipBlock**: IP CIDR 범위를 기반으로 선택

```yaml
# 여러 선택자를 조합한 예시
ingress:
- from:
  - podSelector:
      matchLabels:
        app: frontend
    namespaceSelector:
      matchLabels:
        env: prod
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 172.17.1.0/24
```

## 리소스 쿼터

리소스 쿼터(ResourceQuota)는 네임스페이스 내에서 사용할 수 있는 리소스의 총량을 제한합니다. 이를 통해 여러 팀이나 프로젝트가 클러스터 리소스를 공유할 때 한 팀이 모든 리소스를 독점하는 것을 방지할 수 있습니다.

![ResourceQuota의 네 가지 쿼터 유형이 네임스페이스에 적용되고, Pod들이 쌓은 리소스 사용량과 새 Pod 요청을 합산해 쿼터 이내면 허용하고 초과하면 거부하는 검증 과정을 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-4.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-4.html)

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: team-a
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
```

위 예시에서:
- `team-a` 네임스페이스는 종료 단계가 아닌 파드를 최대 10개 생성할 수 있음
- 모든 포드의 CPU 요청 합계는 4 코어를 초과할 수 없음
- 모든 포드의 메모리 요청 합계는 8Gi를 초과할 수 없음
- 모든 포드의 CPU 제한 합계는 8 코어를 초과할 수 없음
- 모든 포드의 메모리 제한 합계는 16Gi를 초과할 수 없음

### 오브젝트 수 쿼터

리소스 쿼터는 CPU와 메모리 외에도 네임스페이스 내에서 생성할 수 있는 오브젝트의 수를 제한할 수 있습니다:

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: team-b
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "5"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"
```

### 우선순위 클래스 쿼터

특정 우선순위 클래스의 포드에 대한 쿼터를 설정할 수도 있습니다:

우선순위 클래스별로 별도의 쿼터를 사용하며 `pods.high` 같은 키는 없습니다. 파드 스케줄링 전에 해당 PriorityClass를 생성하세요.

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority-quota
  namespace: team-c
spec:
  hard:
    pods: "5"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["high"]
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: medium-priority-quota
  namespace: team-c
spec:
  hard:
    pods: "3"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["medium"]
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: low-priority-quota
  namespace: team-c
spec:
  hard:
    pods: "2"
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values: ["low"]
```

## LimitRange

LimitRange는 누락된 컨테이너 요청·제한에 기본값을 적용하고 admission에서 최소·최대 값을 검증합니다. 기존 파드의 리소스를 변경하거나 Pod·PVC 항목에 기본값을 넣지는 않습니다.

```yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
  namespace: default
spec:
  limits:
  - default:
      cpu: 1
      memory: 512Mi
    defaultRequest:
      cpu: 500m
      memory: 256Mi
    max:
      cpu: 2
      memory: 1Gi
    min:
      cpu: 100m
      memory: 128Mi
    type: Container
```

위 예시에서:
- **default**: 컨테이너에 명시적인 제한이 없을 때 적용되는 기본 제한
- **defaultRequest**: 컨테이너에 명시적인 요청이 없을 때 적용되는 기본 요청
- **max**: 컨테이너가 설정할 수 있는 최대 제한
- **min**: 컨테이너가 설정할 수 있는 최소 요청

LimitRange는 다음과 같은 리소스 유형에 적용할 수 있습니다:
- Container
- Pod
- PersistentVolumeClaim

## 정책 엔진

Kubernetes 생태계에는 더 복잡하고 유연한 정책을 구현할 수 있는 여러 정책 엔진이 있습니다.

![API 서버가 호출한 어드미션 웹훅이 요청을 OPA Gatekeeper, Kyverno, Kubewarden 세 정책 엔진에 전달하고, 각 엔진이 ConstraintTemplate/Constraint, ClusterPolicy/Policy, ClusterAdmissionPolicy라는 자체 정책 정의 리소스를 사용하며 검증·변경(Kyverno는 생성까지) 정책 유형을 지원하는 구조를 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-5.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-5.html)

### OPA Gatekeeper

OPA(Open Policy Agent) Gatekeeper는 Kubernetes 클러스터에 대한 정책을 정의하고 적용하기 위한 오픈 소스 프로젝트입니다. Gatekeeper는 Kubernetes 어드미션 컨트롤러로 작동하여 API 서버에 전송된 요청을 가로채고 정책을 적용합니다.

Gatekeeper는 다음과 같은 구성 요소로 이루어져 있습니다:

1. **ConstraintTemplate**: 정책의 논리를 정의하는 템플릿
2. **Constraint**: ConstraintTemplate의 인스턴스로, 특정 리소스에 정책을 적용

```yaml
# ConstraintTemplate 예시
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabelkeys
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabelKeys
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabelkeys
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("missing required labels: %v", [missing])
        }
```

```yaml
# Constraint 예시
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabelKeys
metadata:
  name: require-app-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["app", "owner"]
```

### Kyverno

Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML 기반의 정책을 사용하여 Kubernetes 리소스를 검증, 변경, 생성할 수 있습니다. Rego 언어를 배울 필요 없이 Kubernetes 리소스와 유사한 구문으로 정책을 작성할 수 있습니다.

```yaml
# Kyverno 정책 예시
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  rules:
  - name: check-for-labels
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      failureAction: Enforce
      message: "The labels 'app' and 'owner' are required."
      pattern:
        metadata:
          labels:
            app: "?*"
            owner: "?*"
```

Kyverno는 다음과 같은 정책 유형을 지원합니다:

1. **Validate**: 리소스가 특정 조건을 충족하는지 검증
2. **Mutate**: 리소스를 자동으로 수정
3. **Generate**: 리소스가 생성될 때 다른 리소스를 자동으로 생성
4. **Verify Images**: 이미지 서명을 검증
5. **Clean Up**: CleanupPolicy/ClusterCleanupPolicy로 조건에 맞는 리소스를 일정에 따라 삭제하며 소유자 참조 기반 가비지 수집과는 별개

### Kubewarden

Kubewarden은 WebAssembly 기반의 정책 엔진으로, 다양한 프로그래밍 언어로 정책을 작성할 수 있습니다. 정책은 WebAssembly 모듈로 컴파일되어 Kubewarden 정책 서버에서 실행됩니다.

```yaml
# Kubewarden 정책 예시
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: require-labels
spec:
  module: "registry://ghcr.io/kubewarden/policies/safe-labels:<tested-tag>"
  mutating: false
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  settings:
    mandatory_labels:
      - app
      - owner
```

위 리소스보다 정책 엔진·CRD·정책 서버를 먼저 설치하세요. Gatekeeper 예시는 더 풍부한 라이브러리 `K8sRequiredLabels`와 충돌하지 않도록 `K8sRequiredLabelKeys`를 정의합니다. Kubewarden은 실제 배포된 검증 버전·다이제스트의 safe-labels와 `mandatory_labels` 설정을 사용하며 `<tested-tag>`는 자리 표시자입니다.

## Amazon EKS에서의 정책 관리

Amazon EKS에서는 Kubernetes의 기본 정책 메커니즘과 함께 AWS의 다양한 서비스를 활용하여 정책을 관리할 수 있습니다.

![AWS Organizations·Config·Firewall Manager가 EKS 클러스터를 제한·감사·보호하고, IAM과 Security Groups가 Pod에 작용하며, Kubernetes 기본 정책이 클러스터·네임스페이스·Pod에 적용되는 구조를 보여준다.](https://raw.githubusercontent.com/Atom-oh/kubernetes-docs/main/ko/.gitbook/assets/ko-core-07-policies-6.png)

[🔍 인터랙티브 다이어그램 보기](https://www.atomai.click/kubernetes-docs/archmaps/ko-core-07-policies-6.html)

### AWS IAM과의 통합

Amazon EKS는 IAM 역할 및 서비스 계정(IRSA)을 통해 포드에 AWS 서비스에 대한 권한을 부여할 수 있습니다. 이를 통해 최소 권한 원칙을 적용할 수 있습니다.

```bash
# OIDC 제공자 생성
eksctl utils associate-iam-oidc-provider --cluster my-cluster --approve

# IAM 역할 생성 및 서비스 계정 연결
eksctl create iamserviceaccount \
  --name my-service-account \
  --namespace default \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::123456789012:policy/ReadApplicationBucket \
  --approve
```

참조한 고객 관리 정책을 먼저 생성하고 필요한 버킷·접두사 읽기로 제한하세요. 지원 컴퓨팅에서는 EKS Pod Identity도 사용할 수 있습니다. IAM은 AWS API 접근을 제어하며 Kubernetes 리소스 인가와 구분됩니다.

### AWS Security Groups for Pods

Amazon EKS는 포드 수준에서 AWS 보안 그룹을 적용할 수 있는 기능을 제공합니다. 이를 통해 포드 간의 통신을 더 세밀하게 제어할 수 있습니다.

```yaml
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: allow-db-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  securityGroups:
    groupIds:
      - sg-0123456789abcdef0
```

클러스터 VPC의 실제 보안 그룹 ID로 바꾸고 앱·DNS에 필요한 규칙을 설정하세요. 파드 보안 그룹에는 지원되는 VPC CNI 설정·IAM 권한·호환 컴퓨팅이 필요하며 Windows·EKS Auto Mode는 지원하지 않습니다.

### AWS Config 및 AWS Organizations

AWS Config는 리소스 준수 여부를 평가하며 자체적으로 CreateCluster를 거부하지 않습니다. Organizations 서비스 제어 정책(SCP)은 적용되는 멤버 계정·OU에서 필수 요청 태그가 없는 생성을 거부할 수 있습니다:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "eks:CreateCluster",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Environment": "true"
        }
      }
    }
  ]
}
```

### AWS Firewall Manager

Firewall Manager는 WAF, VPC 보안 그룹, Network Firewall, DNS Firewall 등의 AWS 보호 기능을 중앙 관리합니다. Kubernetes NetworkPolicy 객체를 동기화하는 서비스는 아니므로 Kubernetes·GitOps 정책 도구로 별도 관리하세요.

## 정책 모범 사례

Kubernetes 클러스터에서 정책을 효과적으로 관리하기 위한 모범 사례를 소개합니다.

### 정책 설계

1. **최소 권한 원칙**: 필요한 최소한의 권한만 부여하는 정책을 설계합니다.
2. **점진적 적용**: 정책을 한 번에 모두 적용하지 말고, 점진적으로 적용하여 영향을 최소화합니다.
3. **감사 모드**: 정책을 적용하기 전에 감사 모드에서 실행하여 영향을 평가합니다.
4. **명확한 문서화**: 각 정책의 목적과 영향을 명확하게 문서화합니다.

### 리소스 관리

1. **네임스페이스 분리**: 팀이나 프로젝트별로 네임스페이스를 분리하고, 각 네임스페이스에 적절한 리소스 쿼터를 설정합니다.
2. **기본 제한 설정**: LimitRange를 사용하여 모든 컨테이너에 기본 리소스 제한을 설정합니다.
3. **QoS 클래스 고려**: 워크로드의 중요도에 따라 적절한 QoS 클래스를 설정합니다.

### 네트워크 보안

1. **기본 거부 정책**: 기본적으로 모든 트래픽을 거부하고, 필요한 통신만 명시적으로 허용하는 정책을 설정합니다.
2. **세분화된 정책**: 포드 간의 통신을 세밀하게 제어하는 네트워크 정책을 설정합니다.
3. **정기적인 검토**: 네트워크 정책을 정기적으로 검토하고 업데이트합니다.

### 정책 자동화

1. **CI/CD 통합**: 정책 검증을 CI/CD 파이프라인에 통합하여 배포 전에 정책 위반을 감지합니다.
2. **정책 테스트**: 정책을 테스트 환경에서 먼저 테스트하고, 문제가 없을 때 프로덕션 환경에 적용합니다.
3. **정책 버전 관리**: 정책을 코드로 관리하고, 버전 관리 시스템을 사용하여 변경 사항을 추적합니다.

## 결론

Kubernetes 정책은 클러스터와 워크로드의 보안, 리소스 사용, 네트워크 통신 등을 제어하는 강력한 도구입니다. 기본 제공 정책 메커니즘(ResourceQuota, LimitRange, NetworkPolicy 등)과 타사 정책 엔진(OPA Gatekeeper, Kyverno 등)을 조합하여 조직의 요구 사항에 맞는 정책 프레임워크를 구축할 수 있습니다.

Amazon EKS를 사용하는 경우, AWS의 다양한 서비스(IAM, Security Groups, AWS Config, AWS Organizations, AWS Firewall Manager 등)를 활용하여 정책 관리를 더욱 강화할 수 있습니다. 이러한 서비스를 통합하여 클러스터와 워크로드의 보안, 규정 준수, 리소스 관리를 효과적으로 수행할 수 있습니다.

정책은 지속적으로 발전하는 영역이므로, 새로운 위협과 요구 사항에 대응하기 위해 정기적으로 정책을 검토하고 업데이트하는 것이 중요합니다. 또한, 정책을 코드로 관리하고 자동화하여 일관성과 효율성을 높이는 것이 좋습니다.

## 퀴즈

이 장에서 배운 내용을 테스트하려면 [정책 퀴즈](https://www.atomai.click/kubernetes-docs/ko/quizzes/core/07-policies-quiz)를 풀어보세요.

## 참고 자료

- [Kubernetes 공식 문서 - 리소스 쿼터](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
- [Kubernetes 공식 문서 - LimitRange](https://kubernetes.io/docs/concepts/policy/limit-range/)
- [Kubernetes 공식 문서 - 네트워크 정책](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
- [Kubernetes 공식 문서 - 포드 보안 표준](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
- [Kubernetes 공식 문서 - 포드 보안 어드미션](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
- [OPA Gatekeeper 공식 문서](https://open-policy-agent.github.io/gatekeeper/website/docs/)
- [Kyverno 공식 문서](https://kyverno.io/docs/)
- [Kubewarden 공식 문서](https://docs.kubewarden.io/)
- [Amazon EKS 공식 문서 - IAM 역할 및 서비스 계정](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
- [Amazon EKS 공식 문서 - 포드용 보안 그룹](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html)
- [AWS Config 공식 문서](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
- [AWS Organizations 공식 문서](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)
- [AWS Firewall Manager 공식 문서](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)