컨테이너 기반환경 보호를 위한 컨테이너 탈출(container escape) 방지

컨테이너 기반의 애플리케이션을 보호하기 위해 컨테이너 탈출(container escape)을 방지하는 것은 중요합니다. 컨테이너 탈출이란 컨테이너가 호스트 머신의 자원에 무단으로 접근하거나 제어할 수 있게 되는 보안 취약점을 의미합니다. 이를 방지하기 위한 여러 가지 방법들이 있습니다.

1. 모든 CAP(능력) 제거하고 필요할 때만 추가

• 리눅스 커널은 특정 작업을 수행할 수 있는 능력(Capabilities)을 정의합니다. 기본적으로 컨테이너는 제한된 능력 세트를 가지고 시작되지만, 특정 작업을 수행하기 위해 추가적인 능력이 필요할 수 있습니다. 보안을 강화하기 위해서는 모든 능력을 제거하고 필요할 때만 최소한의 능력을 추가하는 것이 좋습니다.

2. Privileged Container 사용 금지 혹은 최소화

• Privileged 컨테이너는 호스트 시스템의 거의 모든 능력을 가지며, 이는 컨테이너 탈출을 쉽게 만들 수 있습니다. 가능한 이러한 컨테이너의 사용을 금지하거나 최소화해야 합니다. AllowPrivilegeEscalation 플래그를 비활성화하고, Docker에서는 --security-opt=no-new-privileges 옵션을 사용하여 새로운 권한 부여를 방지합니다.

3. CAP_SYS_ADMIN 능력 사용 금지

• CAP_SYS_ADMIN은 매우 강력한 능력으로, 여러 가지 시스템 수준의 작업을 가능하게 합니다. 이 능력을 컨테이너에 부여하는 것은 매우 위험할 수 있으므로, 사용을 금지하는 것이 좋습니다.

4. Seccomp을 사용하여 위험한 시스템 호출 차단

• Seccomp(Secure Computing Mode)는 프로세스가 특정 시스템 호출을 실행하는 것을 제한할 수 있는 리눅스 커널 기능입니다. 컨테이너에 대해 seccomp 프로필을 정의하여 위험한 시스템 호출을 차단함으로써, 컨테이너가 시스템에 미칠 수 있는 잠재적인 영향을 제한할 수 있습니다.

5. AppArmor를 사용하여 특정 프로그램에서 사용하는 능력 차단

• AppArmor(Application Armor)는 리눅스 커널의 보안 모듈로, 프로그램별로 제한된 리소스 접근 권한을 설정할 수 있습니다. 컨테이너 내의 특정 프로그램이 사용할 수 있는 파일, 네트워크, 기타 시스템 리소스를 제한함으로써, 악의적인 활동이나 컨테이너 탈출 시도를 방지할 수 있습니다.

 

이러한 보안 조치를 통해, 컨테이너 기반 시스템의 보안을 강화하고 잠재적인 컨테이너 탈출 시도로부터 시스템을 보호할 수 있습니다. 각 조치는 컨테이너 환경과 애플리케이션의 특성에 따라 적절히 조정되어야 합니다.

 

최근 기술 변화와 함께 컨테이너의 사용이 일상적인 운영에 필수적이 되면서, 컨테이너를 대상으로 한 사이버 공격의 수가 크게 증가하였습니다. 이에 따라 보안 연구원과 블루팀은 컨테이너 보안 분야에 익숙해져야 합니다. 컨테이너 탈출은 공격자가 컨테이너에서 벗어나 기본 호스트에 접근할 수 있게 하는 고급 공격 기법으로, 이는 호스트 또는 다른 컨테이너로의 수평 이동을 가능하게 합니다.

 

컨테이너와 VM의 차이점 이해

• 컨테이너는 VM과 다르게 호스트의 커널을 공유하며, 리눅스의 다양한 격리 메커니즘을 사용하여 프로세스를 제한합니다. 이러한 차이점은 공격 벡터와 보안 메커니즘을 이해하는 데 중요합니다.

