인증과 접근 권한

inuit·2025년 5월 16일
kubernetes

All about 쿠버네티스

목록 보기
14/21
post-thumbnail

최근 업데이트일 2024-11-23

따라하며 배우는 쿠버네티스: 인증과 권한 관리

쿠버네티스: Authenticating

쿠버네티스: 쿠버네티스 API 접근 제어하기

쿠버네티스 클러스터에 접근하기 위한 과정(인증 → 인가 → 접근제어 → 승인제어)을 파악하고, 그 밖의 형식과 설정파일인 X.509와 kubeconfig에 대해서도 살펴보자.

1. 인증 (Authentication)

  • 모든 쿠버네티스 클러스터의 진입점은 api-server이다.
    • API 서버는 클러스터 상태 정보를 관리하고 리소스를 업데이트한다.
    • Pod 내에서 쿠버네티스 리소스를 관리하려면 kubectl 같은 쿠버네티스 CLI Tool로 API 서버와 통신해야 한다.
    • API 요청에는 User/Group 또는 Service Account(SA)를 통한 인증이 필요하다.
      • User Account: 외부 인증 시스템에 있는 사용자 정보 연결, 사람이 kubectl 등으로 외부에서 클러스터에 접근할 때 사용
      • Service Account: Pod에 위치한 어플리케이션이 사용하는 계정으로 API 서버에 접근할 때 사용
  • Pod 내에서 kubectl 명렁어를 실행하려면 kubectl이 설치된 이미지를 사용해서 API 서버와 통신하여야 한다. e.g. bitnami/kubectl:latest
  • 해당 이미지를 Pod로 실행하고 exec으로 Pod에 접속해 kubectl 명렁어를 실행하면 API 서버에게 거부당한다.
  • 모든 Pod는 특정 SA를 지정하지 않으면 default라는 SA를 가진다.
    • kubectl get sa: SA 조회

API 서버에 대한 접근 권한을 얻기 위해 인증 과정을 거쳐야 한다.

  • 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성된다.

    • 인증 방식설명
      Client Certificate주로 관리자나 kubeconfig로 접근하는 사용자
      Static Password File--basic-auth-file 플래그로 등록 (비추)
      Static Token File--token-auth-file로 토큰 등록
      Bootstrap Token클러스터 초기에 kubelet 등록용으로 사용
      ServiceAccount TokenPod 내부 어플리케이션의 API 접근용 JWT

  • 사람은 인증할 때 인증서를 사용하고, SA는 토큰을 이용한다.


사용자 인증

  • kubernetes-admin은 쿠버네티스의 전체 api를 컨트롤할 수 있는 루트와 같은 사용자이다.
  • Admin은 강력한 권한을 가지므로 사용자들은 제한된 권한을 할당받은 user를 이용해야 한다.
  • 일반 사용자가 클러스터에 kubectl로의 접근을 허용하는 과정
kubectl config view # 클러스터 정보, 인증 정보, 어떤 사용자로 접근 중인지, kubeconfig 파일의 전체 내용
cat ~/.kube/config # kubernetes-admin 인증서

# 일반 user가 사용할 RSA private key 생성
openssl genrsa -out user.key 2048 
# user.key의 공개키 + 신원정보(CN, O 등) 를 묶어 .csr 파일로
openssl req -new -key user.key -out user.csr -subj "/CN=user" 
vi csr-user.yaml # 쿠버네티스에 등록할 인증서 작성
  • CSR(Certificate Signing Request) 생성(서명 요청) 
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: user
spec:
  request: # 인증서 내용, cat user.csr | base64 | tr -d "\n"로 확인
  signerName: kubernetes.io/kube-apiserver-client # CSR을 서명할 사용자 지정
  usages: # 인증서가 사용될 목적을 지정
  - client auth # API 서버에 클라이언트로 인증하는 데 사용
  • 만든 CSR을 승인받고 kubeconfig에 사용자 정보 등록 및 context 설정
# 인증서 등록 -> Pending 상태
# Kubernetes 내에서 자체적으로 인증서를 서명 (CA 역할)
kubectl apply -f csr-user.yaml 

# csr 승인 요청 
kubectl certificate approve user 

# 인증서 저장
kubectl get csr user -o \
  jsonpath='{.status.certificate}'| base64 -d > user.crt 

# user의 키와 인증서를 쿠버네티스 config 파일에 등록 
kubectl config set-credentials user \
  --client-key=user.key \
  --client-certificate=user.crt \
  --embed-certs=true 
# config 파일에 context를 등록, kubectl use-context로 해당 사용자로 변경

