🎯 쿠버네티스 클러스터 권한 관리 가이드 - IAM, RBAC, Context 전환의 핵심

📑 목차

환경별 차이점
로컬 멀티 클러스터
IAM과 RBAC
컨텍스트 전환의 필수성
클라우드 현실
실전 보안 시나리오

1. 로컬 vs 클라우드 환경의 극명한 차이점

핵심 개념

로컬 개발 환경과 클라우드 환경은 권한 관리 방식이 완전히 다릅니다. 이 차이점을 이해하지 못하면 프로덕션 환경에서 심각한 보안 사고가 발생할 수 있습니다.

🏠 로컬 환경 (minikube, kind, Docker Desktop)

🤔 질문: “내 노트북에서는 모든 게 잘 되는데, 클라우드에서는 왜 안 될까?”

📋 로컬 환경의 특징과 함정

로컬 개발 시 일반적인 상황

전능한 권한: 로컬에서는 보통 cluster-admin 권한으로 작업

단순한 인증: kubeconfig 파일 하나로 모든 것 해결

보안 고려 부족: “내 컴퓨터니까 괜찮겠지”라는 생각

현실과의 괴리: 클라우드 배포 시 권한 오류 폭발

💻 로컬 환경 권한 확인

# 📊 로컬 환경에서의 권한 확인
# minikube
kubectl auth can-i "*" "*"
# 결과: yes (보통 cluster-admin 권한)
 
# 현재 사용자 확인
kubectl config view --minify -o jsonpath='{.users[0].name}'
# 결과: minikube (또는 docker-desktop)
 
# 모든 권한 확인
kubectl auth can-i --list
# 결과: 거의 모든 리소스에 대한 모든 동작 가능

📊 로컬 환경별 권한 비교

도구	기본 권한	인증 방식	보안 수준
minikube	cluster-admin	클라이언트 인증서	매우 낮음
Docker Desktop	cluster-admin	내장 인증	매우 낮음
kind	cluster-admin	kubeconfig	매우 낮음
k3s	cluster-admin	토큰 기반	낮음

☁️ 클라우드 환경 (AWS EKS, GCP GKE, Azure AKS)

🤔 질문: “클라우드에서는 왜 이렇게 복잡하고 엄격할까?”

📋 클라우드 환경의 현실적 제약

클라우드 첫 배포 시 겪는 일

IAM 인증 필요: AWS/GCP/Azure 계정 인증 먼저 필요

다층 권한 구조: 클라우드 IAM + 쿠버네티스 RBAC

네트워크 제한: VPC, 서브넷, 보안 그룹 설정 필요

비용 고려: 잘못된 설정으로 인한 예상치 못한 과금

💻 클라우드별 인증 과정

# 📊 AWS EKS 접근 과정
# 1. AWS CLI 인증
aws configure
aws sts get-caller-identity
 
# 2. EKS 클러스터 인증 정보 업데이트
aws eks update-kubeconfig --region us-west-2 --name my-cluster
 
# 3. 권한 확인 (처음엔 거의 아무것도 못함)
kubectl auth can-i get pods
# 결과: no (기본적으로 권한 없음)
 
# 4. aws-auth ConfigMap에 사용자 추가 필요
kubectl get configmap aws-auth -n kube-system -o yaml

# 📊 GCP GKE 접근 과정
# 1. gcloud 인증
gcloud auth login
gcloud config set project my-project
 
# 2. GKE 클러스터 인증 정보 가져오기
gcloud container clusters get-credentials my-cluster \
  --zone us-central1-a
 
# 3. 권한 확인
kubectl auth can-i get pods
# 결과: depends on IAM roles
 
# 4. RBAC 설정 필요
kubectl create clusterrolebinding my-binding \
  --clusterrole=view \
  --user=$(gcloud config get-value account)

📊 로컬 vs 클라우드 비교표

