RBAC과 ServiceAccount 완벽 가이드

쿠버네티스 클러스터에서 누가 무엇을 할 수 있는지 제어하는 RBAC과 ServiceAccount를 초급자도 이해할 수 있도록 설명합니다. 실무에서 바로 적용할 수 있는 보안 설정 방법을 다룹니다.

---

목차

1. RBAC_개념_이해
2. Role과_ClusterRole
3. RoleBinding과_ClusterRoleBinding
4. ServiceAccount_생성
5. 최소_권한_원칙_적용
6. kubeconfig_관리

---

1. RBAC 개념 이해

입사한 지 얼마 되지 않은 김개발 씨가 쿠버네티스 클러스터에 처음으로 접속했습니다. kubectl get pods 명령어를 입력하자 "Error from server (Forbidden): pods is forbidden" 이라는 오류가 떴습니다.

분명 클러스터에 접속은 되었는데, 왜 파드 목록조차 볼 수 없는 걸까요?

RBAC은 Role-Based Access Control의 약자로, 역할 기반 접근 제어를 의미합니다. 마치 회사에서 직급에 따라 접근할 수 있는 문서가 다른 것처럼, 쿠버네티스에서도 사용자나 서비스 계정에게 특정 역할을 부여하여 권한을 제어합니다.

이를 통해 클러스터의 보안을 체계적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# RBAC 구성 요소 확인하기
# 클러스터에 정의된 역할 목록 조회
kubectl get roles --all-namespaces

# 클러스터 수준의 역할 목록 조회
kubectl get clusterroles

# 역할 바인딩 확인
kubectl get rolebindings --all-namespaces

# 특정 사용자의 권한 확인
kubectl auth can-i get pods --as=developer

# 모든 권한 확인
kubectl auth can-i --list --as=developer

김개발 씨는 당황했습니다. 로컬 개발 환경에서는 모든 명령어가 잘 작동했는데, 회사 클러스터에서는 왜 이런 오류가 나는 걸까요?

옆자리 박시니어 씨가 웃으며 설명해주었습니다. "회사 클러스터에는 RBAC이 설정되어 있어요.

아무나 모든 것을 볼 수 없도록 권한을 제어하는 거죠." 그렇다면 RBAC이란 정확히 무엇일까요? 쉽게 비유하자면, RBAC은 마치 회사의 출입 카드 시스템과 같습니다.

신입 사원은 자기 팀 사무실만 들어갈 수 있지만, 팀장은 회의실도 사용할 수 있고, 임원은 모든 층을 자유롭게 다닐 수 있습니다. 쿠버네티스의 RBAC도 이와 똑같이 동작합니다.

RBAC이 없던 시절에는 어땠을까요? 초기 쿠버네티스에서는 클러스터에 접속할 수 있는 사람이라면 누구나 모든 리소스를 조회하고 삭제할 수 있었습니다.

개발자가 실수로 프로덕션 환경의 중요한 파드를 삭제하는 사고가 종종 발생했습니다. 더 심각한 문제는 보안이었습니다.

외부에서 클러스터에 침입하면 모든 것을 장악당하는 상황이 벌어질 수 있었습니다. 바로 이런 문제를 해결하기 위해 RBAC이 도입되었습니다.

RBAC의 핵심은 네 가지 구성 요소에 있습니다. 먼저 Role은 특정 네임스페이스 내에서 어떤 작업을 할 수 있는지 정의합니다.

ClusterRole은 클러스터 전체에 적용되는 역할입니다. RoleBinding은 Role을 특정 사용자나 그룹에 연결합니다.

ClusterRoleBinding은 ClusterRole을 연결합니다. 위의 명령어들을 살펴보겠습니다.

kubectl get roles 명령어는 네임스페이스에 정의된 역할을 보여줍니다. kubectl auth can-i 명령어는 특정 사용자가 특정 작업을 할 수 있는지 확인할 때 유용합니다.

이 명령어를 통해 권한 설정이 제대로 되었는지 테스트할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 개발팀, 운영팀, 보안팀이 있는 회사를 생각해봅시다. 개발팀은 자신의 네임스페이스에서 파드를 생성하고 삭제할 수 있지만, 다른 팀의 네임스페이스는 조회만 가능합니다.

운영팀은 모든 네임스페이스를 관리할 수 있습니다. 보안팀은 감사 로그를 확인할 수 있습니다.