kubectl config set-context myuser --cluster=kubernetes --user=user

SA 인증

Pod는 default SA를 자동으로 부여받으며, /var/run/secrets/kubernetes.io/serviceaccount/token 경로에 JWT 토큰이 자동 마운트되어 API 서버에 전달되어 인증 수단으로 사용된다.

apiVersion: v1
kind: Pod
metadata:
  name: testpod
  namespace: default
spec:
  containers:
  - image: nginx
    name: testpod
  serviceAccount: sa_name # 여기서 지정

Kubernetes에서 인증은 API 요청의 주체를 검증하는 첫 관문으로,
요청이 인증된 후에는 RBAC 등 정책을 통해 인가되며, 어드미션 컨트롤 단계를 거쳐 etcd에 기록된다.


2. 인가 (Authorization)

인증은 "누구인가?"를 확인하는 단계이고, 인가는 "그 사람이 할 수 있는가?"를 판단하는 단계이다.

  • 특정 사용자로부터 온 요청이 인증된 후 사용자가 무엇을 할 수 있는지를 인가한다.
  • 쿠버네티스는 ABAC(Attribute Based Access Control)이나 RBAC(Role Based Access Control)를 사용하여 인가 모듈을 지원한다.
    • ABAC은 수정 후 재시작이 필요해서 잘 사용하지 않는다.
  • Kubernetes API 서버는 --authorization-mode 플래그로 인가 모드를 설정할 수 있고, 복수 설정이 가능하다.
    • 권한 제어 방식설명
      RBACRole/ClusterRole로 권한 정의 → (Cluster)RoleBinding으로 사용자에게 연결 (표준)
      ABACJSON 파일로 속성 기반 정책 정의 (deprecated 성격)
      Webhook외부 시스템에 인가 요청 위임 (OAuth 연동 등)
      Nodekubelet 전용 인가 방식 (Node의 인증된 요청에 한함)
      AlwaysAllow모든 요청 허용 (테스트용)
      AlwaysDeny모든 요청 거부 (디버깅용)

인가는 인증된 요청자에게 무엇을 할 수 있는지 판단하는 절차로, 이것은 접근 제어 정책에 따라 결정된다. 접근 제어는 기본적으로는 RBAC 방식이 사용된다.


3. 접근 제어 (Access Control)

접근 제어 방식 중에서도 쿠버네티스에서 표준으로 사용하는 RBAC에 대해서 알아보자.

  • RBAC: 사용자의 역할(Role)과 그 역할이 가진 권한에 따라 요청이 허용되거나 거부된다.
    • 사용자는 직접 자원에 접근할 권한을 갖지 않고, 대신 Role이나 ClusterRole이라는 “권한 집합”을 생성하고, 이를 RoleBinding 또는 ClusterRoleBinding을 통해 사용자나 SA에 연결한다.
      • Role: 특정 네임스페이스 내 자원에 대한 권한 집합 (예: Pod 조회, 생성)
      • RoleBinding: Role과 사용자/SA를 연결하여 해당 권한을 부여
      • ClusterRole: 클러스터 전체 또는 모든 네임스페이스에 대한 권한 집합
        • cluster-admin: 모든 API, 모든 리소스에 대한 전체 권한
        • admin: 네임스페이스 수준에서 모든 리소스 수정 가능, RBAC 설정 가능
        • edit: 대부분의 리소스를 수정 가능 (RBAC 설정은 불가)
        • view: 리소스를 조회만 가능, 수정 불가
      • ClusterRoleBinding: ClusterRole과 사용자/SA를 연결
  • 네임스페이스 내에서만 적용되는 Role은 Role + RoleBinding로, 클러스터 전체에서 적용되는 Role은 ClusterRole + ClusterRoleBinding을 사용한다.
# ClusterRole, 모든 네임스페이스의 Pod 조회 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-pods-global
rules:
- apiGroups: [""] # Core API 그룹
  resources: ["pods"] # 권한이 적용되는 리소스
  verbs: ["get", "list"] # 해당 리소스에 대해 허용되는 동작

# ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: global-pod-read-binding
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io # RBAC의 기본 그룹
roleRef: # 어떤 역할을 부여할 것인지 지정
  kind: ClusterRole
  name: read-pods-global
  apiGroup: rbac.authorization.k8s.io
# developer라는 이름의 role에 pod에 대해 create, get, list, update, delete 권한을 부여
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
# rolebinding
kubectl create rolebinding developer-binding-myuser --role=developer --user=user

