Cloud Native Computing Foundation(CNCF)는 리눅스 재단 소속의 비영리 단체입니다. 클라우드가 발전하면서 클라우드 네이티브 기술 스택별로 다양한 기술 역시 빠르게 발전하기 시작했고, 각자의 방향으로 발산하는 기술들을 관리할 필요가 생겼습니다. 이를 해결하기 위해 2015년 7월 CNCF가 발표되었고, Kubernetes를 시작으로 클라우드 네이티브 컴퓨팅 환경에서 필요한 다양한 프로젝트를 추진하고 관리하고 있습니다.

클라우드 네이티브(Cloud Native)란?

클라우드 네이티브가 뭐야? 라고 물어보면 저만 그런지 모르겠지만 바로 답이 나오기가 쉽지 않습니다. 이번 기회에 간단히 짚고 넘어가보겠습니다.

Cloud Native Computing Foundation(CNCF)에서 클라우드 네이티브와 관련된 여러 개념을 아주 잘 정의하고 있으니 참고해보세요. (참고 - https://glossary.cncf.io/)

클라우드 네이티브는 클라우드 컴퓨팅 환경에서 제공되는 분산 컴퓨팅을 활용하여 애플리케이션을 구축, 배포 및 관리할 때의 접근 방식입니다.

클라우드 네이티브 애플리케이션 은 클라우드 네이티브 접근 방식으로 구축된 애플리케이션을 말합니다. 클라우드가 제공하는 확장성, 탄력성, 복원성, 유연성을 활용하도록 설계 및 구축합니다.

클라우드 네이티브 기술 은 클라우드 네이티브 애플리케이션을 구축하는데 사용되는 기술들을 말합니다.

이 기술들을 통해 조직은 퍼블릭, 프라이빗, 하이브리드 클라우드와 같은 현대적이고 역동적인 환경에서 확장 가능한 애플리케이션을 구축하고 실행하는 동시에 클라우드 컴퓨팅의 이점을 최대한 활용할 수 있습니다.

containers, service meshes, microservices 가 대표적인 클라우드 네이티브 기술에 해당합니다.

클라우드 네이티브 보안 은 클라우드 네이티브 애플리케이션에 보안을 구축하는 접근 방식을 말합니다.

클라우드 네이티브 보안 영역은 개발단계부터 production까지 전체 애플리케이션 수명주기(lifecycle)를 포함합니다.

클라우드 네이티브 보안은 기존 보안 모델과 동일한 표준을 유지하는 동시에 클라우드 네이티브 환경의 특수성 — 빠른 코드 변경 및 highly ephemeral(일시적인) 인프라 — 에 적합한 보안을 구축하는 것을 목표로 합니다.

클라우드 네이티브 보안과 4C 모델

출처 - https://kubernetes.io/ko/docs/concepts/security/overview/

클라우드 네이티브의 보안은 4개의 계층으로 설명합니다.

•

클라우드(Cloud)

•

클러스터(Cluster)

•

컨테이너(Container)

•

코드(Code)

클라우드 (Cloud)

클라우드 계층은 가장 바깥에 위치한 계층으로 4개의 보안 계층에서 가장 기본이 됩니다. (Trusted Computing Base)

만약 클라우드 계층이 취약하거나 취약한 방식으로 구성된 경우 이 기반 위에서 구축된 구성 요소(k8s Cluster)의 안전을 보장할 수 없게 됩니다.

클라우드 공급자 보안

클라우드 계층의 보안은 공급자와 소비자의 공동의 책임이 있기 때문에, 각 클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 위한 보안 권장 사항을 제시하고, 소비자는 권장 사항을 구성하고 보호해야 합니다.

•

클라우드 계층은 Public/Private 클라우드, 온프레미스와 관계없이 서버 인프라를 지칭

•

클라우드 공급자는 해당 환경에서 워크로드를 안전하게 실행하기 위한 보안 권장 사항을 제시

IaaS 공급자	링크
Amazon Web Services	https://aws.amazon.com/security
Google Cloud Platform	https://cloud.google.com/security
Microsoft Azure	https://docs.microsoft.com/en-us/azure/security/azure-security

인프라스트럭처 보안

쿠버네티스 공식 문서에서는 특히 쿠버네티스 클러스터에서 인프라 보안을 위한 제안을 다음과 같이 제시하고 있습니다.

쿠버네티스 인프라에서 고려할 영역	추천
API 서버에 대한 네트워크 접근(컨트롤 플레인)	쿠버네티스 컨트롤 플레인에 대한 모든 접근은 인터넷에서 공개적으로 허용되지 않으며 클러스터 관리에 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록에 의해 제어된다.
노드에 대한 네트워크 접근(노드)	지정된 포트의 컨트롤 플레인에서 만 (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다.
클라우드 공급자 API에 대한 쿠버네티스 접근	각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 최소 권한의 원칙을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. Kops 설명서는 IAM 정책 및 역할에 대한 정보를 제공한다.
etcd에 대한 접근	etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 etcd 문서에서 확인할 수 있다.
etcd 암호화	가능한 한 모든 스토리지를 암호화하는 것이 좋은 방법이며, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.

클러스터 (Cluster)

쿠버네티스의 클러스터 보안은 쿠버네티스 구성요소로 이루어지는 보안 요소들이 대부분입니다. 클러스터 계층 보안에는 두 가지 영역이 존재하며 가장 많은 보안적 고려 요소가 존재합니다.

•

설정 가능한 클러스터 컴포넌트의 보안

•

클러스터에서 실행되는 애플리케이션의 보안

클러스터의 컴포넌트

우발적이거나 악의적인 접근으로부터 클러스터를 보호할 수 있도록 클러스터 자체의 보안 설정입니다.

이 설정은 다양하며, 쿠버네티스의 경우 큰 분류로 몇가지를 나열하면 다음과 같습니다.

•

Kubernetes API에 대한 접근 제어

•

Kubelet에 대한 접근 제어

•

런타임 및 워크로드의 capabilities 제어

•

클러스터 구성 요소에 대한 보안

이에 대한 모범 사례에 대한 정보 확인하려면 클러스터 보안 가이드를 참고하세요.

클러스터 내 컴포넌트 (Application)

아래는 쿠버네티스에서 실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 가이드입니다.

워크로드 보안에서 고려할 영역	추천
RBAC 인증(쿠버네티스 API에 대한 접근)	https://kubernetes.io/docs/reference/access-authn-authz/rbac/
인증	https://kubernetes.io/ko/docs/concepts/security/controlling-access/
애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등)	https://kubernetes.io/ko/docs/concepts/configuration/secret/https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
파드가 파드 시큐리티 폴리시를 만족하는지 확인하기	https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
서비스 품질(및 클러스터 리소스 관리)	https://kubernetes.io/ko/docs/tasks/configure-pod-container/quality-service-pod/
네트워크 정책	https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
쿠버네티스 인그레스를 위한 TLS	https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls

컨테이너 (Container)

컨테이너 계층의 보안은 쿠버네티스의 경우 쿠버네티스가 사용하는 컨테이너 런타임과 주로 관계가 있습니다. 주로 컨테이너 런타임의 보안 수준 & 이미지의 신뢰성에 따라 보안 상태가 달라지게 됩니다.

컨테이너 계층은 쿠버네티스 보안과는 직접적인 관련은 없지만 클라우드 네이티브 보안에서 컨테이너 계층의 일반적인 보안 권장 사항은 다음과 같습니다.

컨테이너에서 고려할 영역	추천
컨테이너 취약점 스캔 및 OS에 종속적인 보안	이미지 빌드 단계의 일부로 컨테이너에 알려진 취약점이 있는지 검사해야 한다.
이미지 서명 및 시행	컨테이너 이미지에 서명하여 컨테이너의 내용에 대한 신뢰 시스템을 유지한다.
권한있는 사용자의 비허용	컨테이너를 구성할 때 컨테이너의 목적을 수행하는데 필요한 최소 권한을 가진 사용자를 컨테이너 내에 만드는 방법에 대해서는 설명서를 참조한다.
더 강력한 격리로 컨테이너 런타임 사용	더 강력한 격리를 제공하는 컨테이너 런타임 클래스를 선택한다.

코드 (Code)

코드 계층은 4C 모델에서 가장 안쪽에 위치하는 계층입니다.

말 그대로 컨테이너에서 실행되는 실제 코드를 말하며, 다른 상위 3개 계층에 비해 두드러지는 차이점은 개발자가 대부분의 책임과 권한을 갖고 있는 계층이라는 점입니다.

코드 계층은 사실 업데이트 빈도가 가장 높지만, 가장 보안적 검토가 잘 이루어지지 않는 부분이기도하며, 코드는 외부 인터넷과 직접 연결하기 때문에 공격당할 위험이 높은 편에 속합니다.

컨테이너와 마찬가지로 코드 계층 역시 쿠버네티스 보안과 직접적인 관련은 없으며 클라우드 네이티브 보안에 공통적으로 고려해야할 부분입니다.

애플리케이션 코드를 보호하기 위한 권장 사항은 다음과 같습니다.

코드에서 고려할 영역	추천
TLS를 통한 접근	코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 실행하는 mTLS(상호 TLS 인증)를 통해 수행할 수 있다.
통신 포트 범위 제한	이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다.
타사 종속성 보안	애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다.
정적 코드 분석	대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools
동적 탐지 공격	잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 여기에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시이다.

마치며

이 포스팅에서는 클라우드 네이티브에 대한 개념과 클라우드 네이티브 보안, 그리고 4C 모델(Cloud-Cluster-Container-Code)에 대해 알아보았습니다.

쿠버네티스 공식 문서의 보안 가이드 내용을 대부분 옮겨온 것이지만, 한 번 정리하는 것과 아닌 것과의 차이는 크니까요.

꼭 쿠버네티스 클러스터 환경이 아니더라도 보안 구성은 아키텍처의 성숙도/완성도를 결정짓는 중요한 요소 중 하나입니다.

또한 건강한 개발 문화와 변화의 속도를 따라잡기 위해서는 보안적인 측면에 대해서도 지속적인 관심과 평가가 필요하기도 합니다.

저 역시 회사에서 운영 중인 쿠버네티스 클러스터가 어느정도 궤도에 접어들었고, 여러가지 측면으로 보안을 구성하기 위한 작업을 진행 중에 있습니다.

다음 포스팅에서는 보안을 위해 실제로 적용한 내용 중, 위에 소개한 4개의 보안 계층 중 Cluster 계층, 특히 Admission Controller에 대해서 포스팅하겠습니다.