Kubernetes와 같은 오케 스트레이터와 함께 컨테이너는 애플리케이션 개발 방법론의 새로운 시대를 열었으며 마이크로 서비스 아키텍처는 물론 지속적인 개발 및 제공을 가능하게합니다. 

Docker는 최신 컨테이너 상태 및 Kubernetes 보안 보고서 에 따르면 91 %의 침투율을 기록한 가장 지배적 인 컨테이너 런타임 엔진 입니다.

컨테이너화에는 많은 이점이 있으며 그 결과 널리 채택되었습니다. 

Gartner에 따르면 2020 년까지 글로벌 조직의 50 % 이상이 프로덕션 환경에서 컨테이너화 된 애플리케이션을 실행할 것입니다. 

그러나 Docker 컨테이너를 사용하여 앱을 빌드하면 새로운 보안 문제와 위험도 발생합니다. 

손상된 단일 Docker 컨테이너는 Docker 보안의 중요성을 강조하면서 다른 모든 컨테이너와 기본 호스트를 위협 할 수 있습니다.

Docker 보안은 크게 두 가지 영역으로 분류 할 수 있습니다.

컨테이너 위반이 호스트 위반으로 이어지지 않도록 호스트를 보호하고 강화하는 것과 Docker 컨테이너를 보호하는 것입니다. 

이전 블로그 기사 에서 호스트 보안에 대해 간략히 설명했습니다 . 

이 문서는 Docker 컨테이너 보안 위험과 과제를 강조하고 빌드 및 배포 단계에서 환경을 강화하고 런타임 중에 Docker 컨테이너를 보호하기위한 모범 사례를 제공하여 컨테이너 보안에 중점을 둡니다.

또한 컨테이너 오케스트레이션에서 Kubernetes가 대규모로 채택되고 중요한 역할을하므로 Kubernetes 보안 모범 사례를 공유합니다. 

마지막으로 컨테이너 보안 플랫폼이 답할 수 있어야하는 11 가지 주요 보안 질문을 제공하여 프로덕션에서 컨테이너와 Kubernetes를 안전하게 실행하는 데 필요한 통찰력과 보호를 제공합니다.

기업은 오랫동안 가상 머신 (VM) 또는 베어 메탈 서버에 애플리케이션을 배포 해 왔습니다. 해당 인프라에 대한 보안에는 애플리케이션과 실행중인 호스트를 보호 한 다음 실행되는 애플리케이션을 보호하는 것이 포함되었습니다. 컨테이너화는 해결해야 할 몇 가지 새로운 과제를 도입합니다.

1. 컨테이너는 마이크로 서비스를 활성화하여 데이터 트래픽과 네트워크 및 액세스 제어 복잡성을 증가시킵니다.
2. 컨테이너는 기본 이미지에 의존하며 이미지의 출처가 안전한지 또는 안전하지 않은지 파악하는 것은 어려울 수 있습니다. 이미지에는 취약한 이미지를 사용하는 모든 컨테이너로 확산 될 수있는 취약성이 포함될 수도 있습니다.
3. 컨테이너는 수명이 짧기 때문에 특히 런타임 중에 모니터링하는 것이 매우 어려울 수 있습니다. 또 다른 보안 위험은 끊임없이 변화하는 컨테이너 환경에 대한 가시성 부족으로 인해 발생합니다.
4. VM과 달리 컨테이너는 반드시 서로 격리되지는 않습니다. 단일 컨테이너가 손상되면 다른 컨테이너가 손상 될 수 있습니다.
5. 컨테이너화 된 환경에는 자체 보안 문제 를 제기하는 Kubernetes 오케 스트레이터를 포함하여 기존 VM보다 더 많은 구성 요소가 있습니다. 심각도가 높은 취약점의 영향을받는 배포 또는 클러스터를 알 수 있습니까? 인터넷에 노출되어 있습니까? 특정 취약점이 악용 될 경우 폭발 반경은 얼마입니까? 컨테이너가 프로덕션 또는 개발 / 테스트 환경에서 실행되고 있습니까?
6. 컨테이너 구성은 보안 위험을 초래하는 또 다른 영역입니다. 컨테이너가 실행되지 않아야 할 때 높은 권한으로 실행되고 있습니까? 이미지가 공격 표면을 증가시키는 불필요한 서비스를 시작합니까? 비밀은 이미지에 저장됩니까?
7. 가장 큰 보안 동인 중 하나 인 규정 준수는 컨테이너 환경의 빠르게 변화하는 특성을 감안할 때 특별한 도전이 될 수 있습니다. 방화벽 규칙과 같이 규정 준수를 입증하는 데 도움이 된 많은 기존 구성 요소는 Docker 환경에서 매우 다른 형태를 취합니다.
8. 마지막으로 기존 서버 워크로드 보안 솔루션은 컨테이너 보안 문제와 위험을 해결할 수있는 기능이 부족합니다.

