Kubernetes 라는 새롭고 재미있는 Infra 환경에 계속해서 적응해가는 저와
제가 본 Kubernetes 환경, 최근 CKS 취득에 따른 + Security 에 대해 개인적인 느낌과 겪었던 이야기 입니다.
(요약)
우선 제가 경험한 2019~2022년도 초까지의 고객사 중 Kubernetes 관련 생각을 우선 공유드립니다.
---------------------------------------
7. Kubernetes 의 보안에 대해 생각해보다
현재 회사에선 Kubernetes 보안에 관해서 그렇게 쓸모있어 보이진 않아요. (성능모니터링 회사라..)
CKS 를 준비하며 Kubernetes 보안에 대해 다양한 생각을 한 듯 합니다.
지금껏 제가 지원하고 봐왔던 많은 고객사 환경에선.. 보안보다는 우선 동작하는데 더 관심을 가지고 있었던 듯 하네요.
- 하나의 bastion 을 통한 개발/검증/운영계에 kubectl 을 날릴 수 있는 환경
- 누구나 kubectl 로 명령을 날리며 role/rolebinding 에 대한 구분도 없고
- ConfigMap, Secret 을 수정하고 누가 했는지 추적도 안되는 상황
- 컨테이너/컨테이너 관리 환경에 대한 이해 부족
- '일단 Kubernetes 환경에서 서비스가 돌아가게 하자' 까지 인듯..
=> Kubernetes = 논리적인 IDC 센터, kubectl 명령으로 모든걸 날려버릴 수 있기에
보안과 통제 는 정말 중요하다고 생각합니다.
---------------------------------------
Kubernetes, CKS 등에 대한 우여곡절은 아래에 있습니다.
행복하세요~
(잡다구리 + 사족 + @..)
----------------------------------------------------------------------------
1. 장님 코키리 코를 만지다.
현재 회사(WhaTap) 에 애플리케이션 모니터링 필드 엔지니어로 입사하였고,
2018년도 하반기 고객사 차세대 프로젝트에서 처음으로 Kubernetes 환경을 접하게 되었답니다.
파드? 잉그레스? 가장 기억에 남는 단어 였어요.
전산경력과 맥락으로 찍어가며 기술지원을 했던 기억이 납니다.
=> 지금도 그렇지만, 프로젝트에서 kubernetes 를 컨트롤 하는 사람은 소수로 젊은친구가 거의 몰빵 수준이었어요.
다들 프로젝트 종료 후 잘(?) 이직을 하네요 ^^;
2. 나만의 코끼리를 그리다.
현재의 회사는 이익을 내는 스타트업이지만, 당시에는 적자로 위태위태한 회사였어요.
당연히 사람도 적었고, 해야할일과 고객사는 많았기에 지원은 언제나 바빴 답니다.
핸드폰에 메모해 놓은 'kubectl apply -f whatap_kube.yaml', 'kubectl edit pod master-agent -n whatap-monitoring' 를 고객사 지원시 보고 치던 시절이 생각나네요..
하지만 어느덧 경험이 쌓였고, 회사의 CNCF재단 KCSP 인증 목표에 맞춰 2020년도 8월 CKA 자격을 취득했습니다.
=> 현재 국내에는 20여개 회사가 KCSP 인증을 가지고 있지만, 당시에는 거의 없었어요.
현재 회사도 컨테이너 환경에서의 차별화를 어필하고 홍보를 하고자 KCSP 인증을 추진했습니다.
3. 내 코끼리 그림에 만족한 장님
CKA 취득 후에는 Kubernetes 관련 꽤 자신감을 가졌었어요.
당시 3시간 짜리 CKA 시험 을 1시간만에 다 풀었고, 90점 넘는 결과와 바로 CKAD 도 취득한 자신감? (자만감이었죠 ㅡㅡ;)
그해 12월 CKS 가 새로 나왔고, 자심감도 있었고 마침 Cyber Monday 세일이라 "그냥 시간날때 준비하면 되지!" 하며 등록 했답니다.
=> 그냥 자만감 이었어요. ;;
4. 코끼리 그림들은 쌓여가고..
당시 Kubernetes 환경 적용/전환을 망설이던 고객사들도 2021년이 되면서 너도나도 Kubernetes 가 포함된 아키텍처 (Cloud Native 포함)를 그렸습니다.
고객사를 지원하며 다양한 Public/Private Cloud 를 포함한 다양한 Kubernetes 환경을 경험하고, 통합 모니터링과 MSA 연계추적 관점의 설명과 지원을 했었네요.
=> Kubernetes 를 잘아는 사람도 있겠지만, 보통 작업자가 일부로 집중되어 있고, 익숙하지 않은 사람들도 많아 보였어요.
타사 엔지니어들도 예전의 저처럼 컨테이너 환경에 대한 이해가 부족하거나 트러블 슈팅이 안되는 상황을 종종 보게 됩니다.
또한, 차세대 프로젝트에는 Kubernetes + Istio +@ 등으로 최신 클라우드 네이티브한 아키텍처로 프로젝트를 띄워 레퍼런스를 만들고,
오픈 전/후 좋은(?) 곳으로 이직하는 사람들도 꽤 보았던듯 하네요.
또, 그 사람이 벌려놓고 떠난 뒤, 남은 불필요하게 복잡한 Kubernetes 환경을 처리하지 못해 상담하고 모니터링 솔루션 도입, 불필요한 환경 제거를 하는 고객사도 봤습니다.
5. 우여[곡절]
헛.. 2021년도 말.. 1년전 등록했놨던 CKS 시험의 유효기간 만료가 다가왔네요..
준비 1도 되지않았던 상황에서 시험항목에 대한 당황감과 그동안의 자만심에 대한 현타가 왔습니다.
회사일을 하며 나름 준비했지만, 결과는 실패였습니다.
=> 준비부족 + 여권 미지참 + 시험장 입장해서 화면공유 안됨 등.. 별 희한한 일들을 겪으며, 1차 시험과 retake 모두 실패하고, 자기 반성을 하게 되었네요 ^^;
(참고로, 화면 공유안돼서 시험을 못봤던 부분은 retake 를 다시 줍니다.)
6. [우여]곡절
전산에 대해선 나름 프라이드가 있었기에 "이걸 실패해?" 라는 생각과 아쉬운 마음에 재등록을 하였고 (사장님 감사합니다 m(_.,_)m )
차분히 준비한 후 CKS 를 취득했습니다.
=> 전산/IT는 중/고딩때부터 관심, 대학시절 학과/동아리, 8번의 다양한 전산관련 다양한 업종/직업에서 얻어온 경험/자신감 이 저에게 커다란 재산인 듯 합니다.
7. Kubernetes 의 보안에 대해 생각해보다
현재 회사에선 Kubernetes 보안에 관해서 그렇게 쓸모있어 보이진 않아요. (성능모니터링 회사라..)
CKS 를 준비하며 Kubernetes 보안에 대해 다양한 생각을 한 듯 합니다.
지금껏 제가 지원하고 봐왔던 많은 고객사 환경에선.. 보안보다는 우선 동작하는데 더 관심을 가지고 있었던 듯 하네요.
- 하나의 bastion 을 통한 개발/검증/운영계에 kubectl 을 날릴 수 있는 환경
- 누구나 kubectl 로 명령을 날리며 role/rolebinding 에 대한 구분도 없고
- ConfigMap, Secret 을 수정하고 누가 했는지 추적도 안되는 상황
- 컨테이너/컨테이너 관리 환경에 대한 이해 부족
- '일단 Kubernetes 환경에서 서비스가 돌아가게 하자' 까지 인듯..
=> Kubernetes = 논리적인 IDC 센터, kubectl 명령으로 모든걸 날려버릴 수 있기에
보안과 통제 는 정말 중요하다고 생각합니다.
8. Kubernetes 에서의 보안 포인트
제가 공부하며 느꼈던 개인적인 관점에서 흐름을 적어 봤습니다.
1) 저장/요청관련 : etcd - kube-apiserver - kubelet
=> 위 3개가 주요 플로우 입니다. api 기반으로 통신하며, 정보를 저장하고 명령을 수행하고 있어요.
etcd/kube-apiserver로 다이렉트 호출을 통한 정보 취득 도 가능하기에 인증/인가/포트오픈 등 제어가 필요합니다.
당연히 kubernetes cluster 내에서도 마찬가지에요.
이에 apiserver 에는 다양한 Auditing 과 제어기능이 들어가야 합니다.
2) 물리/서버관련 : workernode - pod - container - image - docker build
=> 컨테이너는 하나의 물리머신에 복수개가 떠서 동작하는 구조입니다.
이때, Host 머신 내 공통의 공간이 존재하게 되며, 이를 접근하면 다른 컨테이너에 대한 정보도 취득 할 수 있게 됩니다.
이에 Immutable 이란 개념과 Image 를 만들때, 컨테이너의 실행계정과 privillage, 시스템콜 제어, 컨테이너 내부 동작, 사용하는 이미지의 태그, 중요정보의 노출 등에 대한 생각과 제어, 감시가 필요합니다.
3) 네트워크관련 : networkpolicy / pod - ep - svc - ing
파드, 서비스 및 외부에서의 요청이 pod 까지 들어오는 과정에서 불필요한 엑세스를 제한해야 합니다.
4) 권한관리관련 : (cluster)role/(cluster)rolebinding
=> rbac 기반으로 권한 분리 및 관리가 필요합니다.
# 현재 자체 전산실 및 IDC 센터를 사용하고 있는 경우
기본적으로 터미널에 엑세스를 제어하고, root 계정에 대한 권한관리, 리소스 및 볼륨마운트 관리, 운영자/작업자 관리 등의 보안/운영체계를 가지고 있습니다.
kubernetes 가 되며, 이 모든게 kubectl 명령으로 가능한 상황이라..
당연히 전산실/IDC 센터 이상의 관리/통제가 필요해 보입니다. ^^;;
'Kubernetes' 카테고리의 다른 글
| Kubernetes.. Iceberg.. (0) | 2022.07.26 |
|---|---|
| KodeKloud - CKS Challenge.. May.. Winner.. Thanks.. ^^ (0) | 2022.05.24 |
| KodeKloud : CKS (Certified Kubernetes Security Specialist) - Challenge 4 (0) | 2022.05.08 |
| Secret Env Variable in Container? (0) | 2022.05.02 |
| KodeKloud : CKS (Certified Kubernetes Security Specialist) - Challenge3 (0) | 2022.05.01 |