구분	로컬 환경	클라우드 환경
인증	단순 (kubeconfig만)	복합 (클라우드 IAM + k8s RBAC)
권한	전체 권한 (cluster-admin)	최소 권한 원칙
네트워크	localhost	VPC, 방화벽, 로드밸런서
비용	무료	시간당 과금
보안	개인 컴퓨터 수준	엔터프라이즈 수준
복잡도	매우 단순	높음

2. 로컬 멀티 클러스터 환경 구축하기

핵심 개념

로컬에서 여러 개의 쿠버네티스 클러스터를 구축하여 실제 엔터프라이즈 환경과 유사한 멀티 클러스터 권한 관리를 연습할 수 있습니다.

🏗️ 로컬 멀티 클러스터 아키텍처 설계

🤔 질문: “실제 회사에서는 개발/스테이징/프로덕션 클러스터가 분리되어 있는데, 로컬에서도 비슷하게 만들 수 있을까?”

📋 엔터프라이즈급 멀티 클러스터 시뮬레이션

로컬 환경에서 구축할 클러스터들

dev-cluster (kind): 자유로운 개발 환경

staging-cluster (minikube): 프로덕션 유사 환경

prod-cluster (k3s): 제한적 프로덕션 시뮬레이션

mgmt-cluster (Docker Desktop): 모니터링/관리 전용

💻 실제 멀티 클러스터 구축 과정

# 📊 1. 개발 클러스터 생성 (kind)
cat <<EOF > dev-cluster-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 80
    hostPort: 8080
- role: worker
EOF
 
kind create cluster --config dev-cluster-config.yaml
 
# 📊 2. 스테이징 클러스터 생성 (minikube)
minikube start -p staging \
  --memory=4096 \
  --cpus=2 \
  --disk-size=20g \
  --kubernetes-version=v1.28.0
 
# 📊 3. 프로덕션 시뮬레이션 클러스터 (k3s)
curl -sfL https://get.k3s.io | INSTALL_K3S_NAME=prod sh -
# kubeconfig를 ~/.kube/config-prod로 복사
 
# 📊 4. 관리 클러스터 (Docker Desktop 활용)
# Docker Desktop의 Kubernetes 활성화

📊 클러스터별 특성 매트릭스

클러스터	도구	CPU/Memory	용도	권한 수준
dev	kind	2GB	자유로운 실험	cluster-admin
staging	minikube	4GB	통합 테스트	제한적 admin
prod	k3s	2GB	프로덕션 시뮬레이션	최소 권한
mgmt	Docker Desktop	1GB	모니터링 도구	read-only

🔑 클러스터별 권한 체계 설정

🤔 질문: “각 환경마다 어떻게 다른 권한 정책을 적용할까?”

📋 환경별 권한 정책 설계

실제 기업의 권한 정책 시뮬레이션

개발 환경: 개발자에게 거의 모든 권한

스테이징: 배포 권한은 CI/CD만, 읽기는 개발자

프로덕션: SRE만 쓰기 권한, 개발자는 읽기 전용

관리: 모니터링팀만 접근 가능

💻 클러스터별 RBAC 설정

# 📊 개발 클러스터 - 관대한 권한
kubectl config use-context kind-dev-cluster
kubectl create namespace development
 
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developers-full-access
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF

# 📊 스테이징 클러스터 - 제한적 권한
kubectl config use-context staging
kubectl create namespace staging
 
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: staging-developer
rules:
- apiGroups: ["", "apps", "extensions"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log", "pods/portforward"]
  verbs: ["get", "list", "create"]
EOF

# 📊 프로덕션 클러스터 - 최소 권한
kubectl config use-context k3s-prod
kubectl create namespace production
 
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: prod-read-only
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "watch"]
EOF

🎯 사용자별 kubeconfig 생성

# 📊 개발자용 제한된 kubeconfig 생성
# 1. ServiceAccount 생성
kubectl create serviceaccount jane-developer -n development
 
# 2. 토큰 추출
TOKEN=$(kubectl create token jane-developer -n development)
 
# 3. 제한된 kubeconfig 생성
kubectl config set-cluster dev-cluster \
  --server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') \
  --certificate-authority-data=$(kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}') \
  --kubeconfig=jane-dev-config
 