이렇게 역할에 따라 권한을 분리하면 실수로 인한 사고를 예방할 수 있습니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수 중 하나는 편의를 위해 cluster-admin 권한을 남발하는 것입니다. 이렇게 하면 RBAC을 설정한 의미가 없어집니다.

반드시 필요한 최소한의 권한만 부여해야 합니다. 다시 김개발 씨의 이야기로 돌아가봅시다.

박시니어 씨가 김개발 씨에게 적절한 역할을 바인딩해주었습니다. 이제 김개발 씨는 자신의 개발 네임스페이스에서 자유롭게 작업할 수 있게 되었습니다.

실전 팁

💡 - kubectl auth can-i 명령어로 권한 설정을 미리 테스트하세요

• 프로덕션 환경에서는 절대 cluster-admin을 일반 사용자에게 부여하지 마세요

---

2. Role과 ClusterRole

권한 설정의 기본을 이해한 김개발 씨가 이번에는 직접 역할을 만들어보려고 합니다. 그런데 Role과 ClusterRole 중 어떤 것을 사용해야 할지 고민됩니다.

둘의 차이점은 무엇이고, 언제 어떤 것을 선택해야 할까요?

Role은 특정 네임스페이스 내에서만 유효한 권한을 정의합니다. 반면 ClusterRole은 클러스터 전체에서 유효하거나, 네임스페이스가 없는 리소스에 대한 권한을 정의합니다.

마치 아파트 동 출입 권한과 단지 전체 출입 권한의 차이와 같습니다.

다음 코드를 살펴봅시다.

# Role 정의 - 특정 네임스페이스에서만 유효
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]          # 코어 API 그룹
  resources: ["pods"]       # 대상 리소스
  verbs: ["get", "list", "watch"]  # 허용할 동작

---
# ClusterRole 정의 - 클러스터 전체에서 유효
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

김개발 씨가 질문했습니다. "선배, Role이랑 ClusterRole이 뭐가 다른 거예요?

그냥 ClusterRole 하나만 쓰면 안 되나요?" 박시니어 씨가 화이트보드에 그림을 그리며 설명하기 시작했습니다. 쉽게 비유하자면, Role과 ClusterRole의 차이는 마치 아파트 보안 시스템과 같습니다.

Role은 특정 동의 출입 권한입니다. 101동 주민은 101동에만 들어갈 수 있죠.

ClusterRole은 단지 전체에 대한 권한입니다. 경비원은 모든 동을 순찰할 수 있습니다.

왜 이렇게 나눠 놓았을까요? 실제 운영 환경에서는 다양한 팀이 하나의 클러스터를 공유합니다.

프론트엔드 팀은 frontend 네임스페이스를, 백엔드 팀은 backend 네임스페이스를 사용합니다. 이때 각 팀은 자신의 네임스페이스에서만 작업할 수 있어야 합니다.

Role을 사용하면 이런 격리가 가능합니다. 반면 클러스터 관리자나 모니터링 시스템처럼 여러 네임스페이스에 걸쳐 작업해야 하는 경우도 있습니다.

이때는 ClusterRole이 필요합니다. 또한 노드, 퍼시스턴트볼륨처럼 네임스페이스에 속하지 않는 리소스에 대한 권한도 ClusterRole로만 정의할 수 있습니다.

위의 YAML 파일을 살펴보겠습니다. 첫 번째 Role 정의에서 namespace: development는 이 역할이 development 네임스페이스에서만 유효하다는 의미입니다.

rules 섹션의 apiGroups는 리소스가 속한 API 그룹을 지정합니다. 빈 문자열은 코어 API 그룹을 의미합니다.

resources는 권한을 부여할 대상 리소스입니다. verbs는 허용할 동작으로, get은 조회, list는 목록 조회, watch는 변경 감시를 의미합니다.

두 번째 ClusterRole에는 namespace 필드가 없습니다. ClusterRole은 클러스터 전체에 적용되기 때문입니다.

실무에서는 어떻게 선택할까요? 원칙은 간단합니다.

특정 네임스페이스에서만 필요한 권한이면 Role을, 여러 네임스페이스에서 필요하거나 클러스터 수준 리소스에 대한 권한이면 ClusterRole을 사용합니다. 흔히 하는 실수 중 하나는 편의상 모든 권한을 ClusterRole로 정의하는 것입니다.

