Kubernetes v1.37, 컨테이너 스토리지 보안 강화 기능 도입

새로운 보안 기능 도입

Kubernetes v1.37은 컨테이너 스토리지의 보안을 강화하기 위한 두 가지 중요한 기능을 도입한다. 첫째, `emptyDir` 볼륨에 대한 권한 모드 설정 기능이 추가되었다. 둘째, 볼륨 마운트에 `noexec`, `nosuid`, `nodev`와 같은 리눅스 바인드 마운트 옵션을 적용할 수 있게 되었다. 이 기능들은 애플리케이션 개발자와 보안 전문가가 복잡한 우회 방법 없이 Kubernetes 내에서 직접 엄격한 보안 정책을 구현하도록 돕는다.

이러한 개선 사항은 컨테이너 간 파일 삭제 금지나 쓰기 가능한 볼륨에서 임의 바이너리 실행 금지와 같은 보안 요구사항을 충족하는 데 기여한다. 특히 `emptyDir` 볼륨은 가장 흔히 사용되는 쓰기 가능한 볼륨 유형으로, 이번 업데이트를 통해 그동안 지적되어 온 보안 취약점들이 해결될 전망이다.

기존 보안 취약점과 배경

이전 Kubernetes 버전에서는 컨테이너 런타임과 kubelet이 볼륨을 컨테이너에 바인드 마운트할 때 기본적으로 `noexec`, `nosuid`, `nodev` 플래그를 적용하지 않았다. 이로 인해 컨테이너의 루트 파일 시스템이 읽기 전용(`readOnlyRootFilesystem: true`)으로 설정되어 있더라도, 공격자가 쓰기 가능한 볼륨(예: `emptyDir`, `PersistentVolume`)을 통해 악성 바이너리를 다운로드하고 실행할 수 있는 보안 허점이 존재했다. 이는 여러 보안 감사에서 지적된 문제였다.

`emptyDir` 볼륨은 특히 이러한 보안 공백이 두드러진 부분이었다. Kubernetes 1.24 보안 감사(NCC-E003660-7HM)에서는 `emptyDir`에 `noexec`를 마운트할 수 없는 점이 보안 실패로 명시되었다. 또한, `emptyDir` 볼륨은 기본적으로 `0777` 모드로 디렉터리를 생성하여, 볼륨을 발견할 수 있는 모든 프로세스가 소유자와 관계없이 볼륨 내의 모든 파일을 읽고 쓰고 삭제할 수 있었다. 이는 다중 컨테이너 파드에서 한 컨테이너가 다른 컨테이너의 파일을 삭제하는 것을 막을 수 없게 만들었다.

일부 애플리케이션과 보안 프레임워크는 `/tmp` 디렉터리에 스티키 비트(`01777` 모드)가 설정되기를 요구하지만, `emptyDir` 볼륨은 이를 기본적으로 지원하지 않았다. 이로 인해 개발자들은 `init container`를 사용하여 `chmod` 명령을 실행하거나 다른 볼륨 유형을 사용하는 등 복잡한 우회 방법을 사용해야 했다. `PersistentVolume`의 `mountOptions` 필드는 파일 시스템 수준에서 CSI 드라이버에 의해 적용되는 옵션으로, 컨테이너 내부의 바인드 마운트 플래그로 안정적으로 변환되지 않는 한계도 있었다.

구체적인 기능 및 설정

새로운 `bindMountOptions` 필드를 통해 파드 매니페스트에서 볼륨 마운트에 `noexec`, `nosuid`와 같은 옵션을 직접 지정할 수 있다. 예를 들어, `/tmp`에 마운트되는 `emptyDir` 볼륨에 `bindMountOptions: [noexec, nosuid]`를 설정하여 해당 볼륨에서 실행 파일 실행 및 특수 권한 비트 적용을 방지할 수 있다. 이는 `securityContext`의 `readOnlyRootFilesystem: true`와 함께 사용될 때 더욱 강력한 보안을 제공한다.

`emptyDir` 볼륨에는 `mode` 필드가 추가되어 디렉터리 생성 시 유닉스 권한 모드를 지정할 수 있다. `mode: 01777`을 설정하면 전통적인 유닉스 `/tmp` 디렉터리처럼 스티키 비트가 적용되어, 파일 소유자 또는 루트 사용자만이 해당 파일을 삭제하거나 이름을 변경할 수 있게 된다. 또한, `mode: 0750`과 같이 특정 사용자 및 그룹에게만 읽기/쓰기 권한을 부여하여 최소 권한 원칙을 적용할 수 있다.