kubectl config set-credentials jane-developer \
  --token=$TOKEN \
  --kubeconfig=jane-dev-config
 
kubectl config set-context jane-dev-context \
  --cluster=dev-cluster \
  --user=jane-developer \
  --namespace=development \
  --kubeconfig=jane-dev-config
 
kubectl config use-context jane-dev-context --kubeconfig=jane-dev-config

3. 클라우드 IAM과 쿠버네티스 RBAC 통합 이해

핵심 개념

클라우드 환경에서는 클라우드 IAM과 쿠버네티스 RBAC가 함께 작동하여 이중 보안을 제공합니다. 이 관계를 이해하는 것이 핵심입니다.

🔐 이중 보안 계층의 작동 원리

🤔 질문: “클라우드 IAM과 쿠버네티스 RBAC는 어떻게 함께 작동할까?”

📋 이중 인증 과정

AWS EKS에서의 실제 인증 과정

1단계 (클라우드 IAM): AWS IAM으로 클러스터 접근 권한 확인

2단계 (K8s RBAC): 클러스터 내부에서 세부 권한 확인

매핑: aws-auth ConfigMap이 IAM 사용자를 K8s 사용자로 변환

권한 적용: K8s RBAC 규칙에 따라 실제 작업 권한 결정

💻 AWS EKS IAM + RBAC 통합 설정

# 📊 1. AWS IAM 정책 생성 (클러스터 접근용)
aws iam create-policy \
  --policy-name EKSClusterAccess \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "eks:DescribeCluster",
          "eks:ListClusters"
        ],
        "Resource": "*"
      }
    ]
  }'
 
# 📊 2. aws-auth ConfigMap 설정 (IAM → K8s 사용자 매핑)
kubectl get configmap aws-auth -n kube-system -o yaml > aws-auth.yaml
 
# aws-auth.yaml 편집하여 사용자 추가
cat <<EOF >> aws-auth.yaml
  mapUsers: |
    - userarn: arn:aws:iam::123456789:user/developer
      username: developer
      groups:
        - system:masters
EOF
 
kubectl apply -f aws-auth.yaml
 
# 📊 3. K8s RBAC 규칙 설정
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-role
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developer-binding
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-role
  apiGroup: rbac.authorization.k8s.io
EOF

📊 클라우드별 IAM + RBAC 통합 방식

클라우드	IAM 서비스	K8s 통합 방식	사용자 매핑
AWS EKS	AWS IAM	aws-auth ConfigMap	mapUsers/mapRoles
GCP GKE	Google Cloud IAM	자동 연동	Google 계정 직접 매핑
Azure AKS	Azure AD	AAD 통합	Azure AD 그룹 매핑

🎯 IRSA와 Workload Identity 이해

🤔 질문: “파드가 클라우드 서비스에 접근할 때는 어떻게 권한을 관리할까?”

📋 파드 수준 클라우드 권한 관리

파드가 S3에 접근하는 과정 (AWS)

ServiceAccount 생성: K8s ServiceAccount + AWS IAM Role 연결

IRSA 설정: IAM Roles for Service Accounts 활성화

파드 배포: ServiceAccount를 사용하는 파드 생성

자동 인증: 파드가 자동으로 AWS 서비스 접근 권한 획득

💻 IRSA 설정 예시

# 📊 AWS IRSA 설정
# 1. OIDC 공급자 생성
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster \
  --approve
 
# 2. IRSA 생성
eksctl create iamserviceaccount \
  --name s3-access-sa \
  --namespace default \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve
 
# 3. 파드에서 ServiceAccount 사용
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: s3-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: s3-app
  template:
    metadata:
      labels:
        app: s3-app
    spec:
      serviceAccountName: s3-access-sa  # IRSA ServiceAccount 사용
      containers:
      - name: app
        image: amazon/aws-cli
        command: ["sleep", "infinity"]
EOF

4. 컨텍스트 전환: 왜 필수적인가?

핵심 개념