CAP(능력)과 그 중요성

• 리눅스는 특정 권한을 프로세스에 부여할 수 있는 CAP를 통해 "모든 것 또는 아무것도 아님"의 이분법을 논리적 권한 그룹으로 나눕니다. CAP는 컨테이너 프로세스에 적용되어 해당 컨테이너의 모든 프로세스가 해당 CAP를 상속받을 수 있습니다.

컨테이너 탈출 방지를 위한 최선의 방법

• 모든 CAP 제거 및 필요시 추가: 컨테이너 생성 시 모든 CAP을 먼저 삭제한 다음, 컨테이너 목적에 필요한 CAP만 추가합니다.
• Privileged 컨테이너 최소화: Privileged 컨테이너의 사용을 최소화하고, AllowPrivilegeEscalation 플래그를 비활성화하여 권한 상승을 방지합니다.
• CAP_SYS_ADMIN 사용 금지: 이 CAP는 매우 강력하므로 사용을 금지합니다.
• Seccomp 필터 사용: 컨테이너에서 특정 위험한 시스템 호출을 차단하기 위해 Seccomp 필터를 사용합니다.
• AppArmor 프로필 적용: 특정 프로그램에서 사용하는 위험한 CAP를 차단하기 위해 AppArmor 프로필을 적용합니다.

컨테이너 탈출 시나리오

• 컨테이너 탈출은 여러 방법으로 수행될 수 있으며, SYS_MODULE CAP를 이용한 커널 모듈 설치, SYS_PTRACE를 이용한 프로세스 디버깅 또는 쉘코드 주입 등이 포함됩니다. 이러한 공격은 컨테이너 설정의 미스컨피규레이션을 이용합니다.

탐지 및 방어

• Cybereason Cloud Workflow Protection (CWPP)과 같은 도구는 행동 분석과 머신러닝을 사용하여 컨테이너 탈출을 포함한 악의적인 활동을 탐지할 수 있습니다. 공격 행위를 찾는 것은 변경될 수 있는 서명을 사용하는 것보다 효과적입니다.

 

컨테이너 보안을 강화하기 위해선 이러한 베스트 프랙티스를 실천하고, 컨테이너 설정에 필요한 모든 권한이 정말 필요한지 확인해야 합니다. 이를 통해 컨테이너를 통한 호스트 접근 및 네트워크를 통한 이동을 방지할 수 있습니다.

 

컨테이너 보안에 대한 깊은 이해와 방어 전략을 구축하기 위해, 컨테이너 탈출의 메커니즘, 공격 시나리오 및 이에 대한 방어 방법에 대해 자세히 살펴보겠습니다. 컨테이너 탈출은 공격자가 컨테이너화된 환경을 벗어나 호스트 시스템에 접근할 수 있게 하는 공격 기법입니다.

컨테이너와 VM의 차이점

컨테이너와 가상머신(VM)은 기본적으로 격리된 환경을 제공하지만, 구현 방식에서 큰 차이가 있습니다. VM은 각각의 가상화된 하드웨어 위에 전체 운영 체제를 실행하는 반면, 컨테이너는 호스트의 커널을 공유하고 프로세스 수준에서 격리를 제공합니다. 이러한 차이는 컨테이너를 가볍고 빠르게 만들지만, 보안 측면에서는 추가적인 고려가 필요합니다.

Linux Capabilities

Linux Capabilities는 특정 프로세스에 대해 루트 권한을 미세하게 조절할 수 있는 메커니즘을 제공합니다. 예를 들어, CAP_NET_BIND_SERVICE는 프로세스가 1024번 이하의 포트에 바인딩할 수 있는 권한을 부여합니다. 이러한 Capabilities는 컨테이너에 부여되어, 필요한 최소 권한으로 운영될 수 있도록 합니다.

컨테이너 탈출 방지 전략