이렇게 하면 권한이 필요 이상으로 넓어져 보안에 취약해집니다. 최소 권한 원칙을 항상 기억해야 합니다.

김개발 씨가 고개를 끄덕였습니다. "아, 그러니까 가능하면 Role을 쓰고, 꼭 필요할 때만 ClusterRole을 쓰라는 거죠?" 박시니어 씨가 웃으며 답했습니다.

"정확해요. 보안의 기본은 필요한 만큼만 권한을 주는 겁니다."

실전 팁

💡 - 네임스페이스 범위로 충분하다면 항상 Role을 우선 사용하세요

• verbs에는 필요한 동작만 정확히 명시하세요

---

3. RoleBinding과 ClusterRoleBinding

김개발 씨가 Role을 열심히 정의했습니다. 그런데 이상합니다.

Role을 만들었는데도 아무런 변화가 없습니다. 여전히 권한이 없다는 오류가 뜹니다.

박시니어 씨가 말했습니다. "Role만 만들면 소용없어요.

누군가에게 연결해줘야 하거든요."

RoleBinding과 ClusterRoleBinding은 정의된 역할을 실제 사용자, 그룹, 또는 서비스 계정에 연결하는 역할을 합니다. 마치 회사에서 직급을 정의하는 것과 실제로 사람에게 직급을 부여하는 것이 다른 것처럼, Role 정의와 Role 바인딩은 별개의 작업입니다.

다음 코드를 살펴봅시다.

# RoleBinding - Role을 사용자에게 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
- kind: User
  name: kimdev           # 연결할 사용자
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader       # 앞서 정의한 Role
  apiGroup: rbac.authorization.k8s.io

---
# ClusterRoleBinding - ClusterRole을 그룹에게 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

박시니어 씨가 화이트보드에 다시 그림을 그렸습니다. "Role은 권한의 정의이고, RoleBinding은 그 권한을 실제로 부여하는 거예요." 쉽게 비유하자면, 회사에서 과장이라는 직급을 정의하는 것과 김개발 씨를 과장으로 승진시키는 것은 다른 일입니다.

Role이 직급의 정의라면, RoleBinding은 승진 발령입니다. 왜 이렇게 분리해 놓았을까요?

이렇게 분리하면 유연성이 생깁니다. 하나의 Role을 여러 사용자에게 바인딩할 수 있습니다.

사용자가 퇴사하면 RoleBinding만 삭제하면 됩니다. Role 자체는 그대로 두고 다른 사람에게 새로 바인딩하면 됩니다.

위의 YAML 파일을 자세히 살펴보겠습니다. RoleBinding에서 subjects는 권한을 받을 주체를 지정합니다.

kind가 User이면 개별 사용자, Group이면 사용자 그룹, ServiceAccount이면 서비스 계정입니다. roleRef는 어떤 Role을 바인딩할지 지정합니다.

여기서 중요한 점이 있습니다. RoleBinding은 같은 네임스페이스의 Role만 참조할 수 있습니다.

하지만 ClusterRole을 참조하는 것도 가능합니다. 이 경우 ClusterRole의 권한이 해당 네임스페이스로 제한됩니다.

실무에서 자주 사용되는 패턴을 소개하겠습니다. 예를 들어 view라는 ClusterRole이 있습니다.

이것은 쿠버네티스에서 기본으로 제공하는 역할로, 리소스를 조회할 수 있는 권한을 가지고 있습니다. 이 ClusterRole을 각 네임스페이스에서 RoleBinding으로 연결하면, 해당 네임스페이스에서만 조회 권한을 부여할 수 있습니다.

하나의 ClusterRole을 여러 네임스페이스에서 재사용하는 효율적인 방법입니다. 주의할 점이 있습니다.

ClusterRoleBinding으로 cluster-admin을 바인딩하면 해당 주체는 클러스터의 모든 권한을 갖게 됩니다. 이것은 매우 위험합니다.

반드시 필요한 경우에만, 신중하게 사용해야 합니다. 김개발 씨가 질문했습니다.

"그럼 저한테 권한을 주려면 RoleBinding을 만들어달라고 요청하면 되는 거네요?" 박시니어 씨가 답했습니다. "맞아요.