컨텍스트 전환은 다중 클러스터, 다중 환경에서 안전하고 효율적으로 작업하기 위한 필수적인 메커니즘입니다. 잘못된 환경에서의 작업은 치명적인 결과를 초래할 수 있습니다.

⚡ 컨텍스트 전환이 필수적인 이유

🤔 질문: “프로덕션 DB를 실수로 삭제한 적이 있나요?”

📋 실제 장애 시나리오

실수로 인한 프로덕션 장애

상황: 개발자가 개발 환경에서 테스트 중

실수: 컨텍스트 확인 없이 kubectl delete deployment critical-service 실행

결과: 현재 컨텍스트가 프로덕션이어서 실제 서비스 중단

교훈: 컨텍스트 전환과 확인의 중요성 재인식

💻 안전한 컨텍스트 관리

# 📊 현재 컨텍스트 확인 (매우 중요!)
kubectl config current-context
# 결과: production-cluster-admin
 
# 모든 컨텍스트 조회
kubectl config get-contexts
# * production-cluster-admin
#   development-cluster-user
#   staging-cluster-user
 
# 안전한 컨텍스트 전환
kubectl config use-context development-cluster-user
kubectl config current-context  # 재확인 필수!
 
# 특정 명령에만 다른 컨텍스트 사용
kubectl get pods --context=staging-cluster-user

🛡️ 컨텍스트 전환 보안 모범 사례

컨텍스트 안전 관리 방법

항상 확인: 명령 실행 전 현재 컨텍스트 확인

환경별 분리: 프로덕션과 개발 환경 컨텍스트 명확히 구분

제한된 권한: 필요한 최소 권한만 부여

자동화: 스크립트로 컨텍스트 전환 자동화

📊 컨텍스트 구성 요소

요소	설명	예시
Cluster	쿠버네티스 클러스터 정보	https://prod-k8s.company.com
User	인증 정보	jane.developer
Namespace	기본 네임스페이스	development
Context	위 3개의 조합	dev-jane-context

💻 고급 컨텍스트 관리 도구

# 📊 kubectx - 컨텍스트 빠른 전환
brew install kubectx
kubectx                    # 컨텍스트 목록
kubectx development        # 빠른 전환
kubectx -                  # 이전 컨텍스트로 돌아가기
 
# kubens - 네임스페이스 빠른 전환  
kubens                     # 네임스페이스 목록
kubens production          # 네임스페이스 전환
 
# kubeconfig 파일 직접 편집
kubectl config view        # 현재 설정 확인
kubectl config set-context my-context \
  --cluster=prod-cluster \
  --user=jane.admin \
  --namespace=default

🚨 컨텍스트 혼동 방지

# 📊 프롬프트에 현재 컨텍스트 표시
# ~/.bashrc 또는 ~/.zshrc에 추가
kube_ps1() {
  local context=$(kubectl config current-context 2>/dev/null)
  if [[ -n "$context" ]]; then
    echo "[k8s:$context]"
  fi
}
PS1='$(kube_ps1) \u@\h:\w\$ '
 
# 위험한 환경에서 추가 확인 강제
prod_kubectl() {
  local current_context=$(kubectl config current-context)
  if [[ "$current_context" == *"prod"* ]]; then
    echo "⚠️  PRODUCTION ENVIRONMENT!"
    echo "Current context: $current_context"
    echo "Command: kubectl $@"
    read -p "Are you sure? (yes/no): " confirm
    if [[ "$confirm" == "yes" ]]; then
      kubectl "$@"
    else
      echo "Command cancelled."
    fi
  else
    kubectl "$@"
  fi
}
alias kubectl=prod_kubectl

5. 실제 클라우드 환경에서 놓치기 쉬운 차이점들

핵심 개념

로컬 환경에서 잘 동작하던 것들이 클라우드에서는 예상과 다르게 동작하는 경우가 많습니다. 이런 차이점을 미리 이해하고 준비해야 합니다.

⚡ 클라우드 환경의 숨겨진 복잡성

🤔 질문: “로컬에서는 잘 되는데, AWS EKS에 배포하면 왜 권한 오류가 날까?”

