설명
각 네임스페이스의 기본 ServiceAccount는 별도 지정이 없는 파드에 할당됩니다. 이 계정에 RoleBinding이나 ClusterRoleBinding을 연결하면 여러 워크로드가 원하지 않는 권한을 함께 사용할 수 있습니다.
권한은 워크로드별 전용 ServiceAccount에만 부여하는 것이 안전합니다. 기본 ServiceAccount는 최소 권한 또는 무권한 상태로 두는 편이 좋습니다.
잠재적 영향
- 여러 파드가 동일한 권한을 예상치 못하게 공유할 수 있습니다.
- 신규 파드도 기본 ServiceAccount를 통해 권한을 상속할 수 있습니다.
- 권한 오남용 발생 시 어떤 워크로드가 문제였는지 추적이 어려워질 수 있습니다.
해결 방법
- 기본 ServiceAccount에 불필요한 RoleBinding을 연결하지 마세요.
- 애플리케이션별 전용 ServiceAccount를 만들고 필요한 권한만 부여하세요.
- RBAC 점검 시
subjects.kind: ServiceAccount이면서subjects.name: default인 대상과 해당 네임스페이스를 확인하세요.
예시
예제는 default 네임스페이스에 pod-reader Role이 존재한다고 가정합니다. ServiceAccount 대상은 kube-system 네임스페이스의 default 계정이므로 바인딩의 네임스페이스와 구분하세요.
변경 전
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: default
namespace: kube-system
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
변경 후
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
설명:
- 변경 전: kube-system의 기본 ServiceAccount에 default 네임스페이스의 역할을 부여해 이 계정을 쓰는 워크로드가 권한을 공유할 수 있습니다.
- 변경 후: 이 바인딩에서 기본 ServiceAccount를 제거합니다. jane의 권한과 다른 바인딩에서 부여한 권한은 유지됩니다.