2021.10.07

기고 | '클라우드에서의 쿠버네티스 보호하기'··· 뮌헨재보험 아키텍트가 깨달은 교훈

Karl-Heinz Prommer | InfoWorld
클라우드와 쿠버네티스의 잠재력을 십분 활용하려는 기업은 ‘코드로서의 인프라스트럭처’(IaC), ‘코드로서의 보안’(SaC), 자동화에 주목할 필요가 있다. 

글로벌 재보험 기업 ‘뮌헨재보험’(Munich Re)은 최근까지 전통적인 구내 인프라를 활용했다. 전 세계에 분산되어 있는 여러 이질적인 데이터센터에서 자체 하드웨어를 이용하고 있었다. 하지만 우리는 이 인프라로 인해 더욱 신속한 애플리케이션 개발과 더 빠른 디지털 제품 및 서비스 제공을 필요로 하는 이니셔티브 중 일부를 지연시킬 수 있다는 점을 깨달았다.

그래서 자동화 수준을 높이고 복잡성을 낮추며 날렵하고 민첩한 운영을 줄이기 위해 새로운 클라우드 인프라와 새로운 배치 프로세스를 추구하게 되었다. 아울러 보안도 최우선순위 고려사항이 될 수밖에 없었다. 우리의 중요한 워크로드 중 일부를 하나의 거대한 네트워크에서 인프라로 이동하면서 우리는 새로운 환경을 잠재적인 위협으로부터 지속적으로 보호할 수 있도록 해야 했다.
 
Gerd Altmann (CC0)

클라우드, 오픈소스, 쿠버네티스(Kubernetes) 선택하기
뮌헨재보험 아키텍처팀의 목표는 리소스를 궁극적으로 다른 팀이 책임질 작은 네트워크 배치를 구축하는 것이었다. 이 조력자 역할에서 우리는 팀들이 신속한 혁신적인 애플리케이션 배치를 달성하고 시장에 신속하게 진출할 수 있는 인프라 기반을 제공해야 했다.

우리 회사는 마이크로소프트 제품을 사용하기 때문에 마이크로소프트 애저(Azure)에서 새로운 클라우드 인프라를 구축하고자 했다. 우리의 다음 선택은 마이크로서비스 기반 애플리케이션으로 이동하는 것이었으며 자동화 그리고 IaC(Infrastructure as Code)와 SaC(Security as Code)의 가능성에 주목했다.

우리의 보안 책임자들은 처음에 오픈소스 솔루션을 경계했지만 클라우드 도구를 검토하면서 현존하는 최고의 옵션이 모두 오픈소스라는 사실을 알게 되었다(개인적으로 오픈소스에 대한 보안 우려는 해묵은 선입견이라고 생각한다. 강력한 커뮤니티가 뒷받침되는 탄탄한 기술은 최소한 전매특허 솔루션만큼은 안전하다). 

우리의 클라우드 인프라가 지원할 프로젝트의 예산도 고려해야 했기 때문에 전매특허 라이선스 비용과 록인(Lock-in)을 피할 수밖에 없었다. 그래서 우리는 오픈소스를 선택할 수밖에 없었다. 

회사의 마이크로서비스 인프라를 조율하기 위해 우리 팀은 쿠버네티스를 사용해 보고 싶었다. 하지만 우리의 첫 번째 프로젝트에는 쿠버네티스가 혜성같이 등장하기 전까지 인기가 있었던 옵션인 도커 스웜(Docker Swarm)이 존재했다. 우리는 도커 스웜을 사용하여 프로젝트를 완료하고 같은 작업에 쿠버네티스를 투입하는 실험을 진행할 수 있도록 준비했다. 

이 비교를 통해 쿠버네티스도 우리의 요구에 맞는 선택이라는 것이 입증되었다. 그리고 우리는 이후의 모든 프로젝트에 쿠버네티스를 사용했다.

애저에 있는 쿠버네티스 클러스터 아키텍처
우리가 배치하는 쿠버네티스 클러스터는 실제 URL을 사용하여 액세스할 수 있으며 보안 인증서로 보호된다. 이를 달성하기 위해 우리의 애저 기반 아키텍처에는 프로젝트에 속한 로드 밸런서(Load Balancer)와 DNS 구역, 키볼트(KeyVault, 애저 보안 비밀번호 스토어), 애저 네이티브 객체 스토어를 사용하는 스토리지 등이 포함되어 있다. 

