[KCSA] Kubernetes RBAC 잘 사용하는 법

 

🔐 Kubernetes RBAC 잘 사용하는 법

🧱 기본 원칙: 최소 권한 원칙 (Least Privilege)

• 정말 필요한 권한만 부여하자!
  • 사용자나 서비스 계정에 꼭 필요한 권한만 주고, 그 외엔 주지 말자.
  • 예를 들어, 전체 클러스터가 아닌 특정 네임스페이스에서만 권한을 주는 게 안전해.
    • 그래서 RoleBinding을 쓰는 게 좋고, ClusterRoleBinding은 꼭 필요할 때만!
• 와일드카드 권한(*)은 피하자!
  • *을 쓰면 지금 있는 리소스뿐만 아니라 미래에 생길 리소스에도 권한을 주게 돼. 위험해!
• cluster-admin 계정은 최소한으로!
  • 대신, 낮은 권한 계정 + impersonate 권한 조합을 쓰면 실수로 전체 클러스터 망치는 걸 막을 수 있어.
• system:masters 그룹은 절대 주지 말자!
  • 이 그룹에 들어가면 모든 보안 정책이 무시돼. 어떤 권한 제거도 안 먹힘. 아주 위험!

---

🔑 특권 있는 토큰 최소화하기

• 강력한 권한이 있는 서비스 계정은 아무 컨테이너나 쓰면 안 됨.
  • 예를 들어, DaemonSet이 꼭 필요한 경우만 쓰고, 최대한 권한 줄이기.
• 신뢰 못 하는 Pod과 특권 있는 Pod은 절대 같이 돌리지 말기!
  • Taints, Tolerations, Affinity 설정으로 분리해두자.
  • 특히 Pod Security Standard를 안 지키는 Pod이랑은 반드시 분리!

---

🛡️ 보안 강화 팁 (Hardening)

• Kubernetes는 기본적으로 넉넉한 권한을 줘. 그걸 줄여줘야 해.
• system:unauthenticated 그룹에 권한 주는 경우 → 없애자.
  → API 서버에 네트워크만 연결되면 접근 가능하니까 위험해!
• 자동으로 서비스 계정 토큰 마운트하는 기능 끄기
  • automountServiceAccountToken: false로 설정하면 자동 마운트 방지 가능.

---

🔁 주기적인 점검 필수!

• 사용자가 삭제됐더라도, 같은 이름으로 계정 만들면 예전 권한 그대로 가져갈 수 있어. → 정기적으로 권한 정리 꼭 하기!

---

⚠️ 권한 상승(Privilege Escalation)이 가능한 위험 권한들

🔓 Secret 조회 권한

• get, list, watch 권한만 있어도 비밀 정보 다 볼 수 있음
  → kubectl get secrets -A -o yaml 하면 내용 다 보임

🛠️ 워크로드 생성 권한

• Pod 생성할 수 있는 권한 = 그 네임스페이스 내 다른 리소스(Secret, ConfigMap 등)에 접근 가능
  → Pod 안에서 다른 서비스 계정으로 실행도 가능
• 특권 있는 Pod은 노드 접근도 가능해서 권한 상승 위험 높음 → Pod Security Standard 꼭 적용하기 (Baseline이나 Restricted 모드)

💽 PersistentVolume 생성 권한

• hostPath 같은 걸 마음대로 만들 수 있게 되면, 노드의 파일 시스템 전체 접근 가능
  → 진짜 위험함. 운영자만 이 권한 갖게 하고, 일반 사용자는 PVC만 쓰도록 하자

🔁 Node의 proxy 서브리소스 접근

• Node에 proxy 접근 가능하면 Kubelet API 사용 가능
  → Pod 안에서 명령어 실행 가능, 로그도 안 남음! 조심

⚙️ RBAC의 특별한 verb들

• escalate: 자신보다 높은 권한 가진 Role을 생성 가능
• bind: 원래 권한 없는 Role에 사용자 바인딩 가능
• impersonate: 다른 사용자로 가장해서 권한 사용 가능
  → 셋 다 조심해서 필요한 사람한테만 줘야 함!

📜 CSR 및 인증서 발급 권한

• 권한 있으면 임의로 사용자 인증서 만들 수 있어
  → 시스템 컴포넌트와 같은 이름으로도 생성 가능, 위험

🧪 Admission Webhook 제어 권한

• webhook 수정 가능하면, 클러스터 내부 객체 다 읽거나 조작 가능

🧩 Namespace 수정

• Namespace의 라벨을 수정하면 Pod Security 정책이나 NetworkPolicy가 풀릴 수도 있음

---

💣 서비스 거부 공격(DoS) 위험

🧱 리소스 폭탄

• 리소스를 너무 많이 생성하면 etcd가 터져서 클러스터가 마비될 수 있음
• ResourceQuota 설정으로 생성할 수 있는 리소스 제한 필요!

---

✅ 요약하면,

1. 무조건 최소 권한 원칙
2. 특권 있는 계정은 조심히, 최소한만
3. 토큰/Secret 노출 막기
4. Pod 격리 잘 시키기
5. 정기적인 권한 점검 필수!
6. 위험한 verb (bind, escalate, impersonate)은 꼭 필요한 사람만