K8s 'Forbidden' 오류, 더 이상 헤매지 마세요: 권한 오류 완벽 진단 및 해결 가이드

"Forbidden" 메시지를 마주하는 순간, 개발자나 DevOps 엔지니어의 심장은 잠시 멈추곤 합니다. 마치 시스템이 "당신은 이 문을 열 자격이 없다"고 단호하게 거절하는 것 같죠. Kubernetes 환경에서 이 오류는 가장 흔하지만, 동시에 가장 근본적인 이해가 필요한 지점입니다. 단순히 설정을 잘못 건드린 것인지, 아니면 인증(Authentication) 과정에 문제가 생긴 것인지, 아니면 인가(Authorization) 정책이 미흡한 것인지 파악하는 것이 핵심입니다.

이 글은 단순히 에러 메시지를 띄워주는 튜토리얼이 아닙니다. K8s의 보안 모델인 RBAC(Role-Based Access Control)의 작동 원리부터, 서비스가 자신을 증명하는 방법(ServiceAccount), 그리고 민감 정보를 안전하게 관리하는 방법(Secret)까지, 마치 선배 엔지니어가 옆에서 코드를 보며 팁을 주는 것처럼, 실무 관점에서 'Forbidden'의 근본 원인을 체계적으로 분석하고 해결하는 가이드입니다.

🚀 1단계: 인증과 인가, 개념부터 확실히 잡기

K8s의 권한 문제는 대부분 이 두 가지 개념의 혼동에서 비롯됩니다.

1. 인증 (Authentication, AuthN): "당신이 누구인가?"

   • 시스템이 요청을 보낸 주체(Principal)가 누구인지 확인하는 과정입니다.
   • 예시: "이 요청은 frontend-service라는 이름의 파드에서 왔는가?"
   • K8s에서는 주로 ServiceAccount와 그에 연결된 토큰을 통해 신원을 증명합니다.

2. 인가 (Authorization, AuthZ): "당신이 무엇을 할 수 있는가?"

   • 신원이 확인된 주체에게 특정 리소스(Namespace, Pod 등)에 대해 특정 작업(Get, List, Create 등)을 수행할 권한이 있는지 확인하는 과정입니다.
   • 예시: "네, frontend-service가 맞습니다. 하지만 이 서비스는 '읽기 전용'만 허용됩니다."
   • 이 역할을 하는 것이 바로 RBAC입니다.

💡 실무 Tip: 'Forbidden' 에러가 발생했다면, 90%의 경우 AuthN(신분 확인)은 성공했지만, AuthZ(권한 확인)에서 실패했을 가능성이 높습니다. 즉, "누구인지는 알겠는데, 뭘 하라는 건지 모르겠다"는 상황입니다.

🛡️ 2단계: RBAC의 심층 이해 - Role, ClusterRole, Binding의 역할 분담

RBAC는 세 가지 핵심 오브젝트로 구성됩니다. 이들이 어떻게 상호작용하는지 이해하는 것이 가장 중요합니다.

Role vs. ClusterRole: 범위의 차이

RoleBinding vs. ClusterRoleBinding: 연결고리

Role/ClusterRole이 '권한 목록'이라면, Binding은 '누구에게 이 권한 목록을 부여할지'를 연결하는 접속권입니다.

• RoleBinding: 특정 네임스페이스 내에서 ServiceAccount에 Role을 바인딩합니다. (가장 일반적)
• ClusterRoleBinding: 클러스터 전체 범위의 ClusterRole을 ServiceAccount에 바인딩합니다. (클러스터 레벨 권한 부여 시)

🛠️ 실습 예제: Role, ServiceAccount, RoleBinding 조합 YAML

다음은 dev-ns 네임스페이스 내에서 특정 서비스 계정(report-reader)이 'Pod 목록 조회'만 할 수 있도록 제한하는 예시입니다.

# 1. Role 정의: 'Pod 목록 조회' 권한만 정의
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-ns
  name: pod-reader-role
rules:
- apiGroups: [""] # Core API Group (Pod, Service 등)
  resources: ["pods"]
  verbs: ["get", "list"] # 조회만 허용
---
# 2. ServiceAccount 정의: 신원(ID) 부여
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: dev-ns
  name: report-reader-sa
---
# 3. RoleBinding: ServiceAccount에 Role을 연결 (실제 권한 부여)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-ns
  name: report-reader-binding
subjects:
- kind: ServiceAccount
  name: report-reader-sa
  namespace: dev-ns
roleRef:
  kind: Role
  name: pod-reader-role
  apiGroup: rbac.authorization.k8s.io