우리의 아키텍처에는 클러스터 안에 있고 애저로 모두 처리하는 제어 영역도 포함되어 있다. 이런 각 구성요소에 대한 외부적인 액세스는 전통적인 방화벽에 의해 보호되고 특정 화이트리스트 IP 주소에 대한 액세스만 허용한다(기본적으로 자체 네트워크에 대한 액세스만 허용된다).

우리가 새 프로젝트를 시작하기 위해 사용하는 부스터 프레임워크는 쿠버네티스 클러스터 안에서 여러 개의 구성 요소를 구현한다. 진입 컨트롤러가 프로젝트 마이크로서비스 등 클러스터 안에 배치된 리소스에 대한 외부 액세스를 개방한다. 

여기에는 모든 진입 시 애저 AD(Azure AD)의 승인을 받도록 하는 O오스(OAuth) 프록시가 포함되어 있다. 외부 DNS 서버는 DNS 구역 안에서 DNS 서비스를 생성한다. 우리의 비밀번호 컨트롤러는 애저 키 볼트(Azure Key Vault)로부터 비밀번호를 가지고 온다(이 정보는 클러스터에 보관하지 않아야 하며 클러스터를 파괴해야 하는 경우 분실해서는 안 된다). S3 API가 데이터 스토리지 리소스와 통신한다. 인증서 관리자는 TLS 액세스를 위해 특수 인증서를 생성하며, 우리의 경우 렛츠 인크립트(Let’s Encrypt)를 무료로 사용한다.

또한 우리는 모니터링, 로깅, 추적용 도구를 사용한다. 모니터링을 위해 프로메테우스(Prometheus)와 그라파나(Grafana) 등의 산업 표준을 사용한다. 로깅은 그라파나 로키(Grafana Loki)를 사용한다. 추적은 예거(Jaeger)를 사용한다. 또한 우리는 쿠버네티스 배치를 위한 선택적 개선사항인 링커드(Linkerd)를 우리의 보호 서비스 메시로 도입했다.

쿠버네티스 보안 가시성 및 자동화
쿠버네티스 전용 보안 솔루션은 반드시 필요하다. 여기에서 우리는 E2E(End to End) 애플리케이션 가시성 및 자동화된 취약성 관리를 위한 쿠버네티스 네이티브 컨테이너 보안 플랫폼으로 뉴벡터(NeuVector)를 사용한다.

우리가 처음으로 클라우드에서의 보안에 대한 접근방식을 고려했을 때, 취약성 스캔과 애플리케이션 워크로도 보호를 위한 도구가 최후의 방어선으로 파악됐다. 가장 중요한 것은 올바르게 적용하는 것이었다. 쿠버네티스 클러스터는 진입 및 진출 노출과 해당 환경 안에서 확대되는 공격망을 통한 공격에 직면할 수 있다.

애플리케이션 개발과 배치를 보호하기 위해 구축 단계부터 생산까지 CI/CD 파이프라인의 모든 단계에서 치명적인 취약성 또는 잘못된 구성(그래서 이름이 뉴벡터인 것이다.)을 지속적으로 스캔해야 한다. 애플리케이션을 컨테이너 익스플로잇 공격, 제로데이 공격, 내부자 위협으로부터 보호해야 한다. 쿠버네티스 자체도 공격 표적이며 최근 중대한 취약성이 공개됐다.

효과적인 쿠버네티스 보안 도구는 쿠버네티스 환경 내에서의 모든 연결을 시각화하고 그 안전을 자동으로 검증하며 모든 예상치 못한 활동을 차단할 수 있어야 한다. 또한 쿠버네티스 환경 안에서 예상되는 통신을 화이트리스트 처리하기 위한 정책을 정의하고 비정상적인 활동을 확인 또는 차단할 수 있어야 한다. 이런 실행 시간 보호를 통해 공격자가 쿠버네티스 환경에 침입하여 악의적인 프로세스를 시작하더라도 그 프로세스가 아수라장을 만들기 전에 즉시 자동으로 차단된다.

IaC의 중요성
우리의 쿠버네티스 배치는 IaC를 활용한다. 따라서 상기 아키텍처의 모든 구성 요소를 단순한 YAML 파일을 사용하여 생성하고 재생성 할 수 있다. IaC는 프로젝트에 클러스터 전반에 걸쳐 필수적인 일관성과 재현성을 가능하게 한다. 

