설명
같은 네임스페이스의 동일한 ServiceAccount를 사용하는 워크로드는 같은 API 신원과 계정에 부여된 권한을 공유합니다. 다만 현재의 파드 바인딩 토큰은 파드별로 발급될 수 있으므로 동일 계정을 쓴다고 토큰 값까지 항상 같은 것은 아닙니다.
업무와 권한 요구가 다른 워크로드는 계정을 분리하는 것이 좋습니다. 같은 애플리케이션의 복제 파드처럼 동일한 권한을 의도적으로 공유하는 구성은 필요에 따라 사용할 수 있습니다.
잠재적 영향
- 한 워크로드에 필요한 과도한 권한이 같은 계정을 쓰는 다른 워크로드에도 적용될 수 있습니다.
- 공유 신원으로 여러 워크로드가 호출하면 감사 기록에서 행위 주체를 구분하기 어려워질 수 있습니다.
해결 방법
- 업무와 권한 요구가 다른 워크로드에는 별도의 ServiceAccount를 사용하세요. 계정별 RoleBinding과 실제 허용 동작을 검토하세요.
- 파드에 사용할 계정을 명시하고 API 토큰이 필요하지 않으면 자동 마운트를 끄세요. 동일 계정의 모든 파드를 고려해 권한 변경과 토큰 사고 대응을 계획하세요.
예시
각 예제에는 파드 하나만 표시되어 있습니다. 첫 계정을 다른 워크로드도 함께 사용하는 상황을 가정한 비교이며, 이 코드만으로 공유 여부를 판단할 수는 없습니다. 계정을 먼저 준비하고 실제 배포에는 유지보수되는 이미지를 사용하세요.
변경 전
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "with-pod-affinity"
}
spec {
container {
name = "with-pod-affinity"
image = "k8s.gcr.io/pause:2.0"
}
service_account_name = "terraform-example"
}
}
resource "kubernetes_service_account" "shared" {
metadata {
name = "terraform-example"
}
}
변경 후
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "with-pod-affinity-2"
}
spec {
container {
name = "with-pod-affinity"
image = "k8s.gcr.io/pause:2.0"
}
service_account_name = "service-name"
}
}
resource "kubernetes_service_account" "dedicated" {
metadata {
name = "service-name"
}
}
설명:
- 변경 전: terraform-example 계정을 사용합니다. 다른 업무가 같은 계정을 사용하는지 실제 구성을 확인해야 합니다.
- 변경 후: service-name 계정을 따로 사용합니다. 해당 계정의 실제 권한도 제한해야 합니다.