Linux Capabilities를 사용한 컨테이너 권한 제어

From_A_To_Z·2024년 3월 20일

01. Linux Capabilites

Linux capabilities는 프로세스가 특정 권한을 가질 수 있도록 하는 보안 기능
기존의 전통적인 Unix 권한 모델은 사용자가 root 권한을 갖거나 아니면 일반 사용자 권한만을 갖는 두 가지 선택지가 가능 → 일부 시스템 관리 작업이나 프로그램 실행에 있어서 불필요한 보안 위험을 초래할 수 있음
Linux capabilities는 더 세분화된 권한을 제공하여 이러한 문제를 해결
각 프로세스는 특정 능력을 부여받을 수 있으며, 이를 통해 일반 사용자 권한과 root 권한 사이의 중간 지점을 만들어낼 수 있음
기본적으로 각각의 능력은 특정한 시스템 작업에 대한 권한을 나타내며, 각 프로세스에 부여되거나 제한될 수 있음.

예시
CAP_CHOWN: 파일 소유자 변경 가능
CAP_DAC_OVERRIDE / CAP_DAC_READ_SEARCH: 파일 접근 제어 권한 무시 가능
CAP_NET_BIND_SERVICE: 낮은 포트(0~1023)에 바인딩 가능
CAP_SYS_ADMIN: 시스템 관리 작업 수행 가능

02. Linux Capabilites in Kubernetes

Kubernetes에서는 Linux Capabilites를 통해 루트 사용자의 모든 권한을 부여하지 않고 컨테이너 프로세스에 특정 권한을 부여 (add)하거나 제거 (drop)할 수 있음
참고: Linux Capabilities의 형식은 CAPXXX으로 되어 있음. 그러나 Kuberentes Manifest에 기능을 적용할 때는 CAP상수 부분을 생략해야 함. 예를 들어 CAP_SYS_TIME을 추가하려면 SYS_TIME으로 설정 필요

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

별도 권한을 설정하지 않을 경우, 컨테이너 런타임 (e.g. cri-o, runc, docker)에서 정의한 기본 권한 설정이 적용됨 (https://github.com/opencontainers/runc/blob/main/libcontainer/SPEC.md)

출처: https://learn.snyk.io/lesson/container-does-not-drop-all-default-capabilities/

기본 Linux Capabilities 설정

$ cat /proc/1/status
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
...
 
$ capsh --decode=00000000a80425fb
0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

모든 Linux Capabilities 추가

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: all

$ cat /proc/1/status
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
CapAmb: 0000000000000000
...
 
$ capsh --decode=0000001fffffffff
0x0000001fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,35,36

모든 Linux Capabilities 제거

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        drop: all

$ cat /proc/1/status
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000000000000000
CapAmb: 0000000000000000
...
 
$ capsh --decode=0000000000000000
0x0000000000000000=

테스트 (date - 시간변경)

(1) root 계정 / CAP_SYS_TIME 추가

# date
Mon Nov 20 16:16:08 KST 2023
# date -s '19 APR 2012 22:00:00'
Thu Apr 19 22:00:00 KST 2012
# date
Thu Apr 19 22:00:02 KST 2012

(2) root 계정 / CAP_SYS_TIME 제거

# date
Mon Nov 20 16:34:47 KST 2023
# date -s '19 APR 2012 22:00:00'
date: cannot set date: Operation not permitted
Thu Apr 19 22:00:00 KST 2012
# date
Mon Nov 20 16:35:23 KST 2023

(3) 일반 사용자 계정 / CAP_SYS_TIME 추가

$ date
Mon Nov 20 16:12:48 KST 2023
$ date -s '19 APR 2012 22:00:00'
date: cannot set date: Operation not permitted
$ date
Mon Nov 20 16:12:48 KST 2023

→ Super User 계정이면서 CAP_SYS_TIME 기능이 추가된 경우에만 시간 변경 가능

이슈: 기능 제거 이후에도 정상 동작

chmod 관련 linux capabilities 기능 추가 이후에도 컨테이너의 유저가 non super user일 경우, 권한 이슈로 명령 실패

$ ls -l
total 72
drwxr-xr-x 2 root root  4096 Nov 20 15:02 function
drwxr-xr-x 1 root root  4096 Sep 15 13:28 node_modules
-rw-r--r-- 1 root root 61168 Sep 15 13:28 package-lock.json
-rw-r--r-- 1 root root   476 Sep 15 13:28 package.json
$ chmod 755 package.json
chmod: changing permissions of 'package.json': Operation not permitted
$ chown root package.json
chown: changing ownership of 'package.json': Operation not permitted
$ ls -l
total 72
drwxr-xr-x 2 root root  4096 Nov 20 15:02 function
drwxr-xr-x 1 root root  4096 Sep 15 13:28 node_modules
-rw-r--r-- 1 root root 61168 Sep 15 13:28 package-lock.json
-rw-r--r-- 1 root root   476 Sep 15 13:28 package.json

반대 케이스로 chmod 관련 linux capabilities 기능을 제거하였어도 super user일 경우, 명령 성공

# ls -l
total 72
drwxr-xr-x 2 root root  4096 Nov 20 15:02 function
drwxr-xr-x 1 root root  4096 Sep 15 13:28 node_modules
-rw-r--r-- 1 root root 61168 Sep 15 13:28 package-lock.json
-rw-r--r-- 1 root root   476 Sep 15 13:28 package.json
# chmod 755 package.json
# chown functionuser package.json
chown: changing ownership of 'package.json': Operation not permitted
# ls -l
total 72
drwxr-xr-x 2 root root  4096 Nov 20 15:02 function
drwxr-xr-x 1 root root  4096 Sep 15 13:28 node_modules
-rw-r--r-- 1 root root 61168 Sep 15 13:28 package-lock.json
-rwxr-xr-x 1 root root   476 Sep 15 13:28 package.json

프로세스에 Linux Capabilities 기능이 부여되어 있더라도 무조건적으로 사용 가능한 것은 아님. 반대로 Linux Capabilities 기능이 없더라도 Super User (root)라면 명령 실행이 가능한 경우도 있음
(https://unix.stackexchange.com/questions/229552/what-permissions-one-needs-to-run-chmod-chown-command-on-a-folder-item)

03. 결론

Linux Capabilities 기능 설정도 중요하지만 해당 기능 설정만으로는 특정 OS 실행 파일에 대한 명령 실행을 제어할 수 없음
기존 런타임의 유저 설정 및 실행 권한 설정 (e.g. /bin)이 중요
Security Context의 runAsUser, runAsNonRoot 설정을 추가하여 지정된 유저로만 명령 실행 가능하도록 설정하는 것이 중요함.

From_A_To_Z

What goes around comes around.

이전 포스트

인터넷 프로토콜 정리 (HTTP, ICMP, AMQP, RMCP)

다음 포스트