예를 들어, 어떤 이유로 클러스터를 파괴해야 하는 경우 또는 변화를 추구하고 싶은 경우 클러스터를 파괴하고 변경사항을 적용한 후 다시 배치할 수 있다. IaC는 여러 개의 같은 설정을 사용하며 단순한 값 변경으로 완성할 수 있는 개발 및 생산 클러스터 구축을 시작할 때도 유용하다.

IaC를 통해 클러스터에 적용된 모든 변경사항을 감사할 수 있다. 인간은 모두 오류와 잘못된 구성을 자행하기가 너무 쉽다. 그래서 우리에게 자동화가 있는 것이다. 자동화를 통해 안전한 배치를 재현할 수 있다.

SaC의 중요성
같은 이유로 자동화 및 SaC도 쿠버네티스 보안 보호 구성에 필수적이다. 선택한 쿠버네티스 보안 도구를 통해 클러스터에 YAML 파일로 업로드한 객체인 CRD(Custom Resource Definition)를 활용하여 보안 정책을 손쉽게 구현하고 관리할 수 있어야 한다. 

IaC가 인프라의 일관성과 신뢰성을 확보하듯이 SaC는 복잡한 방화벽과 보안 서비스를 올바르게 구현하도록 한다. 보안 보호를 코드로 도입하고 재현하는 기능은 오류를 없애고 효과성을 크게 높인다.

다음 단계
쿠버네티스 인프라의 미래를 위해 우리는 프레임워크 배치를 위해 깃옵스(GitOps)를 도입하고 잠재적인 배치 에이전트로 플럭스(Flux)를 도입할 방침이다. 또한 게이트키퍼(Gatekeeper)를 사용하여 OPA(Open Policy Agent)와 쿠버네티스를 통합하여 승인된 컨테이너 생성, 권한 컨테이너 등에 대한 정책 관리를 제공할 계획이다.

클라우드와 쿠버네티스의 잠재력을 연구하기 시작한 조직에서는 자동화 및 IaC와 SaC 구현과 관련하여 여기에서 언급한 것과 유사한 아키텍처 및 보안 선택을 조사하는 것을 강력 추천한다. 그러면 쿠버네티스를 성공적으로 활용하고 여러 장점을 누릴 수 있을 것이다.

* 기고자 Karl-Heinz Prommer는 뮌헨재보험의 테크니컬 아키텍트다. ciokr@idg.co.kr



2021.10.07

기고 | '클라우드에서의 쿠버네티스 보호하기'··· 뮌헨재보험 아키텍트가 깨달은 교훈

Karl-Heinz Prommer | InfoWorld
클라우드와 쿠버네티스의 잠재력을 십분 활용하려는 기업은 ‘코드로서의 인프라스트럭처’(IaC), ‘코드로서의 보안’(SaC), 자동화에 주목할 필요가 있다. 

글로벌 재보험 기업 ‘뮌헨재보험’(Munich Re)은 최근까지 전통적인 구내 인프라를 활용했다. 전 세계에 분산되어 있는 여러 이질적인 데이터센터에서 자체 하드웨어를 이용하고 있었다. 하지만 우리는 이 인프라로 인해 더욱 신속한 애플리케이션 개발과 더 빠른 디지털 제품 및 서비스 제공을 필요로 하는 이니셔티브 중 일부를 지연시킬 수 있다는 점을 깨달았다.

그래서 자동화 수준을 높이고 복잡성을 낮추며 날렵하고 민첩한 운영을 줄이기 위해 새로운 클라우드 인프라와 새로운 배치 프로세스를 추구하게 되었다. 아울러 보안도 최우선순위 고려사항이 될 수밖에 없었다. 우리의 중요한 워크로드 중 일부를 하나의 거대한 네트워크에서 인프라로 이동하면서 우리는 새로운 환경을 잠재적인 위협으로부터 지속적으로 보호할 수 있도록 해야 했다.
 
Gerd Altmann (CC0)

클라우드, 오픈소스, 쿠버네티스(Kubernetes) 선택하기
뮌헨재보험 아키텍처팀의 목표는 리소스를 궁극적으로 다른 팀이 책임질 작은 네트워크 배치를 구축하는 것이었다. 이 조력자 역할에서 우리는 팀들이 신속한 혁신적인 애플리케이션 배치를 달성하고 시장에 신속하게 진출할 수 있는 인프라 기반을 제공해야 했다.

우리 회사는 마이크로소프트 제품을 사용하기 때문에 마이크로소프트 애저(Azure)에서 새로운 클라우드 인프라를 구축하고자 했다. 우리의 다음 선택은 마이크로서비스 기반 애플리케이션으로 이동하는 것이었으며 자동화 그리고 IaC(Infrastructure as Code)와 SaC(Security as Code)의 가능성에 주목했다.

