728x90
반응형
이번 글에서는 K8s 내부에 제로 트러스트(Zero Trust) 보안 모델을 구축하기 위한 Network Policy와 RBAC을 다룹니다.
1. 기본값은 "모두 허용": K8s 네트워크의 위험한 출발점
K8s의 기본 네트워크 설정은 모든 Pod 간 통신을 허용합니다. 같은 클러스터에 있는 프론트엔드 Pod, 백엔드 Pod, 데이터베이스 Pod가 서로 아무런 제약 없이 접근할 수 있습니다. 이는 개발 초기에는 편리하지만, 프로덕션 환경에서는 치명적인 보안 취약점입니다.
- 프론트엔드 Pod가 해킹당하면 DB Pod에 직접 접근 가능
- 관련 없는 네임스페이스의 Pod끼리도 자유롭게 통신
2. Network Policy: Pod 간 방화벽
Network Policy는 K8s에서 Pod 간의 트래픽을 제어하는 방화벽 규칙입니다.
# DB Pod는 backend 라벨이 붙은 Pod의 5432 포트 접근만 허용
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-allow-backend-only
namespace: production
spec:
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: backend
ports:
- protocol: TCP
port: 5432핵심 규칙
- Default Deny: Network Policy가 하나라도 적용되면, 해당 Pod는 명시적으로 허용된 트래픽만 받습니다.
- 라벨 기반 선택: IP가 아닌 Pod의 라벨(Label)로 대상을 지정하므로, Pod가 재생성되어 IP가 바뀌어도 정책이 유지됩니다.
- 네임스페이스 격리:
namespaceSelector를 통해 다른 네임스페이스에서의 접근을 완전히 차단할 수 있습니다.
3. RBAC: "누가 K8s API를 호출할 수 있는가"
Network Policy가 Pod 간의 네트워크 통신을 제어한다면, RBAC(Role-Based Access Control)는 K8s API 서버에 대한 접근 권한을 제어합니다. "이 개발자는 Pod를 조회할 수 있지만 삭제는 못 한다", "이 CI/CD 서비스 계정은 Deployment만 업데이트할 수 있다" 같은 규칙을 설정합니다.
RBAC의 4가지 핵심 오브젝트:
| 오브젝트 | 범위 | 역할 |
| Role | 네임스페이스 | 특정 네임스페이스 내 권한 정의 |
| ClusterRole | 클러스터 전체 | 클러스터 전역 권한 정의 |
| RoleBinding | 네임스페이스 | 사용자/그룹에 Role을 연결 |
| ClusterRoleBinding | 클러스터 전체 | 사용자/그룹에 ClusterRole을 연결 |
# 백엔드 개발자에게 production 네임스페이스의 Pod 조회 권한만 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"] # 조회만 가능, 삭제/수정 불가
4. 요약: 제로 트러스트 보안 체크리스트
| 계층 | 도구 | 원칙 |
| 네트워크 | Network Policy | 명시적으로 허용하지 않은 Pod 간 통신은 모두 차단 |
| API 접근 | RBAC | 최소 권한 원칙(Least Privilege) — 필요한 권한만 부여 |
| 데이터 전송 | Cilium WireGuard | Pod 간 통신 자동 암호화 |
제로 트러스트의 핵심은 "클러스터 내부라고 해서 신뢰하지 않는다"입니다. Network Policy로 Pod 간 통신을 최소화하고, RBAC으로 API 접근을 제한하는 것이 클라우드 네이티브 보안의 기본입니다.
728x90
반응형