기본 ServiceAccount에 RoleBinding 연결

기본 계정에 불필요한 권한을 부여하지 말고 용도별 계정을 사용하세요.

설명

Kubernetes의 기본 ServiceAccount는 별도 계정 설정이 없는 파드가 공통으로 사용할 수 있습니다. 이 계정에 RoleBinding이나 ClusterRoleBinding을 연결하면 해당 네임스페이스의 기본 계정을 사용하는 워크로드들이 같은 권한을 갖게 됩니다. 권한이 적용되는 리소스 범위는 바인딩 종류와 범위에 따라 달라집니다.

권한은 필요한 워크로드에만 좁게 부여해야 합니다. 용도가 분명한 ServiceAccount를 만들고 필요한 Role만 연결하세요.

잠재적 영향

  • 신규 파드가 기본 계정을 사용하면서 불필요한 권한도 받게 될 수 있습니다.
  • 여러 워크로드의 권한이 결합되어 오남용의 영향 범위와 감사 부담이 커질 수 있습니다.

해결 방법

  • 기본 ServiceAccount에 부여된 불필요한 RoleBinding과 ClusterRoleBinding을 제거하세요.
  • 용도별 ServiceAccount를 만들고 필요한 권한만 연결하세요. subject의 이름과 네임스페이스를 함께 확인하고 실제 워크로드의 사용 계정도 바꾸세요.

예시

default 네임스페이스의 admin이라는 Role과 kube-system의 대상 ServiceAccount가 별도로 존재한다고 가정합니다. 전용 계정으로 바꾸어도 admin Role 자체의 권한이 줄어들지는 않습니다.

변경 전

hcl
resource "kubernetes_role_binding" "example" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = "admin"
  }

  subject {
    kind      = "ServiceAccount"
    name      = "default"
    namespace = "kube-system"
  }
}

변경 후

hcl
resource "kubernetes_role_binding" "example" {
  metadata {
    name      = "terraform-example"
    namespace = "default"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = "admin"
  }

  subject {
    kind      = "ServiceAccount"
    name      = "service-example"
    namespace = "kube-system"
  }
}

설명:

  • 변경 전: kube-system의 default ServiceAccount에 default 네임스페이스의 Role을 부여합니다.
  • 변경 후: 같은 Role의 대상을 service-example 전용 계정으로 바꿉니다.

참조