컨테이너 보안 — 새로운 영역 (2부)

컨테이너 사용의 보안 유지를 위한 고려 사항에 대한 2부작 블로그 시리즈입니다.

새로운 차원의 컨테이너 보안

컨테이너가 야기할 수 있는 보안 문제를 설명했습니다. 첫 번째 블로그 게시물에서.이로 인해 컨테이너 보안에 대해 어떻게 생각해야 하는지에 대한 의문이 생깁니다.

클라우드, 클러스터, 컨테이너, 코드의 네 가지 C를 다루는 계층화된 심층 방어 접근 방식을 사용하라는 Kubernetes의 조언으로 시작하고 이를 기반으로 구축해야 한다고 생각합니다.또한 세그먼테이션을 통해 컨테이너를 손상시키는 위협을 억제하는 방법도 고려해야 한다고 생각합니다.

이 경우, 우리는 격리를 다섯 번째 C로 제안합니다.

앞서 컨테이너를 보호할 뿐만 아니라 컨테이너가 악용되어 데이터 센터 내부로 이동하기 위한 교두보로 사용되지 않도록 해야 할 필요성에 대해 논의했습니다.바로 이 부분에서 격리의 필요성이 대두됩니다.

4C에 대한 초기 쿠버네티스 지침을 살펴본 다음 격리에 대해 논의하겠습니다.

컨테이너

쿠버네티스에서 소프트웨어를 실행하려면 소프트웨어가 컨테이너에 있어야 합니다.이 때문에 쿠버네티스는 몇 가지 일반적인 보안 고려 사항을 다음과 같이 요약합니다.

• 검사: 컨테이너를 검사하여 알려진 취약점을 찾아냅니다.CoreOS의 Clair와 같은 도구가 도움이 될 수 있습니다.
• 컨테이너 이미지 서명: Docker 엔진에 내장된 Docker 콘텐츠 신뢰를 사용하여 컨테이너 콘텐츠에 대한 신뢰를 유지합니다.IBM의 Portieris 프로젝트는 올바르게 서명된 이미지에 대해 콘텐츠 신뢰를 적용하기 위한 승인 컨트롤러로 사용할 수 있습니다.
• 사용자 권한 제어: 컨테이너 내에서 컨테이너의 목표를 수행하는 데 필요한 최소 수준의 운영 체제 권한을 가진 사용자를 생성하려고 합니다. 

코드

애플리케이션 코드 수준을 살펴보면 쿠버네티스 지침은 다음과 같은 몇 가지 사항에 부딪힙니다.

• TLS를 통한 액세스만 허용: 방화벽 뒤에 있는 네트워크 서비스 간에도 전송 중인 모든 항목을 기본적으로 암호화합니다.
• 통신 포트 범위 제한: 서비스의 필수 포트만 노출합니다.
• 정적 코드 분석: 안전하지 않을 수 있는 코딩 관행이 있는지 코드를 분석합니다.
• 동적 프로빙 공격 테스트: 사용 OWASP 도구 SQL 인젝션, CSRF 등과 같은 일반적인 공격을 자동화합니다.

클라우드

각 클라우드 공급자는 클라우드 인프라에서 컨테이너 워크로드를 실행하는 방법에 대한 광범위한 권장 사항을 제공합니다.보안 제품은 클라우드 공급자마다 다를 수 있으므로 사용자는 이러한 권장 사항을 꼼꼼하게 따라야 합니다.인기 클라우드 제공업체 및 보안 권장 사항에 대한 링크는 다음에서 찾을 수 있습니다. https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security.

일반 지침에는 다음이 포함됩니다.

• 네트워크 액세스 제한: 대부분의 클라우드 보안 제공업체는 다음을 제공합니다. 네트워크 보안 액세스 제어 목록 사용 — 예를 들어 AWS는 워크로드를 그룹으로 나누고 그룹별로 ACL을 구성할 수 있는 보안 그룹을 제공합니다.
• API 액세스 제한: 이상적으로는 클러스터를 관리하는 데 필요한 서버만 API 서버에 액세스할 수 있어야 합니다.
• 쿠버네티스 클러스터 API에 대한 액세스 제한: 다음과 같은 클라우드 제공자 액세스를 클러스터에 제공하는 것이 가장 좋습니다. 최소 권한 원칙 관리에 필요한 리소스에 대해AWS의 Kops에 대한 예는 다음에서 찾을 수 있습니다.https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles.
• 'etcd'에 대한 액세스 제한: 이 디렉터리는 쿠버네티스의 클라우드 구성 파일이 있는 곳입니다.항상 TLS를 사용하여 이러한 파일에 액세스하고 파일을 수정하십시오.
• 모든 드라이브, 특히 etcd 드라이브 암호화: 권한 없는 사용자가 Kubernetes 클러스터에 속한 중요한 구성 파일 및 데이터 저장소를 보지 못하도록 차단합니다.

클러스터

• 다음을 사용하여 쿠버네티스 API에 대한 액세스를 클러스터로 제한합니다. RBAC.
• 클러스터를 제어하는 API에 대한 모든 액세스를 인증합니다.
• etcd의 모든 데이터를 포함하여 클러스터에서 사용하는 모든 비밀 키를 암호화합니다.
• 파드의 보안 측면 제어: 파드 보안 오브젝트는 시스템에 승인되기 위해 파드가 실행해야 하는 일련의 조건을 정의한다.
• 리소스 사용률 제어: 애플리케이션을 실행하는 Kubernetes 노드는 안정성과 리소스 밸런싱을 위해 서로 종속되어 있습니다.따라서 이러한 노드에서 사용하는 리소스의 양을 제한하는 정책이 있어야 합니다.
• 액세스 제어 목록을 사용하여 포드에 대한 모든 네트워크 정책을 제어합니다.이것이 남북 보안 정책입니다.내부 데이터 센터 정책은 아래 컨테인먼트를 참조하십시오.
• 모든 인그레스 액세스가 TLS를 통해 이루어지도록 제한합니다.

컨테인먼트

이를 통해 컨테이너에서 시작된 보안 침해의 확산을 방지하는 격리 5C에 도달하게 됩니다.격리가 가장 효과적이려면 몇 가지 사항을 고려해야 합니다.

• 새로 생성된 컨테이너를 실시간으로 검색합니다.
• 새로운 컨테이너 워크로드에 대한 자동 세분화를 허용하여 보안이 “시작 시” 자동으로 제공됩니다.
• 보이지 않는 것을 보호할 수 없기 때문에 컨테이너화된 워크로드와 베어메탈, 가상 머신, 프라이빗 및 퍼블릭 클라우드 전반에 대한 단일 뷰를 위해 컨테이너의 가시성을 다른 컴퓨팅 환경과 함께 중앙 집중화하십시오.
• 컨테이너와 그 외 모든 것에 통일된 정책을 적용하여 환경에 관계없이 통합 정책으로 세그먼트화할 수 있습니다.이렇게 하면 VM, 베어메탈 서버, 클라우드 및 컨테이너의 세분화를 위한 여러 포인트 도구를 사용하지 않아도 됩니다.

컨테이너에 대한 광범위한 심층 방어 접근 방식을 통해 조직은 컨테이너의 보안 실행 가능성을 보장받아 더욱 확신을 갖고 컨테이너를 배포할 수 있습니다.