정확히 어떤 네임스페이스에서 어떤 작업을 해야 하는지 알려주면, 적절한 Role과 RoleBinding을 만들어 줄게요."

실전 팁

💡 - 기본 제공되는 ClusterRole(view, edit, admin)을 활용하면 편리합니다

• RoleBinding은 삭제해도 Role은 남아있으니, 권한 회수 시 바인딩만 삭제하세요

---

4. ServiceAccount 생성

김개발 씨가 CI/CD 파이프라인을 구축하고 있습니다. 젠킨스에서 쿠버네티스에 배포하려면 클러스터에 접근해야 하는데, 사람이 아닌 시스템에게 어떻게 권한을 줄 수 있을까요?

바로 이때 ServiceAccount가 필요합니다.

ServiceAccount는 파드나 시스템이 쿠버네티스 API에 접근할 때 사용하는 계정입니다. 사람이 사용하는 User와 달리, 애플리케이션이나 자동화 도구를 위한 계정입니다.

마치 회사에서 직원 계정과 시스템 계정을 분리하는 것처럼, 쿠버네티스도 사용자와 서비스를 구분합니다.

다음 코드를 살펴봅시다.

# ServiceAccount 생성
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: ci-cd

---
# ServiceAccount에 Role 바인딩
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: jenkins-deployer
  namespace: ci-cd        # ServiceAccount가 있는 네임스페이스
roleRef:
  kind: Role
  name: deployment-manager
  apiGroup: rbac.authorization.k8s.io

---
# 파드에서 ServiceAccount 사용
apiVersion: v1
kind: Pod
metadata:
  name: jenkins-agent
spec:
  serviceAccountName: jenkins-deployer
  containers:
  - name: jenkins
    image: jenkins/jenkins

박시니어 씨가 설명했습니다. "쿠버네티스에는 두 종류의 계정이 있어요.

User는 사람을 위한 것이고, ServiceAccount는 시스템을 위한 것입니다." 쉽게 비유하자면, 회사 시스템을 생각해보세요. 직원들은 각자 ID로 로그인합니다.

하지만 백업 시스템이나 모니터링 시스템도 데이터에 접근해야 합니다. 이런 시스템에게는 별도의 서비스 계정을 만들어줍니다.

ServiceAccount가 바로 그런 역할입니다. ServiceAccount의 특징을 알아봅시다.

첫째, ServiceAccount는 네임스페이스에 속합니다. 각 네임스페이스에는 default라는 ServiceAccount가 자동으로 생성됩니다.

별도로 지정하지 않으면 파드는 이 default ServiceAccount를 사용합니다. 둘째, ServiceAccount를 생성하면 관련 토큰이 자동으로 관리됩니다.

쿠버네티스 1.24 버전부터는 토큰이 시간 제한이 있는 형태로 발급됩니다. 위의 YAML 파일을 살펴보겠습니다.

먼저 ci-cd 네임스페이스에 jenkins-deployer라는 ServiceAccount를 생성합니다. 그 다음 이 ServiceAccount에 production 네임스페이스의 deployment-manager Role을 바인딩합니다.

주목할 점은 ServiceAccount와 RoleBinding이 서로 다른 네임스페이스에 있다는 것입니다. 이렇게 하면 ci-cd 네임스페이스의 젠킨스가 production 네임스페이스에 배포할 수 있습니다.

마지막으로 파드 정의에서 serviceAccountName을 지정합니다. 이제 이 파드 안에서 실행되는 컨테이너는 jenkins-deployer의 권한으로 쿠버네티스 API에 접근할 수 있습니다.

실무에서 ServiceAccount는 정말 많이 사용됩니다. CI/CD 도구가 배포할 때, 모니터링 도구가 메트릭을 수집할 때, 로그 수집기가 파드 정보를 조회할 때 모두 ServiceAccount가 필요합니다.

Prometheus, Fluentd, ArgoCD 같은 도구들은 모두 자체 ServiceAccount를 사용합니다. 주의할 점이 있습니다.

default ServiceAccount에 과도한 권한을 주면 안 됩니다. 해당 네임스페이스의 모든 파드가 그 권한을 갖게 되기 때문입니다.

용도별로 별도의 ServiceAccount를 만들어 사용하는 것이 좋습니다. 김개발 씨가 말했습니다.