다음은 Docker 컨테이너 및 이미지를 안전하게 구성하기 위해 산업 표준 및 StackRox 고객으로부터 파생 된 모범 사례 목록입니다.

1. 항상 최신 버전의 Docker를 사용하십시오. runC 취약점 올해 초부터, 예를 들어, 신속하게 도커 버전의 출시와 함께 자사의 발견 직후 패치 된 18.09.2 .
2. 신뢰할 수있는 사용자 만 Docker 그룹의 구성원인지 확인하여 신뢰할 수있는 사용자 만 Docker 데몬을 제어하도록 허용합니다. Docker 데몬 공격 표면을 줄이는 방법에 대한 자세한 내용은 이 문서 를 확인하세요 .
3. 다음에 대한 감사 추적을 제공하는 규칙이 있는지 확인하십시오.
   1. Docker 데몬
   2. Docker 파일 및 디렉토리 :
      1. / var / lib / 도커
      2. / etc / docker
      3. Docker.service
      4. Docker.socket
      5. / etc / default / docker
      6. /etc/docker/daemon.json
      7. / etc / sysconfig / docker
      8. / usr / bin / containerd
      9. / usr / sbin / runc
   3. 확인 이 문서 자세한 내용을
4. 모든 Docker 파일 및 디렉터리 (위의 4.2 참조)를 적절한 사용자 (일반적으로 루트 사용자)가 소유하고 파일 권한이 제한적인 값으로 설정되었는지 확인하여 ( Docker 데몬 구성 파일 의 CIS 벤치 마크 섹션 참조 ) 보안을 유지합니다.
5. 유효한 레지스트리 인증서가있는 레지스트리 또는 TLS를 사용하는 레지스트리를 사용하여 트래픽 차단 위험을 최소화하십시오.
6. 이미지에 명시적인 컨테이너 사용자가 정의되지 않은 컨테이너를 사용하는 경우 사용자 네임 스페이스 지원을 활성화해야합니다. 그러면 컨테이너 사용자를 호스트 사용자로 다시 매핑 할 수 있습니다.
7. 컨테이너가 새로운 권한을 얻지 못하도록합니다. 기본적으로 컨테이너는 새 권한을 획득 할 수 있으므로이 구성을 명시 적으로 설정해야합니다. 권한 에스컬레이션 공격을 최소화하기 위해 취할 수있는 또 다른 단계는 이미지에서 setuid 및 setgid 권한을 제거하는 것입니다.
8. 모범 사례로, 루트가 아닌 사용자 (UID가 0이 아님)로 컨테이너를 실행하십시오. 기본적으로 컨테이너는 컨테이너 내에서 루트 사용자로 루트 권한으로 실행됩니다.
9. 컨테이너를 빌드 할 때 신뢰할 수있는 기본 이미지 만 사용하십시오. 이 팁은 분명한 것처럼 보일 수 있지만 타사 레지스트리에는 저장된 이미지에 대한 거버넌스 정책이없는 경우가 많습니다. Docker 호스트에서 사용할 수있는 이미지를 알고, 출처를 이해하고, 이미지의 콘텐츠를 검토하는 것이 중요합니다. 또한 이미지 확인을 위해 Docker에 대한 콘텐츠 신뢰를 활성화하고 확인 된 패키지 만 이미지에 설치해야합니다.
10. 더 큰 공격 영역으로 이어질 수있는 불필요한 소프트웨어 패키지를 포함하지 않는 최소한의 기본 이미지를 사용합니다. 컨테이너에 구성 요소가 적 으면 사용 가능한 공격 벡터의 수가 줄어들고 디스크에 바이트가 적고 복사되는 이미지에 대한 네트워크 트래픽이 적기 때문에 이미지를 최소화하면 성능이 향상됩니다. BusyBox와 Apline은 최소한의 기본 이미지를 만들기위한 두 가지 옵션입니다.
11. 빈번한 이미지 스캔을 시행하는 강력한 거버넌스 정책을 구현합니다. 오래된 이미지 또는 최근에 스캔하지 않은 이미지는 빌드 단계로 이동하기 전에 거부하거나 다시 스캔해야합니다.
12. 호스트에서 오래되거나 사용되지 않는 이미지 및 컨테이너를 정기적으로 식별하고 제거하는 워크 플로를 구축합니다.
13. 이미지 / Dockerfiles에 비밀을 저장하지 마십시오. 기본적으로 Dockerfiles에 비밀을 저장할 수 있지만 이미지에 비밀을 저장하면 해당 이미지의 모든 사용자가 비밀에 액세스 할 수 있습니다. 비밀이 필요한 경우 비밀 관리 도구를 사용합니다 .
14. 컨테이너를 실행할 때 컨테이너가 필요에 따라 작동하는 데 필요하지 않은 모든 기능을 제거하십시오. Docker의 CAP DROP 기능을 사용하여 특정 컨테이너의 기능 (Linux 기능이라고도 함)을 삭제하고 CAP ADD를 사용하여 컨테이너의 적절한 기능에 필요한 기능 만 추가 할 수 있습니다.
15. –privileged 플래그를 사용하여 컨테이너를 실행하지 마십시오.이 유형의 컨테이너에는 기본 호스트에서 사용할 수있는 대부분의 기능이 있습니다. 이 플래그는 또한 CAP DROP 또는 CAP ADD를 사용하여 설정 한 모든 규칙을 덮어 씁니다.
16. 특히 호스트 손상을 초래할 수있는 방식으로 악의적으로 변경 될 수있는 쓰기 가능 모드에서는 민감한 호스트 시스템 디렉토리를 컨테이너에 마운트하지 마십시오 .
17. 컨테이너 내에서 sshd를 실행하지 마십시오. 기본적으로 ssh 데몬은 컨테이너에서 실행되지 않으며 SSH 서버의 보안 관리를 단순화하기 위해 ssh 데몬을 설치해서는 안됩니다.
18. 컨테이너 내에서 1024 미만의 포트는 중요한 데이터를 전송하기 때문에 권한이있는 것으로 간주되므로 매핑하지 마십시오. 기본적으로 Docker는 컨테이너 포트를 49153-65525 범위 내에있는 포트에 매핑하지만 컨테이너를 권한있는 포트에 매핑 할 수 있습니다. 일반적으로 컨테이너에서 필요한 포트만 열려 있는지 확인하십시오.
19. Docker 컨테이너와 기본 호스트간에 적절한 격리를 보장하기 위해 필요한 경우가 아니면 호스트의 네트워크 네임 스페이스, 프로세스 네임 스페이스, IPC 네임 스페이스, 사용자 네임 스페이스 또는 UTS 네임 스페이스를 공유하지 마십시오.
20. 임의의 양에 의존하는 대신 컨테이너가 설계된대로 작동하는 데 필요한 메모리 및 CPU 양을 지정합니다. 기본적으로 Docker 컨테이너는 제한없이 리소스를 동일하게 공유합니다.
21. 컨테이너의 루트 파일 시스템을 읽기 전용으로 설정합니다. 일단 실행되면 컨테이너는 루트 파일 시스템을 변경할 필요가 없습니다. 루트 파일 시스템에 대한 변경 사항은 악의적 인 목적을위한 것일 수 있습니다. 새 컨테이너가 패치되지 않고 새 이미지에서 다시 생성되는 컨테이너의 변경 불가능한 특성을 유지하려면 루트 파일 시스템을 쓰기 가능하게 만들지 않아야합니다.
22. PID 제한을 부과합니다. 컨테이너의 장점 중 하나는 엄격한 PID (프로세스 식별자) 제어입니다. 커널의 각 프로세스는 고유 한 PID를 전달하며 컨테이너는 Linux PID 네임 스페이스를 활용하여 각 컨테이너의 PID 계층 구조에 대한 별도의보기를 제공합니다. PID에 제한을두면 각 컨테이너에서 실행되는 프로세스 수를 효과적으로 제한합니다. 컨테이너의 프로세스 수를 제한하면 새로운 프로세스의 과도한 생성과 잠재적 인 악의적 인 측면 이동을 방지 할 수 있습니다. PID 제한을 부과하면 포크 폭탄 (계속 복제되는 프로세스) 및 비정상적인 프로세스도 방지됩니다. 대부분의 이점은 서비스가 항상 특정 수의 프로세스를 실행하는 경우 PID 제한을 정확한 수로 설정하면 리버스 셸 및 원격 코드 삽입을 포함한 많은 악의적 인 작업을 완화 할 수 있다는 것입니다.
23. 마운트 전파 규칙을 공유로 구성하지 마십시오. 마운트 전파 공유는 마운트에 대한 모든 변경 사항이 해당 마운트의 모든 인스턴스에 전파됨을 의미합니다. 대신에 볼륨에 대한 필요한 변경 사항이 변경이 필요하지 않은 컨테이너와 공유 (또는 전파)되지 않도록 슬레이브 또는 개인 모드에서 마운트 전파를 설정하십시오.
24. 이 설정은 컨테이너 확장 Linux 기능을 제공 할 수 있으므로 권한이있는 또는 user = root 옵션과 함께 docker exec 명령을 사용하지 마십시오.
25. 기본 브리지 "docker0"을 사용하지 마십시오. 기본 브리지를 사용하면 ARP 스푸핑 및 MAC 플러딩 공격에 노출됩니다. 대신 컨테이너는 기본 "docker0"브리지가 아닌 사용자 정의 네트워크에 있어야합니다.
26. 컨테이너 내부에 Docker 소켓을 탑재하지 마십시오.이 접근 방식을 사용하면 컨테이너 내의 프로세스가 호스트를 완전히 제어하는 ​​명령을 실행할 수 있습니다.