1. 모든 CAP 제거 및 필요 시 추가

컨테이너를 생성할 때는 모든 CAP을 제거(--cap-drop ALL)하고, 필요한 경우에만 특정 CAP을 추가합니다(--cap-add=<CAP>).

Docker 예시:

docker run --cap-drop ALL --cap-add=SYS_LOG_ADMIN -it ubuntu bash

Kubernetes 예시:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: secure-container
    image: ubuntu
    securityContext:
      capabilities:
        drop:
        - ALL
        add:
        - SYS_LOG_ADMIN

2. Privileged 컨테이너 최소화

Privileged 컨테이너는 모든 CAP을 가지므로, 이를 최소화하고 --privileged 플래그의 사용을 피합니다.

3. CAP_SYS_ADMIN 사용 금지

CAP_SYS_ADMIN은 매우 강력한 권한이므로, 이를 컨테이너에 부여하지 않도록 합니다.

4. Seccomp 및 AppArmor

Seccomp과 AppArmor를 사용하여 위험한 시스템 호출이나 CAP의 사용을 제한합니다. Seccomp 프로필이나 AppArmor 프로필을 정의하여 적용할 수 있습니다.

컨테이너 탈출 시나리오 및 대응 방법

1. SYS_MODULE을 통한 커널 모듈 설치

SYS_MODULE CAP를 가진 컨테이너는 커널 모듈을 설치할 수 있으며, 이를 악용하여 컨테이너 탈출을 시도할 수 있습니다.

대응 방법: SYS_MODULE CAP의 사용을 제한하고, 컨테이너에서 필요하지 않은 경우 제거합니다.

2. SYS_PTRACE를 통한 프로세스 디버깅 및 쉘코드 주입

SYS_PTRACE CAP는 프로세스를 디버깅하거나 다른 프로세스에 쉘코드를 주입할 수 있게 합니다. 이를 통해 공격자는 호스트 시스템에 대한 제어를 얻을 수 있습니다.

대응 방법: SYS_PTRACE CAP를 제거하고, 필요한 경우에만 최소한으로 부여합니다.

탐지 및 대응

• 행동 분석 및 머신러닝: Cybereason Cloud Workflow Protection과 같은 툴은 행동 분석과 머신러닝을 사용하여 컨테이너 탈출 시도를 탐지할 수 있습니다.
• 로그 모니터링 및 감사: 컨테이너 활동에 대한 로그를 모니터링하고 감사하여 의심스러운 행위를 조기에 탐지합니다.

 

컨테이너 보안은 지속적인 관리와 모니터링을 필요로 합니다. 위에서 언급된 방법들을 통해 컨테이너 기반 인프라의 보안을 강화하고, 공격자의 컨테이너 탈출 시도를 방지할 수 있습니다.

 

컨테이너 기술은 애플리케이션 배포와 관리를 혁신적으로 단순화하고 자동화했지만, 이와 동시에 다양한 보안 도전 과제를 제기합니다. 컨테이너를 안전하게 운영하기 위한 보안 관련 조치를 종합적으로 정리하고, 알려진 취약점에 대한 보호 조치를 설명하겠습니다.

컨테이너 보안의 기본 원칙

1. 최소 권한 원칙 적용: 컨테이너와 컨테이너를 실행하는 사용자에게 필요한 최소한의 권한만 부여합니다.
2. 이미지 보안: 신뢰할 수 있는 소스에서 컨테이너 이미지를 가져오고, 이미지에 포함된 소프트웨어의 취약점을 정기적으로 스캔합니다.
3. Privilege Mode 비활성화 및 non-root 실행: 컨테이너를 비특권 모드에서 실행하고, 가능한 non-root 사용자로 실행하여 권한 상승 공격을 방지합니다.
4. 네트워크 분리와 보안: 컨테이너 간 및 컨테이너와 외부의 통신을 제어하고 제한하는 네트워크 정책을 적용합니다.
5. 액세스 및 권한 관리: 역할 기반 액세스 제어(RBAC)를 사용하여, 컨테이너 관리에 대한 접근을 엄격하게 제어합니다.
6. 보안 감사 및 로깅: 모든 컨테이너 활동을 로깅하고, 보안 위협이나 비정상적인 행위를 탐지하기 위해 로그를 분석합니다.
7. 시크릿 관리: 민감한 정보(예: API 키, 비밀번호)를 안전하게 관리하고, 컨테이너에서 안전하게 사용할 수 있는 방법을 제공합니다.