이러한 기능의 적용 여부는 `kubectl exec`를 통해 컨테이너 내부에서 확인할 수 있다. `noexec`가 적용된 볼륨에서는 실행 스크립트 생성이 가능해도 실행 시 'Permission denied' 오류가 발생한다. `01777` 모드가 적용된 `emptyDir`에서는 다른 사용자가 생성한 파일을 삭제하려 할 때 'Operation not permitted' 오류가 발생하여 스티키 비트의 동작을 검증할 수 있다.

개발자 및 사용자 영향

이러한 기능들은 애플리케이션 개발자와 보안 엔지니어가 애플리케이션의 보안 태세를 강화하고 워크로드가 인프라에 위험을 초래하지 않도록 하는 데 중요한 역할을 한다. 임시 작업 공간(`emptyDir` 또는 `/tmp` 마운트)에 `nosuid` 및 `noexec`를 적용함으로써, 애플리케이션이 침해되더라도 악성 페이로드를 실행하거나 노드에서 권한을 에스컬레이션하는 것을 방지할 수 있다.

다중 컨테이너 파드에서 공유 스크래치 공간을 구성할 때 `emptyDir`에 `mode: 01777`을 설정하면, 각 컨테이너가 독립적으로 파일을 작성하면서도 한 컨테이너의 침해된 프로세스가 다른 컨테이너가 생성한 빌드 아티팩트를 삭제하는 것을 막을 수 있다. 또한, 데이터베이스 파드와 같이 민감한 임시 저장소에 `mode: 0750`을 설정하여 특정 데이터베이스 사용자 및 그룹만 볼륨에 접근하도록 제한함으로써 최소 권한 원칙을 효과적으로 적용할 수 있다.

결과적으로, 개발팀은 `init container`를 이용한 복잡한 우회 방식 대신 Kubernetes의 네이티브 기능을 활용하여 보안 벤치마크 및 정책을 준수하는 방식으로 볼륨 마운트를 강화할 수 있게 되었다. 이는 보안 정책 구현의 복잡성을 줄이고 규정 준수를 용이하게 한다.

적용 조건 및 한계

`bindMountOptions`를 사용하려면 컨테이너 런타임이 CRI `mount_options` 필드를 지원하고 `runtimeFeatures`를 통해 이를 알려야 한다. 스케줄러는 노드가 선언한 기능을 사용하여 호환되지 않는 노드에 파드가 배치되는 것을 방지하며, 만약 파드가 지원되지 않는 노드에 도달하면 kubelet은 이를 거부하고 자동으로 무시하지 않는다. 반면, `emptyDir`의 `mode` 필드 사용은 런타임 지원을 요구하지 않는다.

기존 `PersistentVolume`의 `mountOptions`는 스토리지 계층에서 CSI 드라이버를 통해 적용되는 반면, 새로운 `bindMountOptions`는 컨테이너 내부에서 런타임에 의해 적용되는 바인드 마운트 플래그를 제어한다. 이들은 서로 다른 계층에서 작동하며 충돌하지 않는다. 또한, 파드의 `securityContext`에 `fsGroup`이 설정된 경우, `fsGroup`에 의해 적용되는 그룹 권한이 `emptyDir` 볼륨에 지정된 `mode`를 재정의할 수 있다.

`noexec`, `nosuid`, `nodev`와 같은 플래그 및 유닉스 권한 모드는 리눅스 개념이므로, `bindMountOptions`는 Windows 노드에서는 효과가 없다. `emptyDir` 볼륨의 `mode` 필드 또한 Windows에서는 유닉스 스타일 파일 권한을 지원하지 않으므로 무시된다. 버전 불일치 상황에서 `emptyDir mode`는 API 서버에서 활성화되었지만 kubelet에서 비활성화된 경우 필드는 수락되지만 무시되고 기본값인 `0777`로 대체된다. `bindMountOptions`의 경우, 스케줄러가 런타임 지원이 없는 노드에 파드를 배치하지 않으며, 만약 파드가 그러한 노드에 도달하면 kubelet은 옵션을 무시하지 않고 파드를 거부한다.