[k8s] 쿠버네티스 RBAC 보안 강화 체크리스트: 최소 권한 원칙 적용 가이드

목차

• 1. 왜 쿠버네티스 RBAC 보안이 먼저냐
• 2. RBAC를 쉽게 말하면: 누가, 어디서, 뭘 하느냐
• 3. 쿠버네티스 보안 체크리스트: 먼저 이것부터 보세요
• 4. 실전 구현: 네임스페이스 단위로 RBAC 최소 권한 적용하기
• 4-1. 네임스페이스와 서비스 계정 만들기
• 4-2. Role 정의
• 4-3. RoleBinding 연결
• 4-4. 적용 명령
• 4-5. 권한 검증
• 5. 실무 체크포인트: ClusterRole은 언제 써야 하나
• 6. ⚠️ 주의사항과 트러블슈팅: 제가 실제로 많이 헷갈렸던 부분
• 문제가 생겼을 때 확인 순서
• 7. 검증과 운영 결과: RBAC 최소 권한이 주는 실제 이점
• 8. 자주 묻는 질문: k8s 권한 관리에서 많이 나오는 질문
• Q1. 읽기 전용 계정인데 왜 로그가 안 보일까요?
• Q2. Role만 쓰면 안 되나요?
• Q3. RBAC 최소 권한은 얼마나 잘게 쪼개야 하나요?
• Q4. Secret 접근은 정말 따로 봐야 하나요?
• 9. 마무리: 쿠버네티스 RBAC 보안은 결국 운영 습관입니다

[Kubernetes] 쿠버네티스 RBAC 보안 강화 체크리스트

쿠버네티스 RBAC 보안은 클러스터 운영에서 생각보다 빨리 발목을 잡는 주제입니다. 처음엔 워크로드만 잘 뜨면 된다고 생각했었는데, 실제 운영에 들어가면 누가 어디까지 볼 수 있고, 무엇을 수정할 수 있는지부터 꼬이더라고요. 저도 홈랩에서 Kubernetes(쿠버네티스, 컨테이너 오케스트레이션 플랫폼) 클러스터를 굴리면서 서비스 계정 하나를 너무 넓게 열어뒀다가, 나중에 권한 정리하느라 삽질 좀 했습니다 ㅎㅎ 그래서 오늘은 쿠버네티스 RBAC 보안을 기준으로, 실무에서 바로 점검할 수 있는 체크리스트 형태로 정리해보겠습니다. 특히 k8s 권한 관리가 막막한 분, RBAC 최소 권한을 어디서부터 적용해야 할지 헷갈리는 분께 실질적인 도움이 될 거라고 생각합니다.

이 글은 특정 벤더 기능이 아니라 Kubernetes 기본 RBAC(Role-Based Access Control, 역할 기반 접근 제어)를 중심으로 설명합니다. 즉, 대부분의 표준 클러스터에서 바로 적용 가능한 실전 내용만 담았습니다.

RBAC의 큰 흐름을 한 장으로 보면, 왜 최소 권한이 중요한지 훨씬 빨리 감이 옵니다.

1. 왜 쿠버네티스 RBAC 보안이 먼저냐

많은 분들이 보안이라고 하면 NetworkPolicy(네트워크폴리시, 네트워크 접근 제어)나 이미지 스캔부터 떠올리시는데요. 근데 여기서 중요한 포인트! 권한이 과하면 그 뒤 보안 장치들이 의미가 많이 줄어듭니다. 읽기 전용이어야 할 계정이 Secret(시크릿, 민감 정보 객체)을 읽을 수 있다거나, 특정 네임스페이스만 다뤄야 하는 자동화 계정이 클러스터 전체를 수정할 수 있다면 문제는 금방 커지더라고요.

제가 직접 해보니 RBAC는 꼭 사고 대응 때문에만 필요한 게 아니었습니다. 운영자끼리 역할을 분리할 때도 좋고, CI/CD 파이프라인이 쓸 계정을 분리할 때도 좋고, 나중에 감사(Audit, 행위 추적)할 때도 훨씬 편해지더라고요. 누가 왜 그 권한을 갖는지 설명할 수 있어야 관리가 됩니다.

2. RBAC를 쉽게 말하면: 누가, 어디서, 뭘 하느냐

쉽게 말해 RBAC는 세 가지를 묶는 구조입니다.