알려진 취약점에 대한 보호 조치

• 취약점 스캔: 컨테이너 이미지를 빌드하고 배포하기 전에, 정기적으로 취약점을 스캔하여 알려진 취약점을 식별하고 수정합니다. 이는 취약한 소프트웨어 라이브러리나 의존성을 업데이트하거나 패치함으로써 이루어집니다.
• BuildKit 및 Privilege Mode 관리: BuildKit을 비활성화하고 Privilege Mode를 사용하지 않음으로써, 관련된 취약점으로부터 시스템을 보호합니다. 이는 컨테이너가 필요 이상의 권한을 획득하지 못하게 하여, 시스템에 대한 잠재적인 위협을 최소화합니다.
• 컨테이너 격리: 컨테이너를 격리된 환경에서 실행하여, 하나의 컨테이너가 취약점이나 공격에 노출되어도 시스템의 다른 부분에 영향을 미치지 않도록 합니다. 이는 네임스페이스, cgroups, 가상 머신, 네트워크 정책 등을 활용하여 구현할 수 있습니다.
• 패치 관리: 운영 시스템, 컨테이너 런타임, 컨테이너에 포함된 애플리케이션 및 라이브러리에 대해 최신 보안 패치를 적용합니다. 이는 시스템을 최신 상태로 유지하고 알려진 취약점으로부터 보호합니다.
• 보안 정책 적용: AppArmor, SELinux, seccomp와 같은 보안 정책을 컨테이너에 적용하여, 허용되지 않은 작업을 제한하고 시스템 리소스에 대한 접근을 제어합니다.

 

이러한 조치들은 컨테이너 기반 시스템의 보안을 강화하고, 알려진 취약점으로부터 보호하기 위해 필수적입니다. 보안은 지속적인 프로세스이므로, 새로운 취약점과 위협이 발견될 때마다 이러한 조치들을 검토하고 강화하는 것이 중요합니다.

 

취약점을 통해 발생할 수 있는 침해 시도는 다양하며, 이러한 침해에 대비하고 방어, 탐지, 모니터링하기 위한 방안을 종합적으로 구축해야 합니다. 아래는 발생할 수 있는 주요 침해 시도 유형과 이에 대응하기 위한 방안입니다.

발생할 수 있는 침해 시도

1. 권한 상승: 사용자 또는 프로세스가 시스템상에서 더 높은 권한을 부적절하게 획득하여 중요 시스템 파일 수정, 삭제 또는 생성을 시도할 수 있습니다.
2. 데이터 유출: 민감한 정보가 외부로 유출되어 개인정보 침해, 지적재산권 침해 등이 발생할 수 있습니다.
3. 서비스 거부(DoS) 공격: 시스템 리소스를 고갈시키거나 시스템을 과부하 상태로 만들어 정상적인 서비스 제공을 방해합니다.
4. 코드 실행: 원격 코드 실행(RCE) 취약점을 통해 공격자가 악의적인 코드를 시스템에 주입하고 실행할 수 있습니다.
5. 백도어 설치: 공격자가 시스템에 장기간 접근할 수 있는 백도어를 설치하여 지속적인 침해를 시도합니다.

대비/방어/탐지/모니터링 방안

대비

