쿠버네티스 보안: 인증, RBAC, 서비스 계정, 파드 보안

쿠버네티스 보안은 두 갈래다. 하나는 API 서버에 누가 무엇을 할 수 있나(인증·인가), 다른 하나는 컨테이너가 노드에서 무엇을 할 수 있나(파드 보안)다. 파드 사이 네트워크 접근은 NetworkPolicy가 맡으며 쿠버네티스 네트워킹에 있다. Secret의 보안 수준은 쿠버네티스 저장소와 설정에 있다.

flowchart TB
  a["API 요청"] --> b["인증(Authentication): 누구인가"]
  b --> c["인가(Authorization): 이 동작을 해도 되나 (RBAC)"]
  c --> d["어드미션(Admission): 내용이 정책에 맞나<br/>(Pod Security Admission, 정책 엔진)"]
  d --> e["etcd 저장"]

인증: 누구인가

쿠버네티스에는 사람 사용자 오브젝트가 없다. 사용자는 외부(인증서, IdP)에서 확인된 이름과 그룹 문자열일 뿐이다. 프로그램용 신원인 서비스 계정만 쿠버네티스 오브젝트다.

어느 방식으로도 확인되지 않은 요청은 system:anonymous로 취급된다. 익명 요청에는 권한을 주지 않는다.

kubeconfig

kubectl은 ~/.kube/config(또는 KUBECONFIG 환경 변수의 파일들을 합친 것)를 읽어 어느 클러스터에 어떤 자격으로 접속할지 정한다.

apiVersion: v1
kind: Config
clusters:                          # 어디에: API 서버 주소와 CA 인증서
  - name: prod
    cluster: { server: https://prod.example.com:6443, certificate-authority-data: <base64> }
users:                             # 누구로: 자격 증명
  - name: alice
    user:
      exec:                        # 실행할 때마다 짧은 토큰을 받아 오는 플러그인
        apiVersion: client.authentication.k8s.io/v1
        command: kubectl
        args: [oidc-login, get-token, --oidc-issuer-url=https://idp.example.com]
contexts:                          # 조합: 클러스터 + 사용자 + 기본 네임스페이스
  - name: prod-alice
    context: { cluster: prod, user: alice, namespace: shop }
current-context: prod-alice

• 사용자 항목에는 인증서·키, 토큰, exec 플러그인을 쓸 수 있다. 파일에 긴 수명의 비밀을 두지 않으려면 exec 플러그인(kubelogin, aws eks get-token, gke-gcloud-auth-plugin)이 낫다.
• kubectl config get-contexts, use-context로 클러스터를 바꾼다. 운영 클러스터 컨텍스트를 실수로 쓰지 않도록 프롬프트에 현재 컨텍스트를 띄우는 것이 흔한 습관이다.

인가: RBAC

RBAC(Role-Based Access Control)는 「어떤 주체가 어떤 리소스에 어떤 동작(verb)을 할 수 있나」를 역할로 묶어 부여하는 방식이다. 규칙은 허용만 있고 거부는 없으며, 여러 바인딩의 권한이 합쳐진다.

주체(subject)는 User, Group, ServiceAccount다. ClusterRole을 RoleBinding으로 묶는 조합이 자주 쓰인다. 「파드 읽기」 ClusterRole을 하나 만들고 팀별 네임스페이스에서 RoleBinding하면, 정의는 하나로 두고 범위는 네임스페이스로 제한한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: deployer, namespace: shop }
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]                       # 코어 그룹
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: ci-deployer, namespace: shop }
subjects: [{ kind: ServiceAccount, name: ci, namespace: shop }]
roleRef: { kind: Role, name: deployer, apiGroup: rbac.authorization.k8s.io }

verb

pods/log, pods/exec, deployments/scale처럼 하위 리소스는 따로 권한을 준다. pods/exec의 create는 컨테이너 안에서 명령을 실행하는 권한이다.

최소 권한 원칙 적용

쿠버네티스는 cluster-admin, admin, edit, view 같은 기본 ClusterRole을 제공한다. 직접 만들기 전에 이것으로 충분한지 먼저 본다.

서비스 계정

서비스 계정(ServiceAccount)은 파드 안에서 도는 프로세스의 신원이다. 컨트롤러, CI 러너, 클러스터 정보를 읽는 앱처럼 API 서버를 부르는 프로그램이 이 신원으로 인증하고, RBAC로 권한을 받는다.

