K8s의 계정의 용도 및 적용 원리에 대해서 알아봅시다.
k8s에는 서비스 계정과 유저 계정이 있습니다.
K8s Account
- Service Account
- 클러스터 내에서 실행되는 애플리케이션 또는 서비스와 관련 주로 클러스터 내의 리소스에 대한 접근 권한을 관리
- User Account
- 인증된 운영자 또는 개발자 등이 클러스터를 관리 및 작업을 수행하는데 사용
Role의 기본 개념
- 사용자 계정과 서비스 계정에 대한 권한 부여에 사용되며, 리소스에 대한 접근과 조작을 제어하는 데 중요한 역할을 합니다
- Cluster Role, Role이 존재합니다.
Role과 Cluster Role차이
- Role : 네임스페이스 내에서 리소스에 대한 액세스 권한 정의하는데 사용 (네임스페이스 단위)
- Cluster Role : 클러스터 전체에서 리소스에 대한 액세스 권한을 정의 모든 네임스페이스에 유효 (클러스터 단위)
Role의 우선순위
사용자가 직접 생성한 Role/ClusterRole > ClusterRole > Role
인증 단계
인증 → 인가 → 진입 제어 단계 필요
인증
- 어떤 사용자가 kubectl 명령어 사용시 kubeconfig파일에서 현재 사용자가 누군지 찾습니다
- 여러가지 인증 방법중 하나를 통해 인증을 합니다
- 인증 성공시 다음 단계
인가
- 클러스터내에서 명령을 수행할 권한이 있는지 Cluster Role, Role Binding을 통해 검사합니다
- 권한 확인시 성공
진입 제어
- 인증과 인가를 통과 요청은 사전 정의한 어드미션을 거쳐 최종 확인을합니다.
기본적으로 인증 및 인가까지가 쿠버네티스 인증 단계이며, 진입 제어는 별도의 webhook API를 구성하여 목적에 따라 보안 단계를 추가한 방식입니다.
Mutating Admission, Validating Admission의 주요 목적은 아래와 같습니다.
뮤테이팅 밸리데이팅 주요 목적
- 리소스의 초기화 또는 보안 설정
- 유효성 검사
- 정책 적용
참고 : https://happycloud-lee.tistory.com/259
사용 예시
서비스 계정의 사용 예시
-
마이크로서비스 간 통신: 서비스 계정은 클러스터 내의 여러 마이크로서비스 간에 안전한 통신을 수행하는 데 사용될 수 있습니다. 예를 들어, A 서비스가 B 서비스에 접근해야 하는 경우, A 서비스는 서비스 계정을 사용하여 B 서비스에 인증 및 권한 부여를 받고 API 호출을 통해 B 서비스와 상호 작용할 수 있습니다.
-
외부 리소스와의 통합: 클러스터 외부에 있는 리소스(예: 데이터베이스, 메시징 시스템 등)와 통합해야 할 때 서비스 계정을 사용할 수 있습니다. 서비스 계정은 외부 리소스에 접근하기 위한 인증 및 권한 부여에 사용될 수 있습니다.
사용자 계정의 사용 예시
-
클러스터 관리 및 작업: 사용자 계정은 클러스터 관리자나 개발자가 클러스터를 제어하고 작업을 수행하는 데 사용됩니다. kubectl과 같은 클라이언트 도구를 사용하여 사용자 계정을 인증하고 클러스터 리소스를 관리할 수 있습니다. 예를 들어, 사용자 계정을 사용하여 파드를 배포, 스케일링, 모니터링 및 디버깅하는 등의 작업을 수행할 수 있습니다.
-
권한 관리: 사용자 계정은 롤과 롤 바인딩을 사용하여 클러스터 리소스에 대한 권한을 관리하는 데 사용될 수 있습니다. 클러스터 관리자는 특정 사용자 계정에게 권한을 할당하여 특정 작업(예: 네임스페이스 관리, 리소스 생성 및 삭제 등)을 수행할 수 있도록 할 수 있습니다.