1. 최소 권한 원칙 적용: 모든 사용자와 시스템 프로세스에 필요한 최소한의 권한만 부여합니다.
2. 보안 교육: 사용자와 개발자를 대상으로 정기적인 보안 교육을 실시하여 보안 의식을 강화합니다.
3. 정기적인 취약점 스캔 및 패치 관리: 시스템 및 소프트웨어의 취약점을 정기적으로 스캔하고, 발견된 취약점에 대해 신속하게 패치를 적용합니다.

방어

1. 방화벽 및 침입방지시스템(IPS) 구축: 네트워크 경계에 방화벽과 IPS를 배치하여 악의적인 트래픽과 침입 시도를 차단합니다.
2. 암호화: 데이터 전송 및 저장 시 암호화를 적용하여 민감한 정보의 유출을 방지합니다.
3. 액세스 제어 정책 강화: 사용자 인증, 권한 할당, 다중 인증 방식 등을 통해 액세스 제어를 강화합니다.

탐지

1. 보안 정보 및 이벤트 관리(SIEM) 시스템 활용: 로그 데이터와 보안 경고를 실시간으로 수집, 분석하여 비정상적인 활동을 탐지합니다.
2. 침입 탐지 시스템(IDS) 배치: 네트워크 및 호스트 기반 IDS를 활용하여 의심스러운 활동이나 알려진 공격 시그니처를 탐지합니다.

모니터링

1. 정기적인 보안 감사: 외부 전문가에 의한 정기적인 보안 감사를 통해 보안 체계의 적절성을 평가하고 개선
2. 사항을 도출합니다.
3. 로그 모니터링 및 분석: 시스템 및 어플리케이션 로그를 지속적으로 모니터링하고 분석하여 비정상적인 행동이나 잠재적인 보안 위협을 식별합니다.
4. 응답 프로세스 마련: 보안 사고 발생 시 신속하게 대응할 수 있는 명확한 사고 대응 계획을 수립하고 정기적으로 훈련합니다.

위의 방안들은 종합적인 보안 프레임워크의 일부로, 조직의 구체적인 환경과 요구에 맞게 조정되어야 합니다. 취약점으로 인한 위협을 최소화하기 위해, 이러한 방안들을 체계적이고 지속적으로 적용하는 것이 중요합니다.

 

컨테이너를 실행할 때 표준 Docker 환경과 Kubernetes(K8s) 클러스터 환경 사이의 보안 설정과 기능 차이는 중요한 보안 고려 사항을 야기합니다. 특히, unshare 명령의 사용 가능 여부와 seccomp 필터의 기본 설정은 두 환경에서 크게 다르며, 이는 보안 취약성을 악용할 수 있는 기회를 제공할 수 있습니다.

표준 Docker 환경에서의 unshare 명령 차단

Docker에서는 컨테이너를 격리된 환경으로 실행하기 위해 다양한 리눅스 커널 기능을 사용합니다. unshare 명령은 프로세스가 일부 리소스(네임스페이스)를 공유하지 않도록 할 때 사용되는데, 표준 Docker 환경에서는 보안상의 이유로 이 명령의 사용이 기본적으로 제한됩니다.

 

예를 들어, 다음과 같이 Docker 컨테이너를 실행할 때 unshare 명령을 사용하려고 하면, 시스템은 이를 차단하고 "작업이 허용되지 않습니다"라는 메시지를 반환합니다.

docker run -it ubuntu:20.04 /bin/bash
root@4e22094edd46:/# unshare
unshare: unshare failed: 작업이 허용되지 않습니다.

이는 Docker가 컨테이너의 격리를 강화하고, 호스트 시스템에 대한 잠재적인 악의적인 접근을 차단하기 위해 설정한 보안 정책의 일부입니다.

Kubernetes 클러스터에서의 Seccomp 필터 비활성화