컨테이너 오케스트레이션을위한 사실상의 표준 인 Kubernetes는 애플리케이션 보안을 보장하는 데 중추적 인 역할을합니다. 컨테이너화 된 애플리케이션을 효과적으로 보호하려면 Kubernetes의 컨텍스트 정보와 기본 정책 시행 기능을 활용해야합니다. 예를 들어 Kubernetes에는 Kubernetes RBAC, 네트워크 정책 및 승인 컨트롤러를 포함하여 전체 수명주기 컨테이너 보안을보다 쉽게 ​​운영 할 수 있도록하는 몇 가지 기본 제공 보안 기능이 있습니다. Kubernetes의 이러한 고유 한 제어 기능을 활용하여 컨테이너화 된 환경을 보호하십시오.

다음은 전체 수명주기 컨테이너 보안을 운영하는 데 도움이되는 몇 가지 Kubernetes 보안 모범 사례입니다.

1. RBAC의 경우 사용자 또는 사용자 그룹에 클러스터 관리자 권한을 부여하는 대신 특정 사용자 또는 사용자 그룹에 역할 및 ClusterRoles를 지정합니다.
2. Kubernetes RBAC를 사용할 때 권한 중복을 피하십시오. 그렇게하면 운영 문제가 발생할 수 있습니다.
3. 보안 사고를 해결하거나 조사 할 때 활성 역할에주의를 집중할 수 있도록 사용되지 않거나 비활성 RBAC 역할을 제거합니다.
4. Kubernetes 네트워크 정책을 사용하여 포드를 분리하고 애플리케이션이 작동하는 데 필요한 통신 경로 만 명시 적으로 허용합니다. 그렇지 않으면 측면 및 남북 위협에 모두 노출됩니다.
5. 포드에 인터넷 액세스 (수신 또는 송신)가 필요한 경우 올바른 네트워크 세분화 / 방화벽 규칙을 적용하는 적절한 네트워크 정책을 만든 다음 해당 네트워크 정책의 대상이되는 레이블을 만들고 마지막으로 포드를 해당 레이블에 연결합니다.
6. PodSecurityPolicy 승인 컨트롤러를 사용하여 적절한 거버넌스 정책이 시행되고 있는지 확인합니다. PodSecurityPolicy 컨트롤러는 컨테이너가 루트로 실행되는 것을 방지하거나 컨테이너의 루트 파일 시스템이 읽기 전용으로 마운트되도록 할 수 있습니다 (이 권장 사항은 둘 다 수행 할 Docker 조치의 이전 목록에 있으므로 익숙하게 들릴 것입니다).
7. Kubernetes 승인 컨트롤러를 사용하여 신뢰할 수없는 레지스트리에서 가져온 모든 이미지가 자동으로 거부되도록 이미지 레지스트리 거버넌스 정책을 시행하십시오.