• 누가: User(사용자), Group(그룹), ServiceAccount(서비스어카운트, 파드가 쓰는 계정)
• 어디서: Namespace(네임스페이스, 논리적 격리 단위) 또는 클러스터 전체
• 뭘 하느냐: verbs(동작)와 resources(리소스)

여기서 자주 헷갈리는 게 Role과 ClusterRole 차이입니다. 저도 처음엔 이게 뭔가 싶었는데, 정리하면 꽤 단순합니다.

구성 요소	범위	용도	예시
Role	특정 Namespace	네임스페이스 내부 권한 정의	dev 네임스페이스의 Pod 조회
ClusterRole	클러스터 전체 또는 공통 리소스	광범위 권한 또는 공통 읽기 권한 정의	노드 조회, 전체 네임스페이스 읽기
RoleBinding	특정 Namespace	Role 또는 ClusterRole을 특정 주체에 연결	개발자 그룹에 dev 조회 권한 부여
ClusterRoleBinding	클러스터 전체	ClusterRole을 클러스터 범위로 연결	운영팀에 클러스터 전역 읽기 권한 부여

즉, RBAC 최소 권한의 핵심은 필요한 주체에게 필요한 리소스만, 필요한 동작만 허용하는 겁니다. 말은 쉬운데 실제로는 여기서 많이 넓어지더라고요. 특히 * 와일드카드, 무심코 준 cluster-admin, 그리고 서비스 계정 재사용이 흔한 함정입니다.

3. 쿠버네티스 보안 체크리스트: 먼저 이것부터 보세요

운영 중인 클러스터가 있다면 아래 항목부터 점검해보시면 됩니다. 저는 새 클러스터를 만들 때도 이 리스트부터 잡고 시작합니다.

1. cluster-admin 바인딩 확인: 정말 필요한 주체만 갖고 있는지 봅니다.
2. ServiceAccount 분리: 애플리케이션별, 작업별로 계정을 나눕니다.
3. 와일드카드 금지: resources, verbs에 * 사용을 최대한 피합니다.
4. Secret 접근 최소화: 꼭 필요한 워크로드만 읽게 합니다.
5. Namespace 단위 분리: 팀, 환경, 서비스 기준으로 경계를 명확히 둡니다.
6. 읽기와 쓰기 분리: 조회 전용 계정과 변경 가능 계정을 나눕니다.
7. 권한 검증 자동화: kubectl auth can-i로 배포 전에 확인합니다.
8. 휴면 계정 정리: 더 이상 쓰지 않는 RoleBinding, ClusterRoleBinding 제거합니다.
9. 기본 토큰 사용 점검: default ServiceAccount에 불필요한 권한을 주지 않습니다.
10. 감사 로그 연계 검토: 누가 어떤 API를 호출했는지 추적 가능한 구조를 만듭니다.

혹시 이런 경험 있으신가요? 급해서 일단 권한부터 열고, 나중에 줄이자고 생각했는데 그 나중이 안 오는 경우요. 실제로 써보니까 RBAC는 처음에 30분 더 쓰는 게 나중에 몇 시간을 아껴줍니다.

4. 실전 구현: 네임스페이스 단위로 RBAC 최소 권한 적용하기

이제 예제로 가보겠습니다. 시나리오는 단순합니다. ops-viewer라는 ServiceAccount가 production 네임스페이스 안에서 Pod와 Deployment만 읽을 수 있게 만들겠습니다. 수정, 삭제, Secret 조회는 못 하게 두는 방식입니다. 이런 식으로 시작하면 k8s 권한 관리가 훨씬 명확해집니다.

4-1. 네임스페이스와 서비스 계정 만들기

kubectl create namespace production
kubectl -n production create serviceaccount ops-viewer

여기서 서비스 계정을 애플리케이션용 계정과 섞지 않는 게 중요합니다. 저는 예전에 배치 작업과 운영 조회 계정을 하나로 묶었다가, 생각보다 많은 권한이 전파되더라고요.

4-2. Role 정의

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-deploy-readonly
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]

포인트는 명확합니다. pods, deployments만 읽을 수 있게 열었습니다. 여기서 Secret이나 ConfigMap까지 습관적으로 넣지 않는 게 핵심입니다. 진짜 필요한지부터 따져봐야 합니다.