📋 실제 클라우드 배포 시 마주치는 문제들

클라우드 배포 첫날 겪는 일들

IAM 역할 매핑: aws-auth ConfigMap 설정 필요

네트워크 정책: VPC, 서브넷, 보안 그룹의 복잡함

서비스 계정 권한: 파드가 AWS 서비스 접근 시 필요한 IRSA

로드밸런서 제한: ALB 인그레스 컨트롤러 설정의 복잡성

💻 AWS EKS의 현실적인 권한 설정

# 📊 실제 EKS 클러스터에서 겪는 권한 문제들
 
# 1. kubectl 명령이 안 되는 이유
kubectl get pods
# error: You must be logged in to the server (Unauthorized)
 
# 해결: aws-auth ConfigMap에 사용자 추가
kubectl get configmap aws-auth -n kube-system -o yaml
# 현재 사용자를 mapUsers에 추가해야 함
 
# 2. 파드가 AWS 서비스에 접근하지 못하는 이유
kubectl logs my-pod
# error: unable to load AWS credentials
 
# 해결: IRSA (IAM Roles for Service Accounts) 설정
eksctl create iamserviceaccount \
  --name my-service-account \
  --namespace default \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/S3ReadOnlyAccess \
  --approve

📊 클라우드별 권한 복잡도 비교

요소	로컬 환경	AWS EKS	GCP GKE	Azure AKS
기본 접근	cluster-admin	IAM 사용자 매핑 필요	Google 계정 자동 연동	Azure AD 통합
파드 권한	제한 없음	IRSA 설정 필요	Workload Identity	Pod Managed Identity
네트워크	localhost	VPC 설정	VPC 네이티브	VNET 통합
스토리지	hostPath	EBS/EFS	Persistent Disk	Azure Disk

🔍 클라우드 환경 권한 디버깅 가이드

🤔 질문: “클라우드에서 권한 오류가 났을 때 어디서부터 확인해야 할까?”

📋 단계별 트러블슈팅 체크리스트

권한 오류 해결 순서

클라우드 IAM 확인: 클러스터 접근 권한이 있는가?

Kubernetes RBAC 확인: 클러스터 내부 권한이 있는가?

네트워크 확인: VPC/서브넷 설정이 올바른가?

서비스 계정 확인: 파드가 클라우드 서비스에 접근 가능한가?

💻 실제 디버깅 명령어들

# 📊 AWS EKS 권한 디버깅
# 1. 현재 IAM 사용자/역할 확인
aws sts get-caller-identity
 
# 2. EKS 클러스터 접근 권한 확인
aws eks describe-cluster --name my-cluster
 
# 3. aws-auth ConfigMap 확인
kubectl get configmap aws-auth -n kube-system -o yaml
 
# 4. 현재 사용자의 K8s 권한 확인
kubectl auth can-i "*" "*" --all-namespaces
kubectl auth whoami
 
# 5. 특정 파드의 서비스 계정 확인
kubectl get pod my-pod -o jsonpath='{.spec.serviceAccountName}'
kubectl describe serviceaccount my-service-account

⚠️ 클라우드별 주의사항

자주 놓치는 클라우드 설정들

AWS EKS:

aws-auth ConfigMap 설정 누락

IRSA (IAM Roles for Service Accounts) 미설정

VPC CNI 플러그인 권한 부족

GCP GKE:

Workload Identity 미활성화

GCP API 서비스 비활성화

네트워크 정책 충돌

Azure AKS:

Azure AD Pod Identity 미설정

RBAC와 Azure AD 통합 문제

Network Security Group 제한

💡 클라우드 환경 학습 전략

로컬에서 클라우드 차이점 미리 체험하기

# 📊 로컬에서 클라우드 환경 시뮬레이션
# 1. 제한된 ServiceAccount 생성 (IAM 사용자 시뮬레이션)
kubectl create serviceaccount cloud-user-sim
kubectl create token cloud-user-sim
 
# 2. 최소 권한만 부여 (실제 클라우드와 유사)
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cloud-user-role
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]
EOF
 
