패스트캠퍼스 환급챌린지 8일차 : Kubernetes 자격증 마스터 클래스 : CKA/CKAD/CKS 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.(https://bit.ly/4hTSJNB)

---

공부 인증

시작 시각, 종료 시각, 강의장 목록, 강의 화면

---

공부 후기

 

API 인증의 형태

1) role based access control(rbac) : 쿠버네티스의 인증 방식

2) attribute based access control(abac)

 

API 인증이란? API 서버에 접근하기 위해서는 인증 작업이 필요하다.

 

User 인증

0) username + 인증서 자격 요건 충족: 나 그 인증서를 갖고 있는 유저야. : ~/.kube/config

1) 인증: 너 그 유저가 맞니? ↔ 반려

2) 권한: 그 유저가 맞다면 권한도 있어? ↔ 반려

3) 제한된 작업을 요청하는 건 아니지? ↔ 반려

4) 적절하다면 요청 승인!

*1~3이 단계별 API 인증 과정이다.

 

Service Account 인증

0) 모든 동작되는 Pod는 Service Account를 갖고 있다. 보통의 Pod는 따로 권한을 요하지는 않는데, 모니터링 툴과 같은 대시보드, 프로메테우스 등은 리소스에 대한 접근 권한을 요구한다.

 

Role&Role Binding: User 또는 Service Account가 권한이 있는지 정의해주는 것. 

1) Role: 어떤 API를 이용할 수 있는지 사용 권한을 정의

- rules: verbs: create, get, list, update, patch, delete, deletecollection

2) RoleBinding: 사용자/그룹 또는 Service Account와 role을 연결

3) RoleBinding(특정 유저의 본인 namespace만 role 가능)과 ClusterRoleBinding(자+타 namespace에서 role 가능)이 존재한다.

 

오늘 공부를 하고 나서 첫날과 둘째날에 발생한 에러 원인에 대해 한층 더 이해할 수 있었다.

에러 문구가 API 관련 에러였고 공식페이지나 구글링을 통해 해결 방법을 찾아보면 항상 ~/.kube/config를 다시 한 번 살펴보라는 글들이 많았다. 위에 오늘 공부 내용을 정리했다싶이 User 인증 부분에 "0) username + 인증서 자격 요건 충족: 나 그 인증서를 갖고 있는 유저야. : ~/.kube/config" 내용이 있다. config 파일을 현재 유저에 맞게 왜 갱신하라는 것인지 오늘 이유를 알게 되었다. 또한 실제 원인이었던 인증서 만료 또한 User 인증 과정에 대해 공부하면서 왜 필요했고, 만료가 되면 왜 다시 갱신을 해주어야 하는지에 대해 자세하게 알게 되었다.