반면, Kubernetes 환경에서는 seccomp(보안 컴퓨팅 모드) 필터가 기본적으로 비활성화되어 있습니다. Seccomp 필터는 특정 시스템 호출을 허용하거나 차단하여 컨테이너의 권한을 제한하는 데 사용됩니다. 기본적으로 이 필터가 비활성화되어 있으면, 악의적인 사용자가 unshare와 같은 명령을 사용하여 컨테이너의 격리를 우회하고 시스템에 더 넓은 접근을 시도할 수 있는 여지가 생깁니다.

 

Kubernetes에서 컨테이너를 실행하고 unshare 명령을 사용할 수 있는 예는 다음과 같습니다.

kubectl run -it ubutest2 --image=ubuntu:20.04 /bin/bash
root@ubutest2:/# pscap -a

여기서 pscap -a를 통해 확인할 수 있는 프로세스의 능력(capabilities)은 해당 컨테이너가 다양한 시스템 권한을 가지고 있음을 보여줍니다. 또한, unshare 명령이 차단되지 않는 것으로부터 컨테이너가 추가적인 리소스 격리 없이 시스템 리소스를 다룰 수 있음을 알 수 있습니다.

보안 대책

• Docker 환경: Docker에서는 --security-opt 플래그를 사용하여 seccomp 프로필을 커스텀하게 적용할 수 있습니다. 이를 통해 필요한 시스템 호출만 허용하도록 설정하여 보안을 강화할 수 있습니다.
• Kubernetes 환경: Kubernetes에서는 Pod의 securityContext 설정을 통해 seccomp 프로필을 활성화하고, 필요한 경우에만 특정 시스템 호출이나 capabilities를 허용하도록 설정할 수 있습니다. 또한, PodSecurityPolicy를 사용하여 클러스터 전체의 보안 정책을 관리할 수 있습니다.

이러한 설정을 통해, 컨테이너가 실행되는 환경에 상관없이 보안을 강화하고 잠재적인 취약점을 악용하는 공격을 방지할 수 있습니다.

 

Kubernetes 클러스터에서 BuildKit과 Privilege Mode를 기본적으로 비활성화하는 정책은 보안을 강화하는 데 중요한 단계입니다. 추가로, runc의 사용과 관련하여 Privilege Mode와 non-root 실행을 표준으로 삼는 접근 방식도 보안을 높이는 데 중요한 역할을 합니다. 이러한 조치들이 보안에 미치는 영향을 정리해 보겠습니다.

BuildKit 비활성화

• Docker Engine 호환성 문제 및 표준 지원 부분에서 발생하는 이슈 회피: BuildKit은 Docker 이미지를 빌드하는 고급 기능을 제공하지만, 일부 환경에서 호환성 문제나 표준 지원 부족으로 인한 이슈가 발생할 수 있습니다. 이를 비활성화함으로써, 이러한 문제로 인한 보안 취약점이나 안정성 문제를 사전에 방지할 수 있습니다.

Privilege Mode 비활성화 및 non-root 실행

• 권한 상승 방지: Privilege Mode를 비활성화하고 non-root 사용자로 컨테이너를 실행하면, 애플리케이션의 권한 상승을 방지할 수 있습니다. 이는 공격자가 시스템에 더 깊은 접근을 시도하는 것을 제한합니다.
• 공격 범위 축소: 컨테이너가 제한된 권한으로 실행될 때, 공격자가 시스템 내에서 할 수 있는 행동이 제한됩니다. 이는 공격 범위를 축소하고, 시스템의 다른 부분에 대한 침투 가능성을 낮춥니다.
• 보안 베스트 프랙티스 준수: Kubernetes 환경에서 컨테이너를 non-root 사용자로 실행하는 것은 컨테이너 보안의 베스트 프랙티스 중 하나입니다. 이는 시스템 리소스에 대한 무분별한 접근을 방지하고, 보안을 강화합니다.

추가 보안 조치 필요성

위에서 언급한 조치들은 Kubernetes 클러스터의 보안을 강화하는 데 있어 필수적인 출발점입니다. 그러나 보안은 계층적 접근 방식을 필요로 하며, 다음과 같은 추가적인 보안 조치를 고려해야 합니다.