4-3. RoleBinding 연결

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-deploy-readonly-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: ops-viewer
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-deploy-readonly

이제 이 ServiceAccount는 production 네임스페이스 내부의 조회 권한만 갖습니다. 클러스터 전체 권한이 아니라는 점이 중요합니다. 바로 이 경계 설정이 쿠버네티스 RBAC 보안의 기본입니다.

실전에서는 Role과 Binding 연결 관계를 그림으로 한 번 정리해두면 팀원 온보딩 때 정말 편합니다.

4-4. 적용 명령

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

4-5. 권한 검증

kubectl auth can-i get pods \
  --as=system:serviceaccount:production:ops-viewer \
  -n production

kubectl auth can-i get secrets \
  --as=system:serviceaccount:production:ops-viewer \
  -n production

kubectl auth can-i delete deployments \
  --as=system:serviceaccount:production:ops-viewer \
  -n production

정상이라면 첫 번째는 yes, 나머지는 no에 가깝게 나와야 합니다. 드디어 됐다! 싶은 순간이 여기입니다. RBAC는 적용보다 검증이 더 중요하거든요.

5. 실무 체크포인트: ClusterRole은 언제 써야 하나

모든 걸 Role로만 처리할 수는 없습니다. 예를 들어 여러 네임스페이스에서 공통 조회가 필요하거나, Node(노드), Namespace 같은 클러스터 범위 리소스를 읽어야 하는 경우엔 ClusterRole이 맞습니다. 다만 ClusterRole을 쓸 때도 바인딩 범위를 생각해야 합니다.

예를 들어 ClusterRole 자체는 공통 읽기 정책으로 만들고, 실제 부여는 Namespace별 RoleBinding으로 제한하는 방식도 가능합니다. 이 패턴이 꽤 유용합니다. 권한 정의는 재사용하고, 적용 범위는 좁히는 거죠.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-pods-common
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

이렇게 만들어두고 필요한 네임스페이스에서 RoleBinding으로 참조하면 운영이 조금 더 단정해집니다. 저는 환경이 여러 개일 때 이 방식을 자주 씁니다.

6. ⚠️ 주의사항과 트러블슈팅: 제가 실제로 많이 헷갈렸던 부분

쿠버네티스 보안 체크리스트에서 자주 놓치는 함정을 몇 가지 적어보겠습니다. 저도 처음엔 꽤 많이 틀렸습니다.

• default ServiceAccount 사용: 아무 설정 없이 파드가 default 계정을 쓰는 경우가 많습니다. 이 계정에 권한이 붙어 있으면 의도치 않은 확장이 생깁니다.
• Secret 읽기 권한 과다: Pod 조회만 필요했는데 디버깅 편하다고 Secret 읽기까지 열어두더라고요. 이건 생각보다 위험합니다.
• ClusterRoleBinding 남발: 편해서 전역 바인딩을 쓰다 보면, 나중에 어느 팀이 무엇을 할 수 있는지 안 보입니다.
• verbs 누락 또는 과다: list만 필요한데 create, delete까지 들어가 있는 경우가 있습니다.
• 서브리소스 누락: pods/log 같은 서브리소스 접근이 필요한데 본 리소스만 열어서 안 되는 경우도 많습니다.

예를 들어 로그 조회가 안 될 때는 이런 식으로 서브리소스를 분리해줘야 합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

처음엔 Pod 읽기 권한이 있으면 로그도 되겠지 싶었는데, 여기서 막히더라고요. 이런 디테일이 RBAC에서 은근 많습니다.

문제가 생겼을 때 확인 순서

1. kubectl auth can-i로 해당 주체 기준 권한을 확인합니다.
2. Role/ClusterRole의 resources, verbs, apiGroups가 맞는지 봅니다.
3. RoleBinding이 올바른 네임스페이스에 연결됐는지 확인합니다.
4. 서비스 계정 이름과 네임스페이스가 정확한지 다시 봅니다.
5. 서브리소스가 필요한 작업인지 확인합니다.

권한 검증 흐름을 따로 정리해두면 트러블슈팅 시간이 확실히 줄어듭니다.

7. 검증과 운영 결과: RBAC 최소 권한이 주는 실제 이점

RBAC 최소 권한을 적용하고 나면 체감되는 변화가 분명합니다. 이거 진짜 편하더라고요.

