설명
서로 다른 용도의 워크로드를 default 네임스페이스에 모으면 운영 책임과 권한 범위를 나누기 어려울 수 있습니다. 서비스, 환경 또는 팀별 네임스페이스로 리소스를 정리하세요.
네임스페이스 이름만으로 보안 격리가 생기지는 않습니다. 실제 경계는 RBAC, NetworkPolicy와 리소스 정책 등으로 구성해야 합니다.
잠재적 영향
- 다른 애플리케이션의 리소스를 실수로 수정하거나 삭제할 수 있습니다.
- 공유 권한과 정책이 필요 이상으로 넓게 적용될 수 있습니다.
해결 방법
- 네임스페이스를 사용하는 리소스에는 의도한 metadata.namespace를 명시하세요. 클러스터 범위 리소스에는 적용되지 않습니다.
- 대상 네임스페이스를 먼저 만들고 최소 권한 RBAC, 필요한 NetworkPolicy와 ResourceQuota를 구성하세요.
- 기존 리소스를 옮길 때는 새 네임스페이스의 리소스 생성, 의존 관계와 데이터 이전을 계획하고 접근을 시험하세요.
예시
필수 spec을 생략한 메타데이터 비교입니다. payments 네임스페이스를 먼저 준비하세요. 기존 kubernetes_cron_job은 구형 API용 이름이며 현재 구성에는 지원되는 kubernetes_cron_job_v1을 사용하세요.
변경 전
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "app"
namespace = "default"
}
}
resource "kubernetes_cron_job" "example" {
metadata {
name = "batch-job"
}
}
변경 후
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "app"
namespace = "payments"
}
}
resource "kubernetes_cron_job" "example" {
metadata {
name = "batch-job"
namespace = "payments"
}
}
설명:
- 변경 전: Pod는 default를 명시하고 CronJob은 네임스페이스를 생략합니다. 생략한 경우의 실제 기본값도 확인해야 합니다.
- 변경 후: 두 리소스에 payments를 명시합니다. 이름 지정과 별개로 권한·네트워크 정책이 필요합니다.