RBAC을 통해 사용자의 요청이 인가되더라도, Kubernetes는 리소스의 생성이나 변경이 실제로 클러스터에 반영되기 전, 추가적인 정책 검사(승인 제어)를 수행한다.


4. 승인 제어 (Admission Control)

생성해도 되는가? / 수정해도 되는가?에 대한 유효성을 검사하는 단계

  • Admission Control Module: 승인 제어를 수행하는 소프트웨어 모듈
    • 인가와는 다르게 요청 본문(오브젝트 내용)에 접근 가능
    • 요청을 거부하거나, 또는 요청 내용을 동적으로 수정 가능
    • 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후 오브젝트 저장소에 기록된다.
  • 어드미션 컨트롤러는 2종류이고, Mutating → Validating 순서로 호출된다.
    • MutatingAdmissionController: 요청을 수정할 수 있음
      • 기본값 세팅: 우리가 지정하지 않은 값들을 default 값으로 설정해주는 역할을 한다.
    • ValidatingAdmissionController: 요청이 유효한지 검사만 함
      • 유효성 검사: 생성되거나 삭제되는 yaml 파일에 대한 유효성을 검사

5. X.509 – 사용자 인증 형식

X.509는 공개키 기반 구조(PKI)에서 사용되는 표준 인증서 형식으로, 사용자의 공개 키와 신원 정보(CN, O, OU 등)를 담고 있으며, 이를 신뢰할 수 있는 인증기관(CA)가 서명한다.

  • SA가 내부 애플리케이션 인증 수단이라면, X.509 인증서는 외부 개발자, 운영자 등 사람이 사용하는 인증 수단이다.
  • Kubernetes는 이 표준을 기반으로 사용자를 인증하며, 쿠버네티스 클러스터는 기본적으로 자체 CA(ca.crt + ca.key in /etc/kubernetes/pki)를 가지고 있어, 외부 사용자의 인증서 요청을 스스로 검증하고 서명할 수 있다.
  • X.509 인증서는 외부 사용자가 kubeconfig를 통해 API 서버에 안전하게 접속할 수 있게 해준다.
  • 동작 과정
    1. 사용자: 개인 키 생성 (user.key)
    2. 사용자: CSR 생성 (user.csr)
    3. 사용자: 클러스터에 CSR 제출 (CertificateSigningRequest 리소스)
    4. 관리자: CSR 승인 (kubectl certificate approve)
      • CSR 승인 절차를 통해 자동으로 X.509 인증서를 발급
    5. 클러스터(CA): 서명된 인증서 발급 (user.crt)
    6. 사용자: kubeconfig에 user.crt, user.key 설정 → 인증 완료

6. kubeconfig

~/.kube/config 파일은 kubectl 명령어가 사용할 Kubernetes 클러스터 접속 정보를 담고 있는 설정 파일이다.

  • 해당 파일은 클러스터, 사용자 인증 정보, context 등을 포함하며, 사용자가 어떤 클러스터에 어떤 자격으로 접속할지를 정의한다.
    • clusters: 클러스터 API 서버의 주소 및 인증서 정보
    • users (credentials): 인증서(CRT), 키(KEY), 토큰 등 사용자 인증 정보
    • contexts: 클러스터 + 사용자 + 네임스페이스의 조합
    • current-context: kubectl 명령이 기본적으로 사용할 context
  • kubectl config view: 현재 kubeconfig 전체 구조 보기
  • kubectl은 자체적으로 인증/접속 기능이 없기 때문에, 접속 대상 클러스터와 사용자 인증 정보를 kubeconfig에서 읽어야 한다.
  • kubeconfig 파일에 인증서나 토큰이 없으면 API 서버는 인증을 거부한다.
# 사용자 인증 정보 추가 (credentials 생성)
kubectl config set-credentials user \ 
  --client-certificate=user.crt \ # 사용자 인증서
  --client-key=user.key \ # 사용자 비밀키
  --embed-certs=true # 인증서 내용을 파일 내에 직접 내장

# 클러스터 정보 등록 (보통 기본 config에 이미 등록됨)
kubectl config set-cluster cluster.local \
  --server=https://192.168.0.10:6443 \
  --certificate-authority=ca.crt \
  --embed-certs=true

# 컨텍스트 생성 (클러스터 + 사용자 + 네임스페이스 연결)
kubectl config set-context user@cluster.local \
  --cluster=cluster.local \
  --user=user \
  --namespace=default

# 컨텍스트 적용
kubectl config use-context user@cluster.local
profile
inuit
It’s always white night here.
이전 포스트

Kubernetes DNS

다음 포스트

Kubernetes Autoscaling

0개의 댓글