• 장애 대응 시 누가 무엇을 바꿀 수 있는지 명확해집니다.
• 자동화 계정과 사람 계정의 역할이 분리됩니다.
• 실수로 인한 삭제나 수정 범위를 줄일 수 있습니다.
• 감사와 변경 이력 추적이 쉬워집니다.
• 새 팀원에게 권한 구조를 설명하기 쉬워집니다.

검증할 때는 아래 항목을 한 번 더 보시면 좋습니다.

1. 서비스 계정별 허용 동작 목록이 문서화되어 있는가
2. 네임스페이스를 넘는 불필요한 권한이 없는가
3. Secret, Role, RoleBinding 수정 권한이 꼭 필요한 주체에만 있는가
4. 휴면 바인딩이 남아 있지 않은가
5. 정기 점검 시나리오가 있는가

특히 운영 문서에 단순히 YAML만 남기지 말고, 왜 이 권한이 필요한지도 같이 적어두세요. 나중에 본인이 봐도 살짝 감동합니다. 저는 예전 설정 파일만 덩그러니 남겨놨다가, 몇 달 뒤에 제가 만든 정책을 제가 못 읽겠더라고요.

8. 자주 묻는 질문: k8s 권한 관리에서 많이 나오는 질문

Q1. 읽기 전용 계정인데 왜 로그가 안 보일까요?

pods만 열고 pods/log를 빼먹은 경우가 많습니다. 서브리소스 권한을 따로 확인해보세요.

Q2. Role만 쓰면 안 되나요?

네임스페이스 내부만 다루면 Role로 충분한 경우가 많습니다. 하지만 클러스터 범위 리소스나 공통 정책 재사용이 필요하면 ClusterRole이 더 적합합니다.

Q3. RBAC 최소 권한은 얼마나 잘게 쪼개야 하나요?

정답은 없습니다. 다만 사람별로가 아니라 역할별로 나누는 쪽이 운영하기 쉽습니다. 배포 전용, 조회 전용, 로그 조회 전용처럼 나누는 방식이 실무적입니다.

Q4. Secret 접근은 정말 따로 봐야 하나요?

네, 저는 따로 봐야 한다고 생각합니다. Secret은 영향도가 커서 다른 읽기 권한과 한 묶음으로 주지 않는 편이 안전합니다.

최소 권한 전후 차이를 시각화하면 팀 설득이나 운영 표준화에 꽤 도움이 됩니다.

9. 마무리: 쿠버네티스 RBAC 보안은 결국 운영 습관입니다

쿠버네티스 RBAC 보안은 어려운 개념이라기보다, 귀찮아서 미루기 쉬운 운영 습관에 가깝습니다. 저도 처음엔 일단 되게 만드는 쪽으로 갔었는데, 실제로 써보니까 결국 돌아와서 정리하게 되더라고요. 그래서 처음부터 RBAC 최소 권한 기준으로 설계하는 게 낫습니다.

오늘 내용은 체크리스트 중심으로 정리했지만, 다음 단계에서는 ServiceAccount 토큰 관리, Admission Controller(어드미션 컨트롤러, 요청 검증/제어), NetworkPolicy와 함께 묶어서 보시면 훨씬 좋습니다. 이전 글에서 다뤘던 네임스페이스 분리 전략이 있다면 같이 연결해서 보셔도 좋고요. 다음 글에서는 쿠버네티스 보안 체크리스트를 확장해서 Pod Security와 Secret 관리까지 묶어 다뤄볼 예정입니다.

정리하자면 이렇습니다. 권한은 넓게 주는 순간 편하지만, 운영은 그때부터 복잡해집니다. 반대로 처음부터 좁게 주면 조금 번거롭지만, 나중에 훨씬 덜 흔들립니다. 저는 후자가 맞더라고요.

📚 함께 읽으면 좋은 글

• Rancher 2.x에서 차세대로 마이그레이션: 실제 경험과 주요 변경점
• Argo CD 멀티 클러스터 동기화 문제 해결: 실제 운영 사례와 디버깅 팁
• Kubernetes 스토리지: Longhorn vs Rook-Ceph 성능 벤치마크
• 쿠버네티스 보안: RBAC 권한 오남용 방지 및 클라우드 계정 탈취 대응 전략