Linux 컨테이너 보안을 강화하기 위한 10가지 측면
- PHPz원래의
- 2024-06-04 16:45:38437검색
컨테이너 보안 솔루션은 다양한 기술 스택과 컨테이너 수명 주기의 다양한 단계를 고려해야 합니다. - 1. 컨테이너 운영 체제 및 멀티 테넌시 - 2. 컨테이너 콘텐츠(신뢰할 수 있는 소스 사용) - 3. 컨테이너 등록(컨테이너 이미지에 대한 암호화된 액세스) - 4. 프로세스 보안 구축 - 5. 클러스터에 배포할 수 있는 항목 제어 - 6. 컨테이너 오케스트레이션: 컨테이너 플랫폼 보안 강화 - 7. 네트워크 격리 - 8. 스토리지 - 9. API 관리, 엔드포인트 보안 및 SSO(Single Sign-On) - 10. 역할 및 액세스 제어 관리
컨테이너는 애플리케이션을 패키징하고 개발 및 테스트 환경에서 프로덕션 환경으로 원활하게 배포하는 간단한 방법을 제공합니다. 이는 물리적 서버, 가상 머신(VM), 프라이빗 또는 퍼블릭 클라우드를 포함한 다양한 환경에서 일관성을 보장하는 데 도움이 됩니다. 선도적인 조직은 비즈니스 가치를 추가하는 애플리케이션을 쉽게 개발하고 관리하기 위해 이러한 이점을 기반으로 컨테이너를 빠르게 채택하고 있습니다.
엔터프라이즈 애플리케이션에는 강력한 보안이 필요합니다. 컨테이너에서 기본 서비스를 실행하는 사람이라면 누구나 "컨테이너는 안전한가요?", "우리 애플리케이션이 컨테이너를 신뢰할 수 있나요?"라고 묻습니다.
컨테이너 보안은 실행 중인 프로세스 보안과 매우 유사합니다. 컨테이너를 배포하고 실행하기 전에 전체 솔루션 기술 스택의 보안을 고려해야 합니다. 또한 애플리케이션과 컨테이너의 전체 수명 주기에 걸쳐 보안을 고려해야 합니다.이 10가지 측면에서 다양한 수준, 다양한 기술 스택 및 다양한 수명 주기 단계에서 컨테이너의 보안을 강화하도록 노력하세요.
컨테이너는 리소스를 격리하고 제한하는 Linux 프로세스로, 공유 호스트 커널 내에서 샌드박스 애플리케이션을 실행할 수 있습니다. Linux에서 실행 중인 프로세스를 보호하는 것과 동일한 방식으로 컨테이너를 보호해야 합니다. 권한을 포기하는 것은 중요하며 모범 사례로 남아 있습니다. 더 나은 접근 방식은 가능한 한 적은 권한으로 컨테이너를 만드는 것입니다. 컨테이너는 루트가 아닌 일반 사용자로 실행되어야 합니다. 다음으로, Linux 네임스페이스, SELinux(Security Enhanced Linux), cgroups, 기능, 보안 컴퓨팅 모드(seccomp) 등 Linux에서 사용할 수 있는 여러 수준의 보안 기능을 활용하여 컨테이너를 보호하세요.
컨테이너화된 환경에서 소프트웨어 구축은 전체 라이프사이클의 한 단계이며, 애플리케이션 코드는 런타임과 통합되어야 합니다. 이 빌드 프로세스를 관리하는 것은 소프트웨어 스택의 보안을 보장하는 데 중요합니다. 빌드 프로세스의 제품이 프로덕션에 배포된 제품과 정확히 일치하도록 "한 번 빌드하면 모든 곳에 배포"라는 개념을 고수합니다. 이는 컨테이너의 지속적인 안정성을 유지하는 데에도 매우 중요합니다. 즉, 실행 중인 컨테이너를 대신 패치하고 다시 빌드하고 재배포하는 것입니다. 규제가 심한 산업에 종사하든 단순히 팀 작업을 최적화하려는 경우든 컨테이너 이미지 관리를 설계하고 컨테이너 계층을 활용하여 제어를 분리하는 프로세스를 구축해야 합니다.
운영 및 유지보수팀에서 기본 이미지 관리
아키텍처 팀은 미들웨어, 런타임, 데이터베이스 및 기타 솔루션을 관리합니다
개발팀은 애플리케이션 레이어와 코드에만 집중합니다
마지막으로 사용자 지정 컨테이너에 서명하여 빌드와 배포 사이에 변조되지 않도록 하세요.
빌드 프로세스 중에 문제가 발생하거나 이미지 배포 후 취약점이 발견되는 경우 자동화된 정책 기반 배포를 통해 또 다른 보안 계층을 추가해야 합니다.
애플리케이션을 구축하는 데 사용되는 세 가지 컨테이너 이미지 계층인 코어, 미들웨어, 애플리케이션을 살펴보겠습니다. 코어 이미지에서 문제가 발견되면 이미지가 다시 빌드됩니다. 빌드가 완료되면 이미지가 컨테이너 플랫폼 등록 서버로 푸시됩니다. 플랫폼은 이미지의 변경 사항을 감지할 수 있습니다. 이 이미지에 의존하고 트리거를 정의한 빌드의 경우 플랫폼은 자동으로 애플리케이션을 다시 빌드하고 고정 라이브러리를 통합합니다.
빌드가 완료되면 이미지가 컨테이너 플랫폼의 내부 등록 서버로 푸시됩니다. 내부 등록 서버의 이미지 변경 사항은 즉시 감지되고 업데이트된 이미지는 애플리케이션에 정의된 트리거를 통해 자동으로 배포되므로 프로덕션에서 실행되는 코드가 항상 가장 최근에 업데이트된 이미지와 동일하게 유지됩니다. 이러한 모든 기능이 함께 작동하여 보안 기능을 CI/CD(지속적인 통합 및 지속적인 배포) 프로세스에 통합합니다.
물론 애플리케이션이 단일 컨테이너로 전달되는 경우는 거의 없습니다. 간단한 애플리케이션에도 일반적으로 프런트엔드, 백엔드 및 데이터베이스가 있습니다. 컨테이너에 최신 마이크로서비스 애플리케이션을 배포한다는 것은 그림에 표시된 것처럼 때로는 동일한 호스트에 때로는 여러 호스트 또는 노드에 분산되어 여러 컨테이너를 배포하는 것을 의미하는 경우가 많습니다.
대규모 컨테이너 배포를 관리할 때 고려해야 할 사항은 다음과 같습니다.
어떤 컨테이너를 어떤 호스트에 배포해야 합니까?
어떤 호스트의 용량이 더 크나요?
어떤 컨테이너가 서로 액세스해야 하나요? 그들은 어떻게 서로를 발견하게 될까요?
네트워크, 스토리지 등 공유 리소스에 대한 액세스 및 관리를 어떻게 제어하나요?
컨테이너 상태를 모니터링하는 방법은 무엇입니까?
수요에 맞게 애플리케이션 기능을 자동으로 확장하는 방법은 무엇입니까?
개발자가 셀프 서비스를 수행하면서 보안 요구 사항을 충족할 수 있도록 하려면 어떻게 해야 합니까?
개발자와 운영자가 보유한 광범위한 기능을 고려할 때 강력한 역할 기반 액세스 제어는 컨테이너 플랫폼의 핵심 요소입니다. 예를 들어 오케스트레이션 관리 서버는 중앙 액세스 지점이므로 최고 수준의 보안 검사를 받아야 합니다. API는 컨테이너, 서비스 및 복제 컨트롤러에 대한 데이터를 검증하고 구성하는 데 사용되는 자동화된 컨테이너 관리의 핵심입니다.
컨테이너에 최신 마이크로서비스 애플리케이션을 배포한다는 것은 여러 노드에 분산된 여러 컨테이너를 배포하는 것을 의미하는 경우가 많습니다. 네트워크 방어를 염두에 두고 클러스터 내에서 애플리케이션을 격리하는 방법이 필요합니다.
Google Container Engine(GKE), Azure Container Services 또는 Amazon Web Services(AWS) Container Service와 같은 일반적인 퍼블릭 클라우드 서비스는 단일 테넌트 서비스입니다. 시작하는 VM 클러스터에서 컨테이너를 실행할 수 있습니다. 멀티 테넌트 컨테이너 보안을 달성하려면 단일 클러스터를 선택하고 트래픽을 세그먼트화하여 해당 클러스터 내의 다양한 사용자, 팀, 애플리케이션 및 환경을 격리할 수 있는 컨테이너 플랫폼이 필요합니다.
네트워크 네임스페이스를 사용하면 각 컨테이너 컬렉션("POD"라고 함)은 자체 IP 및 포트 바인딩 범위를 가져오므로 노드에서 POD 네트워크를 격리합니다.
기본적으로 다른 네임스페이스(프로젝트)의 POD는 아래 설명된 옵션을 제외하고 다른 프로젝트의 POD 또는 서비스에서 패킷을 보내거나 받을 수 없습니다. 이러한 기능을 사용하여 클러스터에서 개발자, 테스트 및 프로덕션 환경을 격리할 수 있습니다. 그러나 이러한 IP 주소 및 포트 확장으로 인해 네트워킹이 더욱 복잡해집니다. 이러한 복잡성을 처리할 수 있는 도구에 투자하십시오. 선호되는 도구는 전체 클러스터의 컨테이너 간 통신을 보장하기 위해 통합 클러스터 네트워크를 제공하는 소프트웨어 정의 네트워크(SDN) 컨테이너 플랫폼을 사용하는 것입니다.
컨테이너는 상태 저장 애플리케이션과 상태 비저장 애플리케이션 모두에 매우 유용합니다. 스토리지 보안은 상태 저장 서비스를 보장하는 핵심 요소입니다. 컨테이너 플랫폼은 NFS(Network File System), AWS Elastic Block Stores(EBS, Elastic Block Storage), GCE 영구 디스크, GlusterFS, iSCSI, RADOS(CEPH), Cinder 등을 포함한 다양한 스토리지 플러그인을 제공해야 합니다.
PV(영구 볼륨)는 리소스 공급자가 지원하는 모든 호스트에 마운트할 수 있습니다. 공급자는 다양한 기능을 가지며 각 PV의 액세스 모드는 특정 볼륨에서 지원되는 특정 모드로 설정될 수 있습니다. 예를 들어 NFS는 여러 읽기/쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로만 내보낼 수 있습니다. 각 PV에는 ReadWriteOnce, ReadOnlyMany 및 ReadWriteMany와 같은 PV 관련 성능 메트릭을 정의하는 고유한 액세스 모드 세트가 있습니다.
애플리케이션 보안에는 애플리케이션, API 인증 및 권한 부여 관리가 포함됩니다. 웹 SSO 기능은 최신 애플리케이션의 중요한 부분입니다. 개발자가 자신의 애플리케이션을 구축할 때 컨테이너 플랫폼은 이들이 사용할 수 있는 다양한 컨테이너 서비스를 제공할 수 있습니다.
API는 마이크로서비스 애플리케이션의 핵심 구성 요소입니다. 마이크로서비스 애플리케이션에는 여러 개의 독립적인 API 서비스가 있으므로 서비스 엔드포인트가 급증하므로 더 많은 거버넌스 도구가 필요합니다. API 관리 도구를 사용하는 것이 좋습니다. 모든 API 플랫폼은 API 인증 및 보안을 위한 다양한 표준 옵션을 제공해야 하며, 이는 인증서 발급 및 액세스 제어를 위해 단독으로 또는 조합하여 사용할 수 있습니다. 이러한 옵션에는 표준 API 키, 앱 ID, 키 쌍 및 OAuth 2.0이 포함됩니다.
2016년 7월, Kubernetes 1.3에서는 Kubernetes Federated Cluster를 도입했습니다. 이는 현재 Kubernetes 1.6 베타에 있는 흥미로운 새 기능입니다.
퍼블릭 클라우드 또는 엔터프라이즈 데이터 센터 시나리오에서 페더레이션은 클러스터 전체에 애플리케이션 서비스를 배포하고 액세스하는 데 유용합니다. 멀티 클러스터를 사용하면 여러 지역, 여러 클라우드 공급자(예: AWS, Google Cloud 및 Azure)와 같은 애플리케이션의 고가용성이 가능해 배포 또는 마이그레이션의 공통 관리가 가능합니다.
클러스터 페더레이션을 관리할 때 오케스트레이션 도구가 다양한 배포 플랫폼 인스턴스에 필요한 보안을 제공하는지 확인해야 합니다. 항상 그렇듯이 인증과 권한 부여는 보안의 핵심입니다. 실행 위치에 관계없이 애플리케이션에 데이터를 안전하게 전달할 수 있고 클러스터에서 애플리케이션 다중 테넌시를 관리할 수 있습니다.
Kubernetes는 연합 암호화, 연합 네임스페이스 및 객체 항목에 대한 지원을 포함하도록 클러스터 연합을 확장합니다.
위 내용은 Linux 컨테이너 보안을 강화하기 위한 10가지 측면의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!