# 3. 네트워크 정책으로 클라우드 네트워크 제한 시뮬레이션
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: simulate-cloud-network
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: restricted-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: allowed-app
    ports:
    - protocol: TCP
      port: 8080
EOF

🎯 실전 보안 시나리오

🚨 일반적인 보안 사고와 예방법

시나리오 1: 권한 에스컬레이션 공격

# 📊 공격 시도 탐지
# 의심스러운 권한 상승 시도
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin")'
 
# ServiceAccount의 과도한 권한 확인
kubectl get clusterrolebindings -o custom-columns=\
  NAME:.metadata.name,ROLE:.roleRef.name,SERVICE_ACCOUNT:.subjects[?(@.kind=="ServiceAccount")].name

시나리오 2: 잘못된 네임스페이스 접근

# 📊 네임스페이스별 접근 권한 감사
for ns in $(kubectl get ns -o name | cut -d/ -f2); do
  echo "=== Namespace: $ns ==="
  kubectl auth can-i "*" "*" --namespace=$ns --as=jane.developer
done

시나리오 3: 컨텍스트 혼동 방지

# 📊 프롬프트에 현재 컨텍스트 표시
# ~/.bashrc 또는 ~/.zshrc에 추가
kube_ps1() {
  local context=$(kubectl config current-context 2>/dev/null)
  if [[ -n "$context" ]]; then
    echo "[k8s:$context]"
  fi
}
PS1='$(kube_ps1) \u@\h:\w\$ '
 
# 위험한 환경에서 추가 확인 강제
prod_kubectl() {
  local current_context=$(kubectl config current-context)
  if [[ "$current_context" == *"prod"* ]]; then
    echo "⚠️  PRODUCTION ENVIRONMENT!"
    echo "Current context: $current_context"
    echo "Command: kubectl $@"
    read -p "Are you sure? (yes/no): " confirm
    if [[ "$confirm" == "yes" ]]; then
      kubectl "$@"
    else
      echo "Command cancelled."
    fi
  else
    kubectl "$@"
  fi
}
alias kubectl=prod_kubectl

🛡️ 보안 모니터링 및 알림

# 📊 권한 변경 감시 (Falco 규칙)
apiVersion: v1
kind: ConfigMap
metadata:
  name: falco-rbac-rules
data:
  rbac_rules.yaml: |
    - rule: RBAC Permission Changes
      desc: Detect changes to RBAC permissions
      condition: >
        ka and (
          ka.verb in (create, update, patch, delete) and
          ka.target.resource in (clusterroles, roles, clusterrolebindings, rolebindings)
        )
      output: >
        RBAC permission changed (user=%ka.user.name verb=%ka.verb 
        target=%ka.target.resource/%ka.target.name)
      priority: WARNING
      tags: [rbac, security]

📋 보안 체크리스트

일일 보안 점검 사항

컨텍스트 확인: 매 작업 전 현재 컨텍스트 확인

최소 권한 원칙: 필요한 최소 권한만 부여

정기 권한 감사: 월 1회 불필요한 권한 제거

로그 모니터링: 권한 관련 이벤트 실시간 감시

교육: 팀원 대상 보안 교육 정기 실시

🚀 자동화된 보안 도구

# 📊 권한 검사 자동화 스크립트
#!/bin/bash
# security-audit.sh
 
echo "🔍 Kubernetes Security Audit"
echo "=============================="
 
echo "📊 Cluster Admin Bindings:"
kubectl get clusterrolebindings -o custom-columns=\
  NAME:.metadata.name,SUBJECTS:.subjects[*].name | \
  grep cluster-admin
 
echo "⚠️  Over-privileged ServiceAccounts:"
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | 
    select(.subjects[]?.kind=="ServiceAccount") | 
    "\(.metadata.name): \(.subjects[].name)"'
 
echo "🔐 Current Context:"
kubectl config current-context
 
echo "✅ Audit Complete"

중요한 보안 원칙

Zero Trust: 모든 접근을 검증하고 최소 권한 부여

Defense in Depth: 다층 보안 방어 구조 구축