우리의 보안 책임자들은 처음에 오픈소스 솔루션을 경계했지만 클라우드 도구를 검토하면서 현존하는 최고의 옵션이 모두 오픈소스라는 사실을 알게 되었다(개인적으로 오픈소스에 대한 보안 우려는 해묵은 선입견이라고 생각한다. 강력한 커뮤니티가 뒷받침되는 탄탄한 기술은 최소한 전매특허 솔루션만큼은 안전하다). 

우리의 클라우드 인프라가 지원할 프로젝트의 예산도 고려해야 했기 때문에 전매특허 라이선스 비용과 록인(Lock-in)을 피할 수밖에 없었다. 그래서 우리는 오픈소스를 선택할 수밖에 없었다. 

회사의 마이크로서비스 인프라를 조율하기 위해 우리 팀은 쿠버네티스를 사용해 보고 싶었다. 하지만 우리의 첫 번째 프로젝트에는 쿠버네티스가 혜성같이 등장하기 전까지 인기가 있었던 옵션인 도커 스웜(Docker Swarm)이 존재했다. 우리는 도커 스웜을 사용하여 프로젝트를 완료하고 같은 작업에 쿠버네티스를 투입하는 실험을 진행할 수 있도록 준비했다. 

이 비교를 통해 쿠버네티스도 우리의 요구에 맞는 선택이라는 것이 입증되었다. 그리고 우리는 이후의 모든 프로젝트에 쿠버네티스를 사용했다.

애저에 있는 쿠버네티스 클러스터 아키텍처
우리가 배치하는 쿠버네티스 클러스터는 실제 URL을 사용하여 액세스할 수 있으며 보안 인증서로 보호된다. 이를 달성하기 위해 우리의 애저 기반 아키텍처에는 프로젝트에 속한 로드 밸런서(Load Balancer)와 DNS 구역, 키볼트(KeyVault, 애저 보안 비밀번호 스토어), 애저 네이티브 객체 스토어를 사용하는 스토리지 등이 포함되어 있다. 

우리의 아키텍처에는 클러스터 안에 있고 애저로 모두 처리하는 제어 영역도 포함되어 있다. 이런 각 구성요소에 대한 외부적인 액세스는 전통적인 방화벽에 의해 보호되고 특정 화이트리스트 IP 주소에 대한 액세스만 허용한다(기본적으로 자체 네트워크에 대한 액세스만 허용된다).

우리가 새 프로젝트를 시작하기 위해 사용하는 부스터 프레임워크는 쿠버네티스 클러스터 안에서 여러 개의 구성 요소를 구현한다. 진입 컨트롤러가 프로젝트 마이크로서비스 등 클러스터 안에 배치된 리소스에 대한 외부 액세스를 개방한다. 

여기에는 모든 진입 시 애저 AD(Azure AD)의 승인을 받도록 하는 O오스(OAuth) 프록시가 포함되어 있다. 외부 DNS 서버는 DNS 구역 안에서 DNS 서비스를 생성한다. 우리의 비밀번호 컨트롤러는 애저 키 볼트(Azure Key Vault)로부터 비밀번호를 가지고 온다(이 정보는 클러스터에 보관하지 않아야 하며 클러스터를 파괴해야 하는 경우 분실해서는 안 된다). S3 API가 데이터 스토리지 리소스와 통신한다. 인증서 관리자는 TLS 액세스를 위해 특수 인증서를 생성하며, 우리의 경우 렛츠 인크립트(Let’s Encrypt)를 무료로 사용한다.

또한 우리는 모니터링, 로깅, 추적용 도구를 사용한다. 모니터링을 위해 프로메테우스(Prometheus)와 그라파나(Grafana) 등의 산업 표준을 사용한다. 로깅은 그라파나 로키(Grafana Loki)를 사용한다. 추적은 예거(Jaeger)를 사용한다. 또한 우리는 쿠버네티스 배치를 위한 선택적 개선사항인 링커드(Linkerd)를 우리의 보호 서비스 메시로 도입했다.

쿠버네티스 보안 가시성 및 자동화
쿠버네티스 전용 보안 솔루션은 반드시 필요하다. 여기에서 우리는 E2E(End to End) 애플리케이션 가시성 및 자동화된 취약성 관리를 위한 쿠버네티스 네이티브 컨테이너 보안 플랫폼으로 뉴벡터(NeuVector)를 사용한다.

