nginx 는 기본적으로, 설정 파일에 대한 재기동을 운영중에 지원한다. 이는 nginx 의 이벤트 처리 방식 때문이다.
k8s 에서 nginx.conf 를 운영 하는 방식으로, 2대 이상의 workernode 에 서로 같은 nginx.conf 를 처리 해야 하고 이미지 내의 nginx.conf 를 수정하는 것은 이상한 운영방식일 것이므로 configmap 의 사용이 추천될 수 있다.
문제는 팟 기동시 /etc/nginx 디렉토리 내에 어떻게 /etc/nginx/nginx.conf 를 위치 시킬 것인가이다.
configmap mount 는 기본적인 directory mount 와 subpath 를 이용한 파일의 명확한 위치 마운트를 제공한다. 그러나. k8s configmap 은 기본적으로 자동 reload 되나 특정 경로에 주입하기 위해 subpath 를 쓰면 spec 상으로 reload 되지 않는다.
Dockerfile
RUN ln -s /etc/nginx/configmap/nginx.conf /etc/nginx/nginx.conf
그래서 container image 안에 symbolic link 를 미리 만들어 두는 기법을 사용했는데 작동하기에 괜찮다.
그런데 괜한 노력이었다는 느낌이 든다.
어차피 configmap 조차도 소스 레벨로 관리 되어야 하고, immutable image 와 gitops 의 철학을 기준으로 생각해보면 실시간 수정이 “가능한” 설정이 좋은 운영 방법은 아니라 할 수 있다.
결국 subpath 를 쓰는 것이 단점은 아니라는 얘기가 될 수 있으며, 실시간 수정이 (reloading) 가능한 변칙적인 설정/구성을 애써서 할 필요는 없다는 결론에 이르게 되었다.
kubespace 는 통합관리화면을 통해서 k8s 멀티 클라우드 보안 취약점을 스캐닝하고 RBAC 설정을 시각화 하며, 컨테이너 이미지를 스캐닝한다. kubescape 는 k8s 클러스터와 yaml 파일과 HELM charts 를 다양한 보안 프레임워크를 이용해서 잘못 설정된 부분을 검사하며 s/w 취약점, ci/cd 파이프라인 초기단계의 RBAC 오류, 위험점수를 즉시 계산하며 위험추세도 보여줍니다. k8s 에서 가장 빠르게 성장하는 툴이며 개발자에게 친숙한 CLI, 유연한 포멧, 자동 스케닝 기능을 제공하여 k8s 사용자들에게 시간,노력을 아끼게 해줍니다. kubescape 는 jenkins, circleCI, github workflows, Prometheus, slack 과 같은 DevOps 툴들과 통합되며 EKS, GKE, AKS 와 같은 다중 클라우드 k8s 배포를 지원합니다.
보안 등의 이슈로 k8s worker node는 항상 최신 버전으로 업그레이드 되어야 하며, 가끔은 VM 그 자체를 리붓해야 하는 경우가 생긴다. (정기 PM 등의 목적)
kured
kured 는 k8s reboot daemon 으로 helm 으로 쉽게 설치하여 daemonset 으로 구동시킬 수 있다. (모든 노드에서 동작하도록 하기 위해)
다양한 설정을 통해 리붓이 필요한 상태인 VM 을 스케쥴에 맞추어 리붓이 가능하도록 도와준다. (기본적으로 60분에 한번씩 체크한다) apt update 등을 진행할 때 linux 가 스스로 reboot 이 필요한 상태임을 알리는 mark file (/var/run/reboot-required) 이 생성되는 데 kured는 host 파일을 모니터링하여 지정된 시간에 리붓을 할 수 있다. daemonset 으로 설치하는 이유가 이것 때문이겠다. 모든 node가 동시에 리붓되면 안되니까.
쿠버네티스는 강력한 s/w 배포 플랫폼이다. 유연성이 높아 어떤 유즈케이스도 이루어 낼 수 있다. fortune 500 기업중 절반이 k8s 를 도입한 이유! Dimensional Research and VMware 연구 ( https://k8s.vmware.com/state-of-kubernetes-2020/ ) 에 따르면 k8s 도입 증가율은 폭발적이다.
그러나 모든 툴들이 그렇듯. 강력함과 보안은 서로 상충한다. 수백만의 다양한 방식의 k8s 설정으로 실행중인데 99%는 위험하다. 보안과점, 효율적인 관점, 그리고 신뢰도 측면에서 쉽게 설명 가능하다. 간혹 YAML 설정의 일부를 누락하기 때문에
이 이슈에 대응하기 위해, 커뮤니티는 k8s 워크로드를 설정하는 best practice 를 생각해 냇다. 이 가이드라인은 항상 따라야 하고 따르지 않을 이유가 없다. Fairwinds’ Polaris project 는 이것들을 돕고 강제하기 위해 만들어졌다.
위의 예제는 또한 Liveness 와 Readness Probe 설정이 누락되엇다. 이 설정들은 k8s 가 어플리케이션이 요청을 받아들일 준비가 되어 있는지를 확인하는 방법에 대한 것이다. LivenessProbe 가 없다면, k8s 는 어플리케이션이 응답을 안 할 때 자동 회복하지 않을 것이다. ReadnessProbe 설정이 없다면 pods 이 완전히 제대로 기동 되었는지의 여부를 알 수 없다.
Liveness 와 Readiness Probes 는 어플리케이션 동장에 대한 지식이 있어야 한다. 그러나 특정한 HTTP endpoint 를 호출해 보거나 unix command 를 실행하는 것만으로 적절히 동작하는지를 테스트 해볼 수 있다.
많은 k8s 워크로드 설정은 기본적으로 보안 없이 설정된다. 어플리케이션이 필요할 지도 아닐지도 모르는 권한을 부여할 지도 모른다. 예를 들어 모든 컨테이너는 root 파일시스템을 수정할 수 있는 권한을 기본적으로 가진다. 이것은 공격자가 시스템의 바이너리를 수정하거나 설정을 수정할 수 있다
Polaris 는 위의 내용을 포함해서 더 많은 것들을 검사한다. 2021년 5월 기준 24가지의 종류를 체크하고 여러 커뮤니티의 피드백으로 검사 종류가 더 추가되고 있다.
각각의 체크는 JSON 스키마로 작성되었다. kubectl 명령 실행시마다 동작한다. 가장 간단한 예제는 아래와 같다.
successMessage: Host network is not configured
failureMessage: Host network should not be configured
category: Security
target: Pod
schema:
'$schema': http://json-schema.org/draft-07/schema
type: object
properties:
hostNetwork:
not:
const: true
JSON 스키마와 Go 템플릿으로 꽤 복잡한 문법을 체크한다. the Polaris documentation 를 읽어보면 커스텀 Polaris checks 를 직접 만들 수도 있다. 이것은 당신의 조직의 내부 정책을 구현하여 best practice 를 강제하는데 도움이 될 것이다.
Polaris configuration 을 설정하고 나면 (기본 설정도 꽤 괜찮다.) Polaris 는 3가지 모드로 작동한다.
Dashboard – 클러스터내의 어떤 리소스가 개선되어야 하는지
Admission Controller – 문제가 많은 리소스는 클러스터에 배포 되는 것을 방지
CI/CD – 체크인 되기 전에 코드로서의 인프라 검사
자신있는 배포
k8s 는 강력하며, 강력함에는 큰 책임감도 따른다. 따라서 k8s 배포전에 best practice 를 따르는 것은 중요하다. 설정을 소홀히 하면 보안 결함과, 운영의 문제와, 클라우드인 경우에는 비용이 과다지출 될 수도 있다.
CI/CD 과정에, Admission Control 로서 또는 수정적으로 확인할 Dashboard 역할로 Polaris 를 당신의 workflow 에 넣게되면, 자신있게 위험수위를 체크하는데 도움이 될 것이다. 그리고 poliris 를 cluster 전반에서 활용하고자 할 때 Trivy 와 같은 이미지 스캐닝 도구나 Goldilocks 와 같은 메모리/ cpu 설정의 적정 사이즈를 제시하는 툴과 같은 역할을 하는 도구를 같이 써도 좋고 k8s 의 audinting 과 정책을 강제 하는 Fairwinds Insights 도 알아보라
너가 k8s 전문가일수도 있고 처음 클러스터를 설계할 수도 있을텐데 일종의 가드레일을 준비해야 한다. Fairwind 사의 Polaris 와 Insights 는 좋은 출발점이다.
CKAD, CKA 에 이어 CKS 도 pass 했습니다. CKS는 kubernetes 환경에서 OS 부터 시작해서 POD 레벨 container 레벨 docker image 레벨까지 각각의 요소의 취약점을 파악하는 방법을 알아보고 어떤 문제가 있으며 어떻게 해결하면 좋은지 그리고 자동화된 분석도구를 사용해 보도록 가이드 합니다.
무엇을 알게되는가?
CKS 를 취득하면서 배우면 k8s 를 도입하면 각 영역마다 어떤 부분을 체크해야 하는지 어떤 부분이 보안상 취약할 수 있는지를 전체적으로 바라보고 가이드 할 수 있는 역량을 취득할 수 있습니다.
kube-bench, trivy 등으로 각node 와 container image 취약점을 자동 스케닝 하고 Dockerfile 과 kubernetes yaml 파일을 직접 (manually) 점검하는 방법도 익혀야 합니다. 또한 RBAC 을 통한 세부적인 권한 관리와 audit log 를 설정하여 이상 징후를 감지하고 찾아내는 방법도 익힐 수 있습니다.
해킹과 방어, 창과 방패의 싸움에서 해킹은 점점 강해지고 방어하는 기술도 점점 진화해야 합니다. 한순간에 익힌 보안 기술이 전부가 아니겠습니다. CKAD와 CKA 는 3년의 자격 유지가 인정되는 반면 CKS 는 2년의 자격 유지가 인정됩니다. 2년 후에는 새로운 보안 기술을 익혀야 하며, 2년이 지난 보안 기술은 자격자로 인정하기 어렵다는 뜻이겠습니다.
공부 방법과 걸린 시간 간단한 소회
CKAD, CKA 를 공부하게 되면 기본적으로 kubernetes document 를 검색하고 사용하는 방법 yaml 작성 능력과 vim 사용능력을 키우게 되므로 회사 생활과 병행하며 CKS자격을 취득하는 대는 약 한 달의 시간이 소요되었던 것 같습니다. 주말에는 아내가 공부하는 시간을 많이 배려해 주었습니다.
udemy 강의를 구독하여 1차례 수강 후 강사가 제공하는 killer.sh 에서 각 챕터별 실습을 하였고 시험 결제를 하면 총 2회의 모의고사 (같은 문제) 를 풀 수 있습니다. 처음에는 40점이 나왔으나 그냥 꾸준히 틀린 문제를 반복하여 100점에 나올 때 까지 session reset (문제를 풀고 있는 VM 을 초기화) 을 통해 각 문제에서 모른 부분은 더이상 없도록 할 때까지 반복해서 풀었습니다. 이 때 애매한 개념들이 많이 해소 되었습니다.
시험에는 gviser 설정, trivy 돌려보기, docker 및 pod 취약점 있을 만한 것 찾기, pod security policy 구성, RBAC role / clusterrole binding, OPA, CKA 에 자주 등장한 network policy, ETCD를 이용한 secret 찾기 base64 decode 하기 등
공부했던 거의 모든 부분이 출제 되었습니다. 특히 kube-apiserver 취약 설정 찾아내서 고치는 부분의 경우 manifest 의 pod이 재시작 되고 항상 잘 기동되길 바라는 마음을 가져야 했습니다.
docker 가 아닌 crictl 로 구동 되기에 watch -n 0.5 crictl ps 명령을 자주 사용 하여 kube-apiserver 가 재기동 되는 순간을 알아낼 수 있었습니다. 지금에서야 느끼는데 kube-apiserver 가 죽는데는 거의 10~15 초가 걸리고, 되살아나는대는 2~3초 밖에 안 걸린다는 점입니다. udemy 강사는 4~5 초만에 재기동 되는 것 같은데.. 시험보는 VM 서버는 사양이 좋지 않은 모양입니다. 그래서 manifest 를 수정 후, watch -n 0.5 crictl ps 를 치면서 그야말로 그냥 기다리는 시간은 좀 아깝다고 느껴졌습니다. (그래서 다음 문제를 먼저 살펴보기도 했습니다.)
시험 보는 중에 trivy 나 gviser 문제에서 해당 document 는 탭으로 하나 더 열어도 된다 라는 내용을 보고 k8s document 외에 2개의 탭을 더 열게 되었는데 감독관이 10분 후쯤에 화면을 잠구더니 그러지 말라 해서 그냥 알겠다고 하고 닫았더니 문제는 없었습니다. 그러니까…. 10분 정도는 감독관이 못 본 것 같고 실시간 감시도 아닌 것 같습니다.
만약 시험이 떨어지게 되면, 거의 비슷한 출제 내용으로 1번 공짜로 볼 수 있습니다. 그래서 자격증만을 위해서 시험을 치루는 경우라면 어서빨리 시험을 보고, 패턴을 익혀서 한주 후 쯤에 또 치루는 것도 방법일 수는 있겠습니다.
마치며
digital badges 를 모으는게 새로운 취미가 된 것 같은데 다음 자격증으로는 elastic search 사의 자격증을 따보려고 합니다. 업무상 kibana 를 많이 사용하는데 로그를 검색 하는 것이 아닌 분석하는 사람이 되고 싶습니다.