Continuous Monitoring: 지속적인 보안 모니터링 및 감사

Incident Response: 보안 사고 발생 시 신속한 대응 체계

📚 추가 학습 자료

📝 시험 대비 부록

실전 문제 연습

CKA/CKAD 실습 문제와 GCP Professional Cloud Architect 시나리오 문제는 별도 부록에서 확인하세요:

📝 시험 단골 문제 & 미니퀴즈 부록

CKA/CKAD 실습 문제 (ServiceAccount, Role, ClusterRole)

GCP Professional Cloud Architect 시나리오 문제

실전 미니퀴즈 및 검증 방법

시험 대비 전략 및 주의사항

🔗 공식 문서 참고

추가 학습 리소스

Kubernetes RBAC 공식 문서

GKE Workload Identity 가이드

CKA/CKAD 시험 가이드

GCP Professional Cloud Architect 시험 가이드

Quartz 4

탐색기

08_01쿠버네티스 클러스터 권한 관리 가이드 - IAM, RBAC, Context 전환의 핵심

🎯 쿠버네티스 클러스터 권한 관리 가이드 - IAM, RBAC, Context 전환의 핵심

📑 목차

1. 로컬 vs 클라우드 환경의 극명한 차이점

🏠 로컬 환경 (minikube, kind, Docker Desktop)

📋 로컬 환경의 특징과 함정

💻 로컬 환경 권한 확인

📊 로컬 환경별 권한 비교

☁️ 클라우드 환경 (AWS EKS, GCP GKE, Azure AKS)

📋 클라우드 환경의 현실적 제약

💻 클라우드별 인증 과정

📊 로컬 vs 클라우드 비교표

2. 로컬 멀티 클러스터 환경 구축하기

🏗️ 로컬 멀티 클러스터 아키텍처 설계

📋 엔터프라이즈급 멀티 클러스터 시뮬레이션

💻 실제 멀티 클러스터 구축 과정

📊 클러스터별 특성 매트릭스

🔑 클러스터별 권한 체계 설정

📋 환경별 권한 정책 설계

💻 클러스터별 RBAC 설정

🎯 사용자별 kubeconfig 생성

3. 클라우드 IAM과 쿠버네티스 RBAC 통합 이해

🔐 이중 보안 계층의 작동 원리

📋 이중 인증 과정

💻 AWS EKS IAM + RBAC 통합 설정

📊 클라우드별 IAM + RBAC 통합 방식

🎯 IRSA와 Workload Identity 이해

📋 파드 수준 클라우드 권한 관리

💻 IRSA 설정 예시

4. 컨텍스트 전환: 왜 필수적인가?

⚡ 컨텍스트 전환이 필수적인 이유

📋 실제 장애 시나리오

💻 안전한 컨텍스트 관리

🛡️ 컨텍스트 전환 보안 모범 사례

📊 컨텍스트 구성 요소

💻 고급 컨텍스트 관리 도구

🚨 컨텍스트 혼동 방지

5. 실제 클라우드 환경에서 놓치기 쉬운 차이점들

⚡ 클라우드 환경의 숨겨진 복잡성

📋 실제 클라우드 배포 시 마주치는 문제들

💻 AWS EKS의 현실적인 권한 설정

📊 클라우드별 권한 복잡도 비교

🔍 클라우드 환경 권한 디버깅 가이드

📋 단계별 트러블슈팅 체크리스트

💻 실제 디버깅 명령어들

⚠️ 클라우드별 주의사항

💡 클라우드 환경 학습 전략

로컬에서 클라우드 차이점 미리 체험하기

🎯 실전 보안 시나리오

🚨 일반적인 보안 사고와 예방법

시나리오 1: 권한 에스컬레이션 공격

시나리오 2: 잘못된 네임스페이스 접근

시나리오 3: 컨텍스트 혼동 방지

🛡️ 보안 모니터링 및 알림

📋 보안 체크리스트

🚀 자동화된 보안 도구

📚 추가 학습 자료

📝 시험 대비 부록

🔗 공식 문서 참고

그래프 뷰

목차