• 정기적인 취약점 스캔과 패치 관리: 클러스터의 모든 구성 요소에 대해 정기적으로 취약점을 스캔하고, 발견된 취약점에 대해서는 신속하게 패치를 적용합니다.
• 네트워크 정책 적용: 네트워크 정책을 통해 컨테이너 간 및 외부 네트워크와의 통신을 제한하여, 잠재적인 네트워크 공격으로부터 보호합니다.
• 시크릿 관리: Kubernetes 시크릿을 안전하게 관리하고, 민감한 정보가 평문으로 저장되거나 전송되지 않도록 합니다.
• 로깅 및 모니터링 강화: 보안 로그를 수집하고 모니터링하여, 비정상적인 행동이나 잠재적인 보안 위협을 신속하게 탐지합니다.
• 액세스 제어 강화: 역할 기반 액세스 제어(RBAC)를
• 활용하여, 사용자 및 서비스 계정의 권한을 세분화하고 제한합니다.

 

종합적으로, Kubernetes 클러스터에서의 BuildKit 비활성화와 Privilege Mode 및 non-root 실행 정책은 중요한 보안 기반을 제공합니다. 그러나 보안은 지속적인 프로세스이므로, 이러한 조치들을 기반으로 추가적인 보안 관행을 적용하고 지속적으로 보안 상태를 평가, 개선하는 것이 중요합니다.

 

최근 "Leaky Vessels"라고 명명된 컨테이너 환경의 취약점에 대한 보안 업데이트 권고가 발표되었습니다. 이 취약점들은 컨테이너의 격리 기능을 우회하여 호스트 환경에 접근할 수 있게 하며, 영향받는 소프트웨어를 사용 중인 시스템은 최신 버전으로의 업데이트가 권장됩니다.

취약점 설명 및 영향받는 도구

1. CVE-2024-21626 (runC)
   • 설명: runC에서 발생하는 내부 파일 서술자(File Descriptor) 누출 취약점입니다. 이 취약점을 통해 공격자는 컨테이너 격리를 우회하여 호스트 시스템의 파일에 접근할 수 있습니다.
   • 영향받는 버전: v1.0.0-rc93부터 v1.1.11까지
   • 해결 버전: v1.1.12
2. CVE-2024-23651, CVE-2024-23652, CVE-2024-23653 (BuildKit)
   • 설명: BuildKit 관련 취약점으로, 레이스 컨디션, 컨테이너 외부 파일 제거, 대화형 컨테이너 API에서 부적절한 권한 검증 등이 포함됩니다. 이들은 모두 BuildKit을 사용하여 소프트웨어를 빌드하고 패키징하는 과정에서 발생할 수 있는 보안 문제들입니다.
   • 영향받는 버전: v0.12.4 이하
   • 해결 버전: v0.12.5

사전 대응법 및 예방될 수 있는 보호 방법

1. 최신 버전으로 업데이트: 영향받는 도구의 취약점이 해결된 최신 버전으로 업데이트하여 취약점을 패치합니다.
2. 정기적인 보안 검사 수행: 컨테이너 이미지와 환경에 대한 정기적인 보안 검사를 수행하여 취약점을 조기에 발견하고 대응합니다.
3. 최소 권한 원칙 적용: 컨테이너와 관련된 프로세스에 필요한 최소한의 권한만 부여하여 잠재적인 보안 위협을 줄입니다.
4. 격리된 환경 강화: 컨테이너를 실행할 때 네트워크, 파일 시스템, 프로세스 등의 격리를 강화하는 설정을 적용하여 보안을 강화합니다.
5. 보안 모니터링 및 로깅: 컨테이너 활동에 대한 모니터링 및 로깅을 통해 의심스러운 행동을 식별하고 적절히 대응합니다.
6. 교육 및 인식 제고: 개발자와 운영자를 대상으로 컨테이너 보안에 대한 교육과 인식 제고 프로그램을 실시하여 보안 사고를 예방합니다.

