[Day13] Certified Kubernetes Administrator (CKA) with Practice Tests

153강. KubeConfig

개념) 쿠버네티스 클러스터에 접속하기 위한 설정, 인증서 정보를 저장하고 있는 파일

 

if) kubeconfig가 없을 경우 매번 긴 명령어를 사용하여 접근해야함 

kubectl get pod --server my-k8s:6443 --client-key admin.key --client-certificate admin.crt --certificate-authority ca.crt

kubeconfig 파일은 $HOME/.kube/config에 있음

kubeconfig 구조 

• clusters: 접속할 클러스터의 주소 정보 (Developent, Production, Google)
• contexts: 어떤 유저가 어떤 클러스터에 접속할지 정의한 정보 (user과 cluster를 연결)
• users: 클러스터에 접속할 유저 정보 (Admin, Dev User, Prod User)

Kubeconfig 내용 확인

kubectl config view

기본 경로에 위치한 config가 아닌 경우

kubectl config view --kubeconfig=[경로] 

클러스터 목록 확인

kubectl config get -clusters

Context 목록 확인

kubectl config get -contexts

현재 Context 확인

kubectl config current -contexts

Context 변경

kubectl config use -contexts [contexts]

 

157강.API Groups

API Groups (metrics, healthz, version, api, apis, logs)

=> cluster functionality 

kube proxy kubectl proxy는 다름

kube proxy- pod와 service 연결 

kubectl proxy- kube api server와 연결 

 

158강. Authorization 

사용자, 그룹, 서비스 어카운트 요청이 쿠버네티스에서 처리되기 위해서는 

인증 => 인가 => 진입 제어

• 인증된 사용자가 해당 기능을 실행할 수 있는 권한이 있는지 체크하는 기능
• 쿠버네티스 클러스터의 API 에 접근하기 위해서 유효한 사용자인지 인증을 거쳐야함. 
• 인증이 됐으면, 그 사용자가 접근하려고 하는 API에 권한이 있는지 확인이 된 다음 API 사용. 
• cf) Authentication_인증은 사용자가 누구인지를 식별하는 것. 예) 로그인

<Node authorizer>

실행되도록 스케줄된 pod에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드 

 

ABAC -> Attribute-based access control configurations

속성을 함께 결합하는 정책을 사용하여 사용자에게 액세스 권한을 부여하는 액세스 제어 패러다임 

API에 외부 접근 

-> managing하기 힘듦 

 

RBAC-> Role-based Access Control 

쿠버네티스 환경에서 Node 또는 네트워크 리소스 등 여러가지 접근 권한에 대한 Role 관리하는 작업 요소 

-> managing/수정하기 쉬웅

 

Webhook

HTTP 콜백 (어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림)

Open policy agen -> third-party tool -> admission control & authorization

-> response를 받고 user는 access 승인을 받음

 

만약 설정하지 않으면, default 값이 alwaysallow로 설정

 

159강. Role Based Access Controls

API 접근 확인

Kubectl 은 API 인증계층을 신속하게 쿼리하기 위한 하위 명령어 : auth can-i 

 

1. Role definition file 을 API Version set과 함께 생성

-> kubectl creates -f developer-role.yaml

2. API Group, resource, work 3가지 section in rule

3. roll binding 생성 (역할: user object과 role을 연결)

-> kubectl create -f devuser-developer-binding.yaml

 

role 확인

-> kubectl get roles

rolebinding 확인

-> kubectl get rolebindings

role developer 확인

-> kubectl describe role developer

 

162강. Cluster Roles and Role Bindings

RoleBinding은 User, Team 단위의 권한 부여 기능 (EX) POD-read)

ClusterRoleBinding은 클러스터 단위의 권한 부여 기능을 나타냄

 

Namespaced Cluster scope에 있는 항목들이 다름

Namespaced 

-> kubectl api-resources --namespaced=true

Cluster Scoped (Clusterroles)

-> kubectl api-resources --namespaced=false

 

 

 

 

 

참조:

https://velog.io/@_zero_/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-kubeconfig-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%84%A4%EC%A0%95

쿠버네티스 kubeconfig 개념 및 설정

https://happycloud-lee.tistory.com/259

[쿠버네티스 쉽게 이해하기 14] 인증Authentication과 알백RBAC 방식의 인가Authorization

https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/