"아, 그러니까 젠킨스용 계정을 따로 만들고, 딱 배포에 필요한 권한만 주면 되는 거군요!"

실전 팁

💡 - 용도별로 전용 ServiceAccount를 만들어 사용하세요

• default ServiceAccount에는 최소한의 권한만 유지하세요

---

5. 최소 권한 원칙 적용

보안팀에서 감사가 나왔습니다. 김개발 씨의 ServiceAccount를 확인하던 보안 담당자가 미간을 찌푸렸습니다.

"이 계정이 왜 시크릿 전체를 읽을 수 있죠? 필요한 건 ConfigMap 뿐인데요." 최소 권한 원칙을 지키지 않아서 생긴 문제였습니다.

**최소 권한 원칙(Principle of Least Privilege)**은 필요한 최소한의 권한만 부여해야 한다는 보안 원칙입니다. 과도한 권한은 보안 사고 시 피해를 키웁니다.

마치 금고 열쇠를 모든 직원에게 주지 않는 것처럼, 쿠버네티스에서도 꼭 필요한 권한만 부여해야 합니다.

다음 코드를 살펴봅시다.

# 나쁜 예 - 과도한 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: too-permissive
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]            # 모든 것에 모든 권한 - 위험!

---
# 좋은 예 - 최소 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config", "db-config"]  # 특정 리소스만
  verbs: ["get"]          # 조회만 허용

---
# 리소스 이름까지 제한하는 세밀한 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: specific-pod-manager
rules:
- apiGroups: [""]
  resources: ["pods"]
  resourceNames: ["web-app", "api-server"]
  verbs: ["get", "delete"]

박시니어 씨가 진지한 표정으로 말했습니다. "보안에서 가장 중요한 원칙 중 하나가 최소 권한 원칙이에요.

줄여서 PoLP라고도 합니다." 왜 최소 권한이 중요할까요? 쉽게 비유하자면, 호텔을 생각해보세요.

투숙객에게는 자기 방 카드키만 줍니다. 만약 모든 투숙객에게 마스터키를 준다면 어떻게 될까요?

한 명이 카드키를 잃어버리면 전체 호텔이 위험해집니다. 쿠버네티스에서도 마찬가지입니다.

계정이 해킹당하거나 토큰이 유출되었을 때, 해당 계정의 권한이 작으면 피해도 작습니다. 모든 권한을 가진 계정이 유출되면 클러스터 전체가 위험해집니다.

위의 코드에서 나쁜 예를 보세요. apiGroups, resources, verbs에 모두 와일드카드(*)를 사용했습니다.

이것은 모든 API 그룹의 모든 리소스에 모든 동작을 허용한다는 뜻입니다. 절대로 이렇게 설정하면 안 됩니다.

좋은 예를 보겠습니다. configmap-reader Role은 ConfigMap만 읽을 수 있습니다.

더 나아가 resourceNames 필드로 특정 ConfigMap만 접근할 수 있도록 제한했습니다. app-config와 db-config라는 이름의 ConfigMap만 조회할 수 있습니다.

최소 권한을 적용하는 방법을 정리하겠습니다. 첫째, 와일드카드를 피하세요.

구체적인 리소스와 동작을 명시합니다. 둘째, 읽기만 필요하면 get과 list만 주세요.

create, update, delete는 정말 필요할 때만 추가합니다. 셋째, 가능하면 resourceNames로 특정 리소스만 접근하도록 제한하세요.

실무에서 적용하는 팁을 알려드리겠습니다. 처음에는 최소한의 권한으로 시작하세요.

권한이 부족하면 오류 메시지가 무엇이 필요한지 알려줍니다. 그때 필요한 권한만 추가하면 됩니다.

처음부터 넉넉하게 주고 줄이는 것보다 훨씬 안전합니다. 김개발 씨가 기존 Role을 수정하며 말했습니다.

"앞으로는 꼭 필요한 권한만 요청해야겠어요. 보안팀 감사 또 받기 싫거든요."

실전 팁

💡 - 와일드카드(*) 사용을 최대한 피하고, 필요한 권한을 명시적으로 나열하세요

• 권한이 부족하면 추가하고, 처음부터 과도하게 주지 마세요

---

6. kubeconfig 관리

김개발 씨가 새 노트북을 받았습니다. 클러스터에 접속하려면 kubeconfig 파일이 필요합니다.