• 네임스페이스마다 default 서비스 계정이 자동으로 생기고, 지정하지 않은 파드는 이것을 쓴다. 앱별로 만들어 spec.serviceAccountName으로 지정한다.
• kubelet은 파드에 투사된(projected) 토큰을 /var/run/secrets/kubernetes.io/serviceaccount/(토큰, CA 인증서, 네임스페이스 파일)에 넣는다. 이 토큰은 대상(audience)과 만료 시간이 있고, kubelet이 만료 전에 갱신하며, 파드가 지워지면 무효가 된다.
• 쿠버네티스 1.24부터 서비스 계정마다 만료 없는 토큰 Secret을 자동으로 만들지 않는다. 클러스터 밖에서 쓸 토큰이 필요하면 kubectl create token <서비스 계정> --duration=1h로 짧게 발급한다.
• 같은 토큰을 클라우드 IAM과 연동해(EKS IRSA·Pod Identity, GKE Workload Identity) 파드에 클라우드 권한을 준다. 노드 IAM 역할에 권한을 몰아주지 않는다.

토큰 자동 마운트 끄기

대부분의 앱은 쿠버네티스 API를 부르지 않는데도 토큰이 마운트된다. 컨테이너가 뚫리면 공격자가 그 토큰으로 API를 탐색할 수 있다.

apiVersion: v1
kind: ServiceAccount
metadata: { name: web, namespace: shop }
automountServiceAccountToken: false        # 이 계정을 쓰는 파드 기본값
---
# 또는 파드 단위로 (파드 설정이 우선)
spec:
  serviceAccountName: web
  automountServiceAccountToken: false

파드 보안

securityContext

securityContext는 컨테이너가 노드에서 가질 권한을 정한다. 파드 수준과 컨테이너 수준에 둘 수 있고 컨테이너 쪽이 우선한다.

spec:
  securityContext:                       # 파드 수준
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001                       # 마운트한 볼륨의 그룹 소유권
    seccompProfile: { type: RuntimeDefault }
  containers:
    - name: app
      image: app:1.2.0
      securityContext:                   # 컨테이너 수준
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities: { drop: ["ALL"] }

파드 명세의 hostUsers: false는 파드에 사용자 네임스페이스를 줘서, 컨테이너 안의 root(UID 0)를 노드에서는 권한 없는 UID로 대응시킨다. 컨테이너 탈출이 일어나도 노드 root가 되지 않는다. 쿠버네티스 1.36에서 정식 기능이 됐다. 이 필드들이 기대는 리눅스 기능(capability, seccomp, LSM, 네임스페이스)은 Docker 컨테이너 운영과 리눅스 접근 제어에 있다.

Pod Security Standards

Pod Security Standards는 securityContext 등 파드 설정을 기준으로 정한 세 단계의 보안 수준 정의다.

Pod Security Admission

Pod Security Admission은 Pod Security Standards를 네임스페이스 단위로 강제하는 내장 어드미션 컨트롤러다. 쿠버네티스 1.25에서 정식이 됐고, 같은 버전에서 이전의 PodSecurityPolicy가 제거됐다. 네임스페이스 라벨로 설정한다.

apiVersion: v1
kind: Namespace
metadata:
  name: shop
  labels:
    pod-security.kubernetes.io/enforce: baseline     # 어기면 거부
    pod-security.kubernetes.io/warn: restricted      # 어기면 경고만
    pod-security.kubernetes.io/audit: restricted     # 어기면 감사 로그에 기록
    pod-security.kubernetes.io/enforce-version: latest

enforce는 파드에만 적용되므로, Deployment를 만들 때는 성공하고 ReplicaSet이 파드를 만들 때 실패한다. warn·audit은 워크로드 리소스의 파드 템플릿에도 적용되어 Deployment 단계에서 경고가 보인다. 그래서 흔한 도입 순서는 warn·audit으로 restricted를 걸어 위반을 모으고 → 고친 뒤 enforce를 올리는 것이다.

세 단계보다 세밀한 규칙(허용 레지스트리, 필수 라벨, latest 태그 금지)은 CEL로 쓰는 ValidatingAdmissionPolicy나 Kyverno·OPA Gatekeeper 같은 정책 엔진이 맡는다.

정리

• 요청은 인증 → 인가(RBAC) → 어드미션을 거친다. 사람은 OIDC 같은 외부 IdP로, 프로그램은 서비스 계정으로 인증한다.
• kubeconfig는 clusters(어디) · users(누구) · contexts(조합)로 짜인다.
• RBAC는 허용만 있다. Role·RoleBinding은 네임스페이스, ClusterRole·ClusterRoleBinding은 클러스터 범위이고, ClusterRole을 RoleBinding으로 좁혀 재사용할 수 있다. list와 파드 생성도 강한 권한이다.
• 서비스 계정 토큰은 만료와 파드 결속이 있는 투사 토큰이다. API를 부르지 않는 앱은 자동 마운트를 끈다.
• securityContext로 루트 실행·권한 상승·쓰기 가능한 루트 파일 시스템·capability를 없애고, Pod Security Admission으로 네임스페이스에 Baseline·Restricted를 강제한다.

관련 노트: 쿠버네티스 구조와 핵심 개념, 쿠버네티스 네트워킹, 쿠버네티스 저장소와 설정, Docker 컨테이너 운영, DevSecOps, 리눅스 접근 제어