보안 상태를 신속하게 평가할 수 있도록 보안, DevSecOps 또는 DevOps 팀이 클라우드 네이티브 스택이 적절한 보안 조치로 설계되었는지 여부에 대해 즉시 답변 할 수 있어야하는 질문 목록을 작성했습니다.

1. 마지막 스캔 날짜가 60 일을 초과하는 호스트에는 몇 개의 이미지가 있습니까?
2. 심각도가 높은 취약성이있는 이미지 / 컨테이너는 몇 개입니까?
3. 이러한 심각도가 높은 취약한 컨테이너의 영향을받는 배포는 무엇입니까?
4. 영향을받는 배포에 비밀이 저장된 컨테이너가 있습니까?
5. 취약한 컨테이너가 루트 또는 권한있는 플래그로 실행되고 있습니까?
6. 연결된 네트워크 정책이없는 포드에 취약한 컨테이너가 있습니까 (모든 통신을 허용 함을 의미)?
7. 프로덕션 환경에서 실행되는 컨테이너가이 취약점의 영향을 받습니까?
8. 우리가 사용하는 이미지의 출처는 어디입니까?
9. 신뢰할 수없는 레지스트리에서 가져온 이미지를 어떻게 차단합니까?
10. 컨테이너 런타임 중에 어떤 프로세스가 실행되고 있는지 볼 수 있습니까?
11. Docker 및 Kubernetes에 대한 CIS 벤치 마크를 준수하지 않는 클러스터, 네임 스페이스 및 노드는 무엇입니까?

이 목록에 정리 된 모범 사례를 따르면 Docker 및 Kubernetes 환경을 성공적으로 강화하고 중요한 비즈니스 애플리케이션을 보호하기 위해 가장 중요한 단계를 수행하게됩니다.