컨테이너 환경의 보안은 지속적인 관리와 업데이트, 그리고 적절한 보안 대책의 실행을 통해 유지됩니다. "Leaky Vessels" 취약점과 같은 보안 위협에 대응하기 위해서는 시스템의 최신 상태 유지와 함께, 전반적인 보안 관행을 강화하는 것이 중요합니다.

 

Kubernetes 클러스터에서 BuildKit과 Privilege mode를 기본적으로 비활성화하는 정책은 컨테이너 보안을 강화하는 데 중요한 단계입니다. 이러한 접근 방식은 보안 취약점을 줄이고, 공격 표면을 최소화하는 데 도움이 됩니다. 그러나 보안은 다양한 계층에서의 지속적인 노력이 필요하므로, 이 정책만으로 모든 보안 이슈를 회피할 수 있다고 보장하기는 어렵습니다. 여러분의 클러스터 보안 전략이 충분한지 평가하기 위해 고려해야 할 몇 가지 중요한 요소들을 정리해 보겠습니다.

1. BuildKit 비활성화의 영향

• BuildKit은 Docker 이미지 빌드 과정의 성능을 개선하고, 새로운 기능을 제공하는 도구입니다. 그러나 여러분이 언급한 대로 Docker Engine과의 호환성 문제나 표준 지원 부분에서 이슈가 있을 수 있으며, 특히 보안 취약점이 발견될 가능성이 있습니다. BuildKit을 사용하지 않음으로써, 이러한 문제로부터 자유로울 수 있지만, 동시에 BuildKit이 제공하는 성능 개선이나 기능상의 이점을 누리지 못하게 됩니다.

2. Privileged Mode 비활성화의 중요성

• Privileged Mode를 비활성화하면, 컨테이너가 호스트 시스템에 대한 광범위한 접근 권한을 획득하는 것을 방지할 수 있습니다. 이는 컨테이너가 시스템 리소스에 대한 제어를 넘어서서 임의의 시스템 호출을 수행하는 것을 막아, 보안을 크게 강화합니다.

3. Non-root 사용자 실행

• Non-root 사용자로 컨테이너를 실행하는 것은 컨테이너가 시스템에 미칠 수 있는 영향을 제한합니다. 이는 특히 컨테이너 내부에서 발생할 수 있는 잠재적 보안 위협을 줄이는 데 효과적입니다.

추가적인 보안 조치

위에서 언급한 정책들은 기본적인 보안을 강화하지만, 보다 포괄적인 보안 전략을 위해 다음과 같은 추가 조치를 고려해야 합니다.

1. 네트워크 폴리시 적용: 클러스터 내에서의 통신을 제어하여 불필요한 네트워크 접근을 차단합니다.
2. Pod Security Policy (PSP) 또는 그 후속 기능 사용: 컨테이너가 실행될 때 준수해야 하는 보안 관련 조건을 정의합니다.
3. 시크릿 관리: 민감한 정보는 Kubernetes Secrets나 외부 시크릿 관리 도구를 통해 안전하게 관리합니다.
4. 정기적인 취약점 스캔 및 업데이트: 이미지와 클러스터의 취약점을 정기적으로 스캔하고, 발견된 취약점을 신속하게 패치합니다.
5. 감사 로그 및 모니터링: 시스템의 변경 사항이나 의심스러운 활동을 추적하기 위해 로그를 수집하고 모니터링합니다.

종합적으로, Kubernetes 클러스터의 보안은 다층적인 접근 방식을 필요로 하며, 단일 정책이나 설정만으로는 충분하지 않습니다. BuildKit과 Privileged Mode를 비활성화하는 것은 좋은 시작점이지만, 지속적인 관리, 업데이트, 그리고 보안 관행의 실행이 필요합니다.