설명
Kubernetes에서는 네임스페이스가 운영과 권한 관리의 기본 단위입니다. 서로 다른 팀, 서비스, 환경의 리소스를 같은 네임스페이스에 섞어 두면 누가 무엇을 관리하는지, 어떤 권한을 어디까지 줘야 하는지 불명확해질 수 있습니다.
같은 네임스페이스를 사용하는 것 자체가 취약점은 아닙니다. 분리가 필요한지는 운영 목적에 따라 정하고, 이름을 나누는 것만으로 네트워크나 강한 보안 격리가 이루어지지는 않는다는 점을 고려해야 합니다.
잠재적 영향
- 팀이나 서비스의 관리 책임과 권한 범위가 불명확해질 수 있습니다.
- 문제 발생 시 영향 범위 파악과 운영 정책 적용이 복잡해질 수 있습니다.
해결 방법
- 서비스, 팀과 환경별로 관리 경계를 분리할 필요가 있는지 검토하세요. 권한과 운영 책임이 다른 워크로드는 적절한 네임스페이스로 구분하세요.
- 네임스페이스별 RBAC, ResourceQuota와 지원되는 NetworkPolicy를 함께 구성하세요. 이동하는 워크로드의 Secret, Service 참조와 연결 경로도 확인하세요.
예시
example 이미지와 네임스페이스는 배치 구조를 나타내는 예시입니다. 실제 이미지를 지정하고 대상 네임스페이스와 권한·네트워크 정책을 별도로 준비해야 합니다.
변경 전
yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: shared-all
spec:
containers:
- name: app
image: example/frontend:v1
---
apiVersion: v1
kind: Pod
metadata:
name: billing
namespace: shared-all
spec:
containers:
- name: app
image: example/billing:v1
두 워크로드를 shared-all에 둡니다. 공동 관리가 의도된 경우에는 유효할 수 있으며, 실제 권한 범위를 검토해야 합니다.
변경 후
yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: frontend-team
spec:
containers:
- name: app
image: example/frontend:v1
---
apiVersion: v1
kind: Pod
metadata:
name: billing
namespace: billing-team
spec:
containers:
- name: app
image: example/billing:v1
팀별 네임스페이스로 나눕니다. 이름 분리만으로 접근이 차단되지는 않으므로 실제 정책을 적용해야 합니다.