Kubernetes IAM 및 RBAC DevOps 및 SRE용

I’m ready to translate the article for you, but I need the text you’d like translated. Could you please paste the content you want converted into Korean? (The source line you provided will stay unchanged at the top.)

쿠버네티스에서 아이덴티티 이해하기 (초급 수준)

인증 vs 인가

• Authentication – 당신은 누구인가요?
• Authorization – 무엇을 할 수 있나요?

Kubernetes는 이 두 작업을 분리합니다: 인증은 아이덴티티를 확인하고, 인가는 권한을 결정합니다.

쿠버네티스의 아이덴티티 유형

Kubernetes는 세 가지 아이덴티티 유형을 인식합니다:

1. Users – 인간 운영자 또는 외부 시스템.
2. Groups – 사용자들의 논리적 집합.
3. ServiceAccounts – 파드 내부에서 실행되는 워크로드를 위한 아이덴티티.

사용자, 그룹 및 ServiceAccounts (초급 → 중급)

사용자 (인간)

사용자는 클러스터 외부에서 작업하는 사람을 나타냅니다 (예: kubectl).

Note: Kubernetes는 내장된 create user 명령을 제공하지 않으며, 사용자는 일반적으로 클러스터 외부에서 관리됩니다 (예: 인증서 또는 외부 아이덴티티 제공자).

그룹

그룹은 사용자를 논리적으로 모아 권한 할당을 간소화하는 컬렉션입니다.

ServiceAccounts

ServiceAccount(SA)은 클러스터 내부 워크로드를 위한 아이덴티티입니다.
일반적인 사용자는 cert‑manager 및 prometheus‑operator와 같은 오퍼레이터입니다.

핵심 원칙: 인간 ≠ 워크로드.

인증 실전 (중급 수준)

실습: 사용자 생성 (인증서 인증)

# Step 1: Generate a private key
openssl genrsa -out devuser.key 2048

# Step 2: Generate a CSR
openssl req -new -key devuser.key -out devuser.csr \
  -subj "/CN=devuser/O=dev-team"

# Step 3: Sign the certificate (using the cluster’s CA)
openssl x509 -req -in devuser.csr \
  -CA /etc/kubernetes/pki/ca.crt \
  -CAkey /etc/kubernetes/pki/ca.key \
  -CAcreateserial -out devuser.crt -days 365

# Step 4: Add the user to your kubeconfig
kubectl config set-credentials devuser \
  --client-certificate=devuser.crt \
  --client-key=devuser.key

# Step 5: Create a context for the new user
kubectl config set-context devctx \
  --cluster=kubernetes \
  --user=devuser

접근 테스트

kubectl --context=devctx get pods
# Expected output:
# Error from server (Forbidden): pods is forbidden

RBAC를 이용한 권한 부여 (중급)

RBAC 기본

RBAC (Role‑Based Access Control)는 주체(사용자, 그룹, 서비스 계정)를 허용된 리소스와 동사를 정의하는 역할에 바인딩함으로써 “무엇을 할 수 있나요?”라는 질문에 답합니다.

• 리소스 예시: pods, deployments, nodes
• 동사 예시: get, list, watch, create, delete

실용적인 RBAC 구성

역할 생성 (네임스페이스 범위)

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

kubectl apply -f role.yaml
# role.rbac.authorization.k8s.io/pod-reader created

역할을 사용자에게 바인딩

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-dev-pods
  namespace: dev
subjects:
- kind: User
  name: devuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f rolebinding.yaml
# rolebinding.rbac.authorization.k8s.io/read-dev-pods created

권한 테스트

# Should succeed (read‑only access to pods in dev)
kubectl --context=devctx get pods -n dev

# Should fail (no cluster‑scope permission)
kubectl --context=devctx get nodes
# Output:
# Error: User "devuser" cannot list resource "nodes" at cluster scope

클러스터 수준 액세스 (고급)

ClusterRole 생성

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

kubectl apply -f clusterrole.yaml
# clusterrole.rbac.authorization.k8s.io/node-reader created

ClusterRole을 ServiceAccount에 바인딩

# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-reader-binding
subjects:
- kind: ServiceAccount
  name: prometheus-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f clusterrolebinding.yaml
# clusterrolebinding.rbac.authorization.k8s.io/node-reader-binding created

액세스 확인

kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:prometheus-sa
# Output: yes

배포에서 ServiceAccount

ServiceAccount를 Deployment에 연결합니다 (발췌):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: prometheus-sa
      containers:
      - name: prometheus
        image: prom/prometheus:latest

Pod 내부에서 마운트된 인증 정보를 확인할 수 있습니다:

kubectl exec -it prometheus-xxxx -n monitoring -- ls /var/run/secrets/kubernetes.io/serviceaccount
# Output:
# ca.crt  token  namespace

Real DevOps/SRE 시나리오 (전문가 수준)

클라우드 IAM 통합 (전문가 수준)

Kubernetes 자체는 엔터프라이즈‑급 IAM을 제공하지 않습니다. 클라우드 제공업체는 외부 아이덴티티를 Kubernetes RBAC에 매핑하는 통합 기능을 제공합니다:

• Amazon EKS – 서비스 계정용 IAM 역할 (IRSA)
• Azure AKS – Azure AD 통합
• Google GKE – GCP IAM 바인딩

이러한 브리지를 통해 기존 클라우드 IAM 정책을 클러스터 접근에 활용할 수 있습니다.

안티‑패턴 (실제 실수)

• 애플리케이션에서 사용하는 서비스 계정에 cluster‑admin 권한을 부여합니다.
• 회전 없이 인간 사용자에게 정적 인증서를 사용합니다.
• 과도하게 권한이 부여된 RoleBinding (예: * verbs on * resources).
• 동일 그룹에 인간 아이덴티티와 워크로드 아이덴티티를 혼합합니다.

모범 사례 (엔터프라이즈 급)

• SSO/OIDC를 인간 인증에 사용하세요.
• 짧은 수명의 토큰과 인증서 회전을 선호하세요.
• Role/ClusterRole 정의에서 최소 권한 원칙을 적용하세요.
• 네임스페이스‑스코프와 클러스터‑스코프 권한을 구분하세요.
• RBAC 바인딩을 정기적으로 감사하세요 (kubectl get rolebindings,clusterrolebindings).
• Pod Security Standards와 NetworkPolicies를 RBAC와 함께 활용하세요.

Conclusion

이 가이드를 따라 하면 이제 다음을 이해할 수 있습니다:

• 쿠버네티스 인증이 어떻게 작동하는지 (인증서, OIDC 등)
• 사용자, 그룹, 서비스 계정의 구분
• RBAC 이론, 역할 생성 및 바인딩 메커니즘
• 네임스페이스‑스코프와 클러스터‑스코프 권한의 차이
• 실용적인 YAML 매니페스트와 명령줄 워크플로우
• 실제 DevOps/SRE 아이덴티티 시나리오와 클라우드 IAM 연동
• 흔히 발생하는 안티‑패턴 및 엔터프라이즈‑급 모범 사례

이 사고 모델은 프로덕션 급 SRE 및 플랫폼 엔지니어가 안전하고 유지보수 가능한 쿠버네티스 클러스터를 운영하는 데 기반이 됩니다.