컨테이너 보안 - 새로운 개척지(2부)

컨테이너 사용을 안전하게 유지하기 위한 고려 사항에 대한 2부로 구성된 블로그 시리즈입니다.

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

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

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

이 경우, 다섯 번째 C로 봉쇄를 제안합니다. 

앞서 컨테이너를 보호할 뿐만 아니라 컨테이너가 악용되어 데이터 센터 내부로 측면 이동하기 위한 거점으로 사용될 수 없도록 해야 한다고 설명했습니다. 바로 이 지점에서 봉쇄의 필요성이 대두됩니다. 

4C에 대한 초기 Kubernetes 지침을 살펴본 다음 봉쇄에 대해 논의해 보겠습니다.

컨테이너

Kubernetes에서 소프트웨어를 실행하려면 해당 소프트웨어가 컨테이너에 있어야 합니다. 이 때문에 쿠버네티스에는 몇 가지 일반적인 보안 고려 사항이 있습니다:

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

코드

애플리케이션 코드 레벨을 살펴보면 Kubernetes 가이드는 몇 가지 사항을 강조합니다:

• 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 클러스터에 속한 중요한 구성 파일과 데이터 저장소를 볼 수 없도록 차단하세요.

클러스터

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

격리

이제 컨테이너에서 시작된 침해가 확산되는 것을 방지하는 다섯 번째 봉쇄의 C를 살펴봅니다. 봉쇄가 가장 효과적이려면 몇 가지 사항을 고려해야 합니다:

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

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