우리가 처음으로 클라우드에서의 보안에 대한 접근방식을 고려했을 때, 취약성 스캔과 애플리케이션 워크로도 보호를 위한 도구가 최후의 방어선으로 파악됐다. 가장 중요한 것은 올바르게 적용하는 것이었다. 쿠버네티스 클러스터는 진입 및 진출 노출과 해당 환경 안에서 확대되는 공격망을 통한 공격에 직면할 수 있다.

애플리케이션 개발과 배치를 보호하기 위해 구축 단계부터 생산까지 CI/CD 파이프라인의 모든 단계에서 치명적인 취약성 또는 잘못된 구성(그래서 이름이 뉴벡터인 것이다.)을 지속적으로 스캔해야 한다. 애플리케이션을 컨테이너 익스플로잇 공격, 제로데이 공격, 내부자 위협으로부터 보호해야 한다. 쿠버네티스 자체도 공격 표적이며 최근 중대한 취약성이 공개됐다.

효과적인 쿠버네티스 보안 도구는 쿠버네티스 환경 내에서의 모든 연결을 시각화하고 그 안전을 자동으로 검증하며 모든 예상치 못한 활동을 차단할 수 있어야 한다. 또한 쿠버네티스 환경 안에서 예상되는 통신을 화이트리스트 처리하기 위한 정책을 정의하고 비정상적인 활동을 확인 또는 차단할 수 있어야 한다. 이런 실행 시간 보호를 통해 공격자가 쿠버네티스 환경에 침입하여 악의적인 프로세스를 시작하더라도 그 프로세스가 아수라장을 만들기 전에 즉시 자동으로 차단된다.

IaC의 중요성
우리의 쿠버네티스 배치는 IaC를 활용한다. 따라서 상기 아키텍처의 모든 구성 요소를 단순한 YAML 파일을 사용하여 생성하고 재생성 할 수 있다. IaC는 프로젝트에 클러스터 전반에 걸쳐 필수적인 일관성과 재현성을 가능하게 한다. 

예를 들어, 어떤 이유로 클러스터를 파괴해야 하는 경우 또는 변화를 추구하고 싶은 경우 클러스터를 파괴하고 변경사항을 적용한 후 다시 배치할 수 있다. IaC는 여러 개의 같은 설정을 사용하며 단순한 값 변경으로 완성할 수 있는 개발 및 생산 클러스터 구축을 시작할 때도 유용하다.

IaC를 통해 클러스터에 적용된 모든 변경사항을 감사할 수 있다. 인간은 모두 오류와 잘못된 구성을 자행하기가 너무 쉽다. 그래서 우리에게 자동화가 있는 것이다. 자동화를 통해 안전한 배치를 재현할 수 있다.

SaC의 중요성
같은 이유로 자동화 및 SaC도 쿠버네티스 보안 보호 구성에 필수적이다. 선택한 쿠버네티스 보안 도구를 통해 클러스터에 YAML 파일로 업로드한 객체인 CRD(Custom Resource Definition)를 활용하여 보안 정책을 손쉽게 구현하고 관리할 수 있어야 한다. 

IaC가 인프라의 일관성과 신뢰성을 확보하듯이 SaC는 복잡한 방화벽과 보안 서비스를 올바르게 구현하도록 한다. 보안 보호를 코드로 도입하고 재현하는 기능은 오류를 없애고 효과성을 크게 높인다.

다음 단계
쿠버네티스 인프라의 미래를 위해 우리는 프레임워크 배치를 위해 깃옵스(GitOps)를 도입하고 잠재적인 배치 에이전트로 플럭스(Flux)를 도입할 방침이다. 또한 게이트키퍼(Gatekeeper)를 사용하여 OPA(Open Policy Agent)와 쿠버네티스를 통합하여 승인된 컨테이너 생성, 권한 컨테이너 등에 대한 정책 관리를 제공할 계획이다.

클라우드와 쿠버네티스의 잠재력을 연구하기 시작한 조직에서는 자동화 및 IaC와 SaC 구현과 관련하여 여기에서 언급한 것과 유사한 아키텍처 및 보안 선택을 조사하는 것을 강력 추천한다. 그러면 쿠버네티스를 성공적으로 활용하고 여러 장점을 누릴 수 있을 것이다.

* 기고자 Karl-Heinz Prommer는 뮌헨재보험의 테크니컬 아키텍트다. ciokr@idg.co.kr

X