🔒 3단계: 최소 권한 원칙(PoLP)과 Secret 관리

권한을 부여할 때는 반드시 **최소 권한 원칙(Principle of Least Privilege, PoLP)**을 따라야 합니다. 즉, 해당 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 합니다.

시나리오 적용: 특정 네임스페이스에서만 읽기 권한이 필요한 경우

만약 billing-ns 네임스페이스에서만 billing-api 파드가 ConfigMap의 내용만 읽어야 한다고 가정해 봅시다.

1. Role 정의: ConfigMap 리소스에 대해 get 및 list 권한만 부여합니다.
2. RoleBinding: billing-api의 ServiceAccount에 이 Role을 바인딩합니다.
3. Secret 관리: 이 API가 외부 DB 접속을 위해 필요한 비밀번호는 Secret 오브젝트로 관리하고, 이 Secret에 접근할 수 있는 권한(예: get 권한)을 별도로 부여해야 합니다.

⚠️ 주의: Secret 자체를 노출하는 것만큼, Secret에 접근할 수 있는 권한을 과도하게 부여하는 것이 더 큰 보안 취약점이 될 수 있습니다.

🔎 4단계: 권한 오류 발생 시 5단계 디버깅 체크리스트

"Forbidden" 에러가 발생했을 때, 다음 순서대로 점검해보세요. 이 순서가 가장 효율적입니다.

1. [Scope 확인] 네임스페이스 범위 확인: 요청이 발생한 네임스페이스가 올바른가? (ClusterScope vs. NamespaceScope)
2. [AuthN 확인] ServiceAccount/Token 확인: 요청을 보내는 파드가 올바른 ServiceAccount를 사용하고, 해당 토큰이 유효한가? (kubectl describe sa <sa-name> -n <ns>)
3. [AuthZ 확인] Role/ClusterRole 확인: 해당 ServiceAccount에 바인딩된 Role 또는 ClusterRole이 존재하는가?
4. [Verb/Resource 확인] 구체적 권한 확인: 필요한 리소스(pods, secrets)와 동사(get, list, delete)가 모두 명시되었는가?
5. [Audit Log 분석] 최종 검증: 클러스터의 Audit Log를 확인하여, 실제로 어떤 주체(Subject)가 어떤 리소스에 대해 어떤 액션(Verb)을 시도했는지 기록을 역추적합니다. (가장 정확하지만, 접근 권한이 필요함)

✨ 전문적인 시야로 본 추가 팁: 요즘은 GitOps 트렌드에 따라, 이러한 모든 RBAC 정책(Role, Binding)을 YAML 파일로 관리하고 Git에 커밋하여 Policy as Code로 관리하는 것이 표준입니다. 또한, 외부 인증 시스템(IdP)과의 연동을 위해 OIDC(OpenID Connect)를 활용하는 방식도 점차 보편화되고 있습니다.

맺음말: 보안은 습관입니다

Kubernetes는 강력한 도구인 만큼, 그만큼 보안의 책임도 무겁습니다. 'Forbidden' 에러는 시스템이 우리에게 보내는 가장 친절한 경고등입니다. 이 경고등을 무시하지 않고, AuthN $\rightarrow$ AuthZ $\rightarrow$ PoLP 순서로 체계적으로 접근하는 습관을 들이는 것만으로도 운영 안정성은 비약적으로 높아질 것입니다.

자주 묻는 질문 (FAQ)

Q1. ServiceAccount를 지정하지 않아도 권한이 생기나요? A1. 기본적으로 파드는 default ServiceAccount를 사용합니다. 하지만 보안상 명시적으로 필요한 ServiceAccount를 지정하고, 그 SA에 필요한 최소한의 권한만 바인딩하는 것이 원칙입니다.

Q2. Role과 ClusterRole 중 무엇을 사용해야 할지 모르겠어요. A2. 만약 특정 네임스페이스(예: dev) 내의 리소스만 건드리면 Role을 사용하세요. 클러스터 전체의 리소스(예: 모든 네임스페이스의 PersistentVolumeClaim)에 영향을 주는 작업을 하려면 ClusterRole을 사용해야 합니다.

Q3. Audit Log를 확인하는 것이 정말 필수인가요? A3. 필수적입니다. 디버깅 과정에서 'Forbidden'을 받았을 때, Audit Log는 "왜 거부되었는지"에 대한 가장 객관적이고 최종적인 증거를 제공합니다. 운영 환경에서는 반드시 모니터링 대상에 포함해야 합니다.