해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 6 - Kubernetes RBAC with Ansible
1. RBAC 이란?
역할 기반 접근 제어 (Role-Based Access Control, RBAC)은, 쿠버네티스만의 기술이 아닌, 1970년대부터 시작된 오랫동안 검증된 컴퓨터 보안 개념이다.
핵심 아이디어는 '사용자' 개인이 아닌 '역할 (Role)'에 기반하여 권한을 부여하는 것이다.
- 핵심 원칙:
- 보안강화:
- 승인된 사용자만 특정 데이터나 기능에 접근하도록 제한
- 관리 단순화:
- 인원이 추가될때마다 권한을 개별적으로 주는 것이 아닌, '개발자' or '운영자' 같은 역할 하나만 부여하면 되므로, 관리가 편해짐.
- 최소 권한 원칙 (Principle of Least Privilege):
- 사용자에게 업무에 필요한 최소한의 권한만 부여하여, 실수나 계정 탈취로 인한 피해를 최소화
- 보안강화:
Verizon의 보고서에 따르면 데이터 유출의 82%가 사람의 실수와 관련이 있으며, 부적절한 권한 관리가 주된 원인 중 하나였다고 한다.
따라서, RBAC은 이러한 인적 오류로 인한 보안 사고를 예방하는 데 결정적인 역할을 하고 있다.
2. 쿠버네티스에서 RBAC
쿠버네티스는 버전 1.6부터 RBAC을 표준 인가 (Authorization) 방식으로 도입하였으며, 네가지 핵심 객체를 통해 작동한다.
추가적으로, RBAC은 선택적 기능이며, EKS나 AKS 등 Managed Cloud 제공업체의 배포판에는 해당 기능이 켜진 상태로 제공된다.
$ kubectl api-versions | grep rbac.authorization.k8s.io/v1해당 명령어를 통해, RBAC이 활성화되어있는지 확인할 수 있다.
만약 RBAC이 활성화되어있지 않다면 쿠버네티스 API 서버에서
$ kube-apiserver --authorization-mode=RBAC플래그를 사용하여 활성화할 수 있다.
1. Role (역할)
- 어떤 작업을 할 수 있는가에 대한 권한 목록
- ex ->"A 네임스페이스에 있는 Pod를 조회(get), 삭제(delete) 할 수 있다."
- 해당 역할은 특정 Namespace에 한정됨.
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: role-dev
rules:
- apiGroups: ["", "apps"]
resources: ["pods", "deployments"]
verbs: ["get", "list", "edit"]2. ClusterRole (클러스터 역할)
- Role과 기능은 동일하나, 클러스터 전체에 적용되는 권한
- 조회나 클러스터 전반의 설정을 변경하는 등의 강력한 권한을 정의할 때 사용
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-resource-reader
rules:
- apiGroups: [""] # 코어(core) API 그룹
resources: ["nodes", "persistentvolumes", "namespaces"]
verbs: ["get", "list", "watch"]3. RoleBinding (역할 연결)
- Role을 특정 사용자 (User), 그룹 (Group), 서비스 계정 (ServiceAccount)에 연결하는 역할
- Role과 동일하게 특정 네임스페이스 내에서만 유효함.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-rolebinding
namespace: default
subjects:
- kind: ServiceAccount
name: dev01
apiGroup: ""
roleRef:
kind: Role
name: role-dev
apiGroup: rbac.authorization.k8s.io
4. ClusterRoleBinding (클러스터 역할 연결)
- ClusterRole을 사용자나 그룹에 연결하여 클러스터 전반에 걸친 권한을 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-cluster-resources-binding
subjects:
- kind: User # 권한을 부여받을 주체의 종류 (User, Group, ServiceAccount 중 선택)
name: jane.doe@example.com # 권한을 부여받을 사용자의 이름
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-resource-reader # 연결할 ClusterRole의 이름
apiGroup: rbac.authorization.k8s.io3. 쿠버네티스 사용자 인증 과정
해당 강의에서는 사용자 인증과정의 예시로, kubectl apply 명령어 처리 과정에 대해서 설명한다.
1. 요청 접수 및 파싱
사용자가 kubectl apply 명령을 실행하면, 해당 요청이 클러스터의 API 서버로 제출됨.
- API 서버의 역할: 클러스터 관리의 중추적 역할 및 외부 요청을 받는 유일한 창구
- API 서버는 가장 먼저 수신된 요청을 파싱하여, YAML 파일의 형식이나 요청 구문이 올바른지 확인하는 작업 수행
2. 인증 (Authentication) 단계
구문 검사가 끝나면 API 서버는 요청을 보낸 주체의 신원을 확인하는 인증 절차를 시작함.
- 다양한 인증 방식 (클라이언트 인증서, 베어러 토큰, 프록시 사용)
- 인증 모듈 실행: 여러 인증 방법이 활성화된 경우, API 서버는 이들을 순서 보장 없이 실행하며, 하나의 모듈이라도 성공적으로 인증 완료시, 인증절차 즉시 종료
- 사용자 이름 식별: 클라이언트 인증서 방식의 경우, 쿠버네티스는 인증서의 주체 (Subject) 정보 내 공통이름 (Common name, CN) 필드 값을 사용자 이름으로 결정
3. 인가 (Authorization) 및 저장 단계
인증을 통해 사용자 이름이 식별되면, 다음으로 해당 사용자가 요청한 작업을 수행할 권한이 있는지 확인하는 인가 절차 실행함
- RBAC 시스템을 사용하여 해당 사용자에게 부여된 Role이나 ClusterRole에 해당 작업을 수행할 권한이 있는지 확인
- 인가까지 성공적으로 완료되면, API 서버는 요청된 Object의 상태를 etcd에 저장
- apply 명령의 모든 절차 완료
➕ TLS 클라이언트 인증서 발급 과정?
앞서 인증 (Authentication) 단계에서 설명한 다양한 인증 방식 중, '클라이언트 인증서' 방식의 자격 증명 발급 과정은 '인증서 서명 요청(Certificate Signing Request, CSR)'을 통해 이루어 진다.
1. Key 및 CSR 생성 : 사용자는 자신의 개인 키(private key)와 공개 키 및 신원 정보가 포함된 CSR을 생성
2. CSR 제출 : 생성된 CSR을 쿠버네티스 API에 제출
3. 검토 및 승인 : 관리자 또는 자동화된 시스템이 제출된 CSR을 검토하고 승인
4. CA 서명 : CSR이 승인되면, 쿠버네티스의 인증 기관(CA)이 해당 CSR에 서명하여 최종 인증서를 생성
5. 인증서 수신 : 사용자는 서명된 인증서를 쿠버네티스 API로부터 받아 자신의 kubeconfig에 설정하여 사용
4. Ansible, HashiCorp Vault
4-1. 앤서블 (Ansible)
Ansible은 복잡하고 반복적인 IT 작업을 자동으로 처리해주는 도구로, 서버에 소프트웨어를 설치하거나, 설정을 변경하거나, 어플리케이션을 배포하는 등의 일을 미리 작성된 YAML에 따라 수행하게 한다.
특징1 : Agentless
- 관리할 서버에 별도의 Agent를 설치할 필요 없이, SSH를 통해 명령을 내릴 수 있음
- 설치 및 관리가 매우 간편 및 관리 대상 시스템에 부담을 주지 않음.
특징2. 플레이북 (PlayBook)
- 작업할 내용을 YAML을 통해 원하는 상태로 자동관리할 수 있음.
즉, Ansible은 Agent 없이 SSH를 통해 작동하며, Playbook이라는 각본을 통해 IT인프라를 원하는 상태로 자동관리할 수 있는 자동화 도구이다.
4-2. HashiCorp Vault
HashiCorp Vault는 IT 환경의 민감한 Secret정보들을 안전하게 저장하고 관리하는 데 특화된 보안도구이다.
특징1. 중앙 집중식 Secret 관리
- 여러 설정 파일이나 코드에 흩어진 Secret을 Vault라는 하나의 안전한 장소에 모아 관리
- 모든 접근은 암호화되고, 상세한 감사 로그가 남아 보안 및 추적에 용이
특징2. 동적 Secret
- 필요할 때마다 짧은 시간만 유효한 임시 암호를 동적으로 생성해줌
- 임시 암호가 유출 되더라도, 유효시간이 짧아 공격자가 악용할 수 있는 시간이 제한되어 보안 수준을 높여줌.
즉, HashiCorp Vault는 암호나 API 키 와 같은 Secret을 암호화하여 중앙에서 안전하게 관리하며, 동적 시크릿을 만들어주는 보안도구이다.