그런데 선배가 자기 kubeconfig를 메신저로 보내주려고 합니다. 김개발 씨는 뭔가 이상하다는 느낌이 들었습니다.

과연 이 방법이 안전할까요?

kubeconfig는 쿠버네티스 클러스터에 접근하기 위한 설정 파일입니다. 클러스터 주소, 인증 정보, 컨텍스트 등이 포함되어 있습니다.

마치 회사 출입증과 같아서, 잃어버리거나 다른 사람과 공유하면 보안 문제가 생길 수 있습니다.

다음 코드를 살펴봅시다.

# kubeconfig 파일 구조 예시
apiVersion: v1
kind: Config
clusters:
- name: production
  cluster:
    server: https://k8s.example.com:6443
    certificate-authority-data: LS0tLS...  # 클러스터 CA 인증서
contexts:
- name: prod-context
  context:
    cluster: production
    user: kimdev
    namespace: development    # 기본 네임스페이스 설정
current-context: prod-context
users:
- name: kimdev
  user:
    token: eyJhbG...          # 인증 토큰 (민감 정보!)

# kubeconfig 관리 명령어
# 현재 컨텍스트 확인
kubectl config current-context

# 컨텍스트 목록 조회
kubectl config get-contexts

# 컨텍스트 전환
kubectl config use-context prod-context

박시니어 씨가 손사래를 쳤습니다. "제 kubeconfig를 공유하면 안 돼요!

그건 제 인증 정보가 들어있어요. 공유하면 제가 할 수 있는 모든 일을 할 수 있게 됩니다." kubeconfig 파일의 구조를 이해해봅시다.

kubeconfig는 세 가지 주요 섹션으로 구성됩니다. clusters는 접속할 클러스터 정보를 담고 있습니다.

서버 주소와 CA 인증서가 포함됩니다. users는 인증 정보를 담고 있습니다.

토큰, 클라이언트 인증서, 또는 외부 인증 명령어가 설정됩니다. contexts는 cluster와 user를 조합하여 접속 설정을 정의합니다.

쉽게 비유하자면, contexts는 즐겨찾기와 같습니다. "프로덕션 클러스터에 김개발 계정으로 접속"이라는 설정을 저장해두고, 필요할 때 바로 사용할 수 있습니다.

왜 kubeconfig 공유가 위험할까요? kubeconfig에는 인증 토큰이 포함되어 있습니다.

이 토큰은 해당 사용자로 클러스터에 접근할 수 있는 열쇠입니다. 만약 cluster-admin 권한을 가진 사용자의 kubeconfig가 유출되면, 공격자는 클러스터의 모든 것을 제어할 수 있습니다.

올바른 kubeconfig 관리 방법을 알아봅시다. 첫째, kubeconfig 파일은 ~/.kube/config 경로에 저장하고, 권한을 600으로 설정하세요.

본인만 읽고 쓸 수 있어야 합니다. 둘째, 절대로 다른 사람과 공유하지 마세요.

각 사용자는 자신만의 인증 정보를 가져야 합니다. 셋째, 버전 관리 시스템에 커밋하지 마세요.

.gitignore에 반드시 추가해야 합니다. 여러 클러스터를 관리할 때는 어떻게 할까요?

kubeconfig는 여러 클러스터와 컨텍스트를 하나의 파일에 담을 수 있습니다. kubectl config use-context 명령어로 쉽게 전환할 수 있습니다.

또는 KUBECONFIG 환경 변수로 여러 파일을 지정할 수도 있습니다. 김개발 씨가 물었습니다.

"그럼 저는 어떻게 kubeconfig를 받아야 하나요?" 박시니어 씨가 답했습니다. "인프라팀에 요청해서 본인 명의의 계정과 kubeconfig를 발급받으세요.

그게 정상적인 절차입니다." 신규 입사자에게 kubeconfig를 발급하는 올바른 프로세스가 있습니다. 인프라팀이 사용자 계정을 생성하고, 적절한 Role을 바인딩한 후, 해당 사용자만을 위한 kubeconfig를 안전한 채널로 전달합니다.

메신저나 이메일로 공유하는 것은 위험합니다.

실전 팁

💡 - kubeconfig 파일 권한을 chmod 600으로 설정하세요

• 여러 클러스터를 다룰 때는 컨텍스트를 활용하여 안전하게 전환하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!