이 페이지에서는 Google Kubernetes Engine(GKE)의 Linux 보안 컴퓨팅 모드(seccomp)에 대한 정보를 제공합니다. 이 정보를 통해 컨테이너화된 애플리케이션이 노드를 지원하는 호스트 가상 머신(VM)에서 수행 가능한 작업을 파악할 수 있습니다.
seccomp란?
보안 컴퓨팅 모드(seccomp)는 Linux 커널에서 프로세스가 수행 가능한 시스템 호출(syscall)을 제한할 수 있는 Linux의 보안 기능입니다.
기본적으로 GKE 노드는 containerd 컨테이너 런타임과 함께 Container-Optimized OS 운영체제를 사용합니다. containerd는 허용된 Linux 기능을 기본 목록으로 제한함으로써 Linux 커널을 보호하고, seccomp 프로필로 허용된 syscall을 추가로 제한할 수 있습니다. containerd에는 사용 가능한 기본 secomp 프로필이 있습니다. GKE에서 기본 seccomp 프로필을 적용하는지 여부는 다음과 같이 사용하는 클러스터 모드에 따라 다릅니다.
- Autopilot(권장): GKE는 containerd 기본 seccomp 프로필을 모든 워크로드에 자동으로 적용합니다.
- Standard: GKE는 containerd 기본 seccomp 프로필을 모든 워크로드에 자동으로 적용하지 않습니다. 워크로드에 기본 seccomp 프로필 또는 맞춤 seccomp 프로필을 적용하는 것이 좋습니다.
기본 containerd seccomp 프로필은 대부분의 워크로드와의 호환성을 유지하면서 기준 강화를 제공합니다. containerd에 대한 전체 seccomp 프로필 정의는 GitHub에서 확인할 수 있습니다.
Linux 기능 및 syscall
Linux 시스템에서 실행되는 루트가 아닌 프로세스는 루트 사용자로 작업을 수행하려면 특정 권한이 필요할 수 있습니다. Linux는 사용 가능한 권한을 그룹으로 나누는 기능을 사용하므로 루트가 아닌 프로세스가 모든 권한을 부여받지 않고도 특정 작업을 수행할 수 있습니다. 프로세스에서 특정 syscall을 성공적으로 수행하려면 해당 프로세스에 기능에 의해 부여된 해당 권한이 있어야 합니다.
모든 Linux 기능 목록은 기능을 참조하세요.
기본 GKE seccomp 프로필에서 거부된 syscall
containerd 기본 seccomp 프로필은 모든 syscall을 차단한 후 특정 syscall을 선택적으로 허용하며 이 중 일부는 노드의 VM과 커널 버전의 CPU 아키텍처에 따라 달라집니다. DefaultProfile 함수의 syscalls 변수는 모든 아키텍처에 허용되는 syscall을 나열합니다.
기본 seccomp 프로필은 컨테이너 격리 경계를 우회하고 노드 또는 다른 컨테이너에 대한 권한 있는 액세스를 허용하는 데 사용할 수 있는 syscall을 차단합니다. 다음 표에는 기본 seccomp 프로필이 거부되는 일부 중요한 syscall에 대한 설명이 나와 있습니다.
| 거부된 syscall | |
|---|---|
mount, umount, umount2,
fsmount, mount_setattr |
프로세스에서 컨테이너 경계 외부의 노드 파일 시스템에 액세스하거나 조작할 수 없도록 제한합니다. 또한 |
bpf |
프로세스가 커널에서 eBPF 프로그램을 만들 수 없도록 제한하여 노드에서 권한 에스컬레이션이 발생할 수 있습니다. 예를 들어 CVE-2021-3490은 또한 |
clone, clone3, unshare |
컨테이너의 제한된 네임스페이스 외부에 있을 수 있는 새 네임스페이스에서 새 프로세스를 만들지 못하도록 프로세스를 제한합니다. 이러한 새 프로세스에는 승격된 권한 및 기능이 포함될 수 있습니다. 예를 들어 CVE-2022-0185는 또한 |
reboot |
프로세스에서 노드를 재부팅할 수 없도록 제한합니다. 또한 |
open_by_handle_at, name_to_handle_at |
컨테이너 외부의 파일에 대한 액세스를 제한합니다. 이러한 syscall은 초기 Docker 컨테이너 이스케이프 악용 중 하나에서 사용되었습니다. 또한 |
GKE에서 seccomp를 사용하는 방법
Autopilot 클러스터에서 GKE는 containerd 기본 seccomp 프로필을 모든 워크로드에 자동으로 적용합니다. 추가 조치는 필요하지 않습니다. 제한된 syscall을 수행하려고 시도하면 실패합니다. GKE가 노드를 관리하므로 Autopilot에서는 맞춤 seccomp 프로필을 허용하지 않습니다.
Standard 클러스터에서는 seccomp 프로필을 수동으로 적용해야 합니다. GKE가 프로필을 적용하지 않습니다.
Standard 클러스터에서 seccomp 사용 설정
다음 예시와 같이 포드 사양의 spec.securityContext.seccompProfile 필드를 사용하여 포드 또는 컨테이너 보안 컨텍스트를 설정하여 seccomp 프로필을 수동으로 적용합니다. 사용 사례에서 제한된 syscall을 사용해야 하는 경우가 아니라면 워크로드에 seccomp 프로필을 사용하는 것이 좋습니다. 지원되는 두 가지 seccompProfile 유형은 다음과 같습니다.
RuntimeDefault: containerd 런타임에서 지정된 기본 프로필입니다.Localhost: 맞춤 프로필 정의입니다.
다음 예시 매니페스트는 seccomp 프로필을 런타임 기본 프로필로 설정합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
labels:
app: default-pod
spec:
replicas: 3
selector:
matchLabels:
app: default-pod
template:
metadata:
labels:
app: default-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: seccomp-test
image: nginx
이 매니페스트를 배포할 때 포드의 컨테이너가 런타임 기본 seccomp 프로필을 위반하는 syscall을 수행하려고 하면 포드 또는 워크로드에 예기치 않은 동작이 발생할 수 있습니다. 예를 들어 시작 중에 제한된 syscall을 수행하는 포드는 시작되지 않습니다. 포드가 실행되는 동안 애플리케이션이 제한된 syscall을 수행하려고 하면 컨테이너에 오류가 표시될 수 있습니다. 실패한 syscall의 심각도는 애플리케이션이 오류를 처리하는 방법에 따라 다릅니다.
Standard 클러스터에서 맞춤 seccomp 프로필 사용
런타임 기본 seccomp 프로필이 애플리케이션에 너무 제한적인 경우(또는 충분히 제한적이지 않은 경우) Standard 클러스터의 포드에 커스텀 seccomp 프로필을 적용할 수 있습니다. 이 프로세스에는 노드의 파일 시스템에 대한 액세스 권한이 필요합니다. 맞춤 seccomp 프로필을 로드하고 사용하는 방법에 관한 튜토리얼은 seccomp로 컨테이너의 Syscall 제한을 참고하세요.