쿠버네티스는 지금도 발전하고 있습니다. 쿠버네티스 API 서버의 버전별 용량 변화 <출처: 바이라인 네트워크, 클라우드 네이티브의 현재와 미래> 이러한 발전 과정 가운데 v1.30에서 CEL(Common Expression Language)을 바탕으로 Admission Control을 할 수 있는 기능이 GA(General Availability) 되었습니다. 쿠버네티스의 기능은 알파, 베타, 그리고 GA 단계를 거쳐 출시됩니다. 각 단계를 간단히 설명하면 다음과 같습니다.알파: 버그가 있을 수 있으며, 갑자기 중단될 수 있습니다. 간단한 테스트 목적으로만 사용할 것을 권고합니다.베타: 코드가 잘 테스트되며, 갑자기 중단되지 않습니다. 프로덕션 사용을 권고하진 않으나, 추후 바뀔 수 있습니다.GA: 프로덕션 사용이 가능하며, 일반적으로 기능을 제외하지 않습니다.*각 단계를 더 자세히 알고 싶다면 링크를 참고하세요. 그러므로 이번에 GA된 CEL 기반 기능은 실제 업무에도 사용할 만큼 성숙했다고 볼 수 있습니다. 그럼 이제부터 쿠버네티스 보안 정책을 어떻게 적용할 수 있는지 알아보겠습니다. 진행 순서는 다음과 같습니다. CEL에 대한 이해Admission Control이란?실제 적용 예제쿠버네티스의 보안 정책에 대한 향후 전망 CEL에 대한 이해 CEL은 굉장히 간결하게, 개발자가 표현하고자 하는 내용을 담을 수 있도록 설계되어 있습니다. 좀 더 손쉬운 이해를 위해 예제를 살펴보도록 하겠습니다. CEL-SPEC <출처: CEL-SPEC 깃허브> 코드 하단을 보겠습니다.// Object construction 즉, 오브젝트의 구조를 보고 읽어들일 수 있습니다. YAML에 가깝게 표현하자면 다음과 같습니다. 이렇게 구조화된 데이터를 읽은 값을 기반으로 // Condition에 넣어서 판단합니다. 결과값은 매우 간결하게 True 또는 False, 이진으로 출력할 수 있습니다. 이러한 간결함을 쿠버네티스에 녹여내면 손쉽게 보안 정책을 적용할지 말지 결정할 수 있습니다. 예를 들어 파드(pod)의 hostNetwork 사용 부분을 검출하기 위해서 다음과 같이 사용할 수 있습니다. 코드 중간의 || 는 or의 역할을 담당합니다. 이를 기준으로 앞(!has(object.spec.hostNetwork))과 뒤(object.spec.hostNetwork != true)는 모두 동일한 목적으로 쓰입니다. 다만 앞에서 존재를 체크하고, 뒤에서는 구체적인 조건을 표현하는 편입니다. 물론 hostNetwork의 경우에는 값이 True와 False 2개 밖에 존재하지 않아 하나만 써도 충분하긴 합니다. 이렇게 hostNetowrk 사용 부분을 검출하고 난 다음, 어떻게 보안 정책을 적용하게 되는 걸까요? 사실 이 작업은 이미 오래 전부터 존재했었습니다. Admission Control이라는 기능으로 말이죠.*CEL이 쿠버네티스 적용되는 과정에 대한 Change History를 알고 싶다면 링크를 참고하세요. Admission Control이란?Admission Control은 지난 2019년도 쿠버네티스 공식 블로그에 공개된 내용입니다. Admission이라고 불리는 Mutating admission과 Validating admission이 보안 정책을 담당했습니다. 하지만 당시에는 웹훅을 통해서만 지원이 되었으며, 이를 구현하기 위해 추가로 CRD를 설치하는 OPA나 Kyverno와 같은 프로젝트가 나왔습니다. 쿠버네티스 Admission Controller 가이드 <출처: 쿠버네티스 블로그> 이를 쿠버네티스에 직접 녹여내기 위한 요구 사항들이 있었고, v1.23부터 이를 구현하고자 하는 노력이 있었습니다. 결국 v1.30부터 Validating에 대한 구현과 적용이 완료된 것입니다. v1.30에서는 이에 멈추지 않고 Mutating에 대한 구현을 추가로 시작했습니다. 이를 그래프로 표현하면 다음과 같습니다. Admission 관련 API에 대한 버전별 성숙도 <출처: 작가> 그럼 실제 적용 예제를 살펴보기 전, 각 Admission에 대해서 살펴보겠습니다. Validating Admission Policy일종의 체크리스트라고 볼 수 있습니다. 예를 들어 ‘object.spec.hostNetwork != true’ 같은 내용은 오브젝트의 스펙에 있는 hostNetwork가 true가 아니라면, okay(true) 처리됩니다. 반대 경우는 false이겠죠. 이를 통해 validation, 즉, 검증을 할 수 있습니다. Mutating Admission Policy 일종의 사전(강제) 조치라고 볼 수 있습니다. NK 세포 혹은 면역 세포로 봐도 매우 유사할 듯합니다. 문제가 생기는 부분을 찾아 조치한다는 점에서 그러합니다. 이 부분은 구현 이전이므로, Kyverno의 예제를 살펴보겠습니다. `- (image): "*:latest" imagePullPolicy: "IfNotPresent"` 만약 이미지에 최신(latest) 태그가 붙어 있다면, 이미지를 내려받는 정책(imagePullPolicy)이 현재 존재하지 않을 때만(ifNotPresent) 하는 것이 가장 좋을 것입니다. 이 Admission으로 해당 규칙을 강제로 주입(변경)시키는 것입니다. 실제 적용 예제 실제 예제를 보며 이 부분이 어떻게 동작하는지 살펴보겠습니다. 현재 테스트는 바닐라 쿠버네티스 또는 특별한 변경이 없는 배포 판을 기준으로 만들어 졌습니다. 따라서 환경에 따라 이와 같이 동작하지 않을 수 있습니다. 환경 구성에 관련해서는 링크를 참고하면 좋습니다. 또한, 쿠버네티스 v1.30 이상 환경에서 테스트할 수 있으므로 버전을 확인하기 바랍니다. 1. 코드를 내려받고, 실습 파일이 있는 곳으로 이동실습 코드를 바로 사용할 수 있도록 구성된 것허브 소스를 내려받습니다. 그 후에 실습을 진행할 B/B.009로 이동합니다. 2. 실습 디렉터리 구조 확인B.009에는 다양한 실습 소스가 있습니다. 네이티브 k8s(Admission Policy 바로 사용 가능)외에 OPA와 Kyverno 모두 비교할 수 있는 소스가 준비되어 있습니다. 우리는 그중 k8s_native-{{CEL}} 디렉터리로 이동해, 해당 디렉터리의 내용을 확인합니다. 3. hostNetwork 제한 정책 파일 확인hostNetwork를 제한할 목적으로 작성된 CEL-ValidatingAdmissionPolicy-NoHostNetwork.yaml 파일의 내용은 아래와 같습니다. RBAC와 아주 유사한 형태로 구조화되어 있으며, vadalidations 이하 expression 항목에 앞서 설명한 내용들이 있음을 알 수 있습니다. 4. hostNetwork 제한 설정을 실제로 적용1.CEL-ValidatingAdmissionPolicy-NoHostNetwork.yaml을 실제로 적용하고, 결과를 확인합니다. 5. hostNetwork 적용 가능 여부 확인hostNetwork 설정이 포함되어 있는 샘플 앱을 배포해 보고, validating 관련 admission이 적용되는지 확인합니다. 곧이어 ../sample-apps/hostNetwork로 이동하며 해당 디렉터리의 내용을 확인합니다. yes는 hostNetwork가 포함되어 있는 yaml 파일입니다. 반면 no는 hostNetwork가 포함되어 있지 않은 yaml 파일입니다. 각 yaml 파일을 적용해 보고 admission의 동작 여부를 확인할 수 있습니다. 6. 배포 내용 모두 삭제마지막 조치입니다. admission policy는 클러스터에 영향을 주는 설정이므로, 이를 테스트하기 위해 배포했던 모든 내용을 삭제합니다. 실습에 활용한 B.009에는 다양한 항목을 모두 스크립트로 정리해 두었습니다. 필요에 따라 다른 보안 정책 도구도 사용하며 비교해 보는 것을 추천합니다. 마치며: 쿠버네티스 보안 정책에 대한 전망 쿠버네티스는 CEL을 활용해 우선 Validation에 대한 Admission Control을 강화했습니다. 그리고, 2025년 내에 아마 Mutation 부분 또한 완결지을 것으로 예측됩니다. 물론 그렇다고 기존의 보안 정책을 담당했던 OPA와 Kyverno가 당장 쓸모 없어지는 것은 아닙니다. 웹훅을 기반으로 하는 경우에는 꾸준히 필요할 것이며, Mutation 역시 아직 구현 중이기 때문입니다. 따라서 시간을 두고 조직에 따라 천천히 보안 정책 구성을 변경할 것을 추천합니다. 네이티브 쿠버네티스, OPA(Gatekeeper), Kyverno 비교 <출처: 작가> 쿠버네티스는 CEL 이외에도 필요한 것은 내재화하고, 벤더 중립성을 지키기 위한 코드는 제거하는 등 꾸준히 개선하며 발전하고 있습니다. 그런 만큼 가급적 최신 버전에 맞추어 사용하는 것이 가장 빠르게 현재 기술에 적합한 쿠버네티스를 사용하는 방법이라고 할 수 있겠습니다. *이번 글에서 소개한 내용을 바탕으로 KubeCon India 2024에서 발표하기도 했습니다. 다음 링크에 발표 소개와 영상이 공개되니 살펴보는 것도 좋을 것 같습니다. 작가조훈(CNCF 앰버서더)시스템/네트워크 IT 벤더의 경험 이후, 메가존 GCP 클라우드 팀에서 쿠버네티스와 연관된 모든 프로젝트에 대한 Tech Advisor 및 Container Architecture Design을 제공하고 있다. 페이스북 ‘IT 인프라 엔지니어 그룹’의 운영진을 맡고 있으며, 오픈 소스 컨트리뷰터로도 활동한다. 지식 공유를 위해 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하기도 한다. 책 <컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커> 등 3권을 썼다. CNCF(Cloud Native Computing Foundation) 앰버서더로서 쿠버네티스 생태계가 더 활발하게 퍼질 수 있도록 기여하고 있다. 심근우LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다. 문성주 체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다. 이성민미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다. 요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
