[Kubernetes] 파드를 보다 안전하게 - SecurityContext

 

쿠버네티스 보안 관련 모범 사례를 살펴보면 아마 가장 기본적이고, 가장 많이 보이는 것이 하나 있습니다. 아마 쿠버네티스 뿐만 아니라 컨테이너를 사용하는 환경이라면 모두가 신경써야 하는 부분이죠.

 

바로 루트 계정 비활성화 입니다.

즉, 컨테이너 내 프로세스에서 루트 권한을 모두 비활성화 하는 것이죠.

 

컨테이너 내부에서 아무나 루트 권한을 사용하게 한다는 것은 모르는 사람에게 집 비밀번호를 알려주는 것과 다름이 없습니다.

예를 들어 컨테이너에 접속한 후 uname -a 명령어를 쳐보면 호스트의 OS 버전을 볼 수 있습니다. 

 

루트 권한 비활성화는 이미지를 만들 때도 설정할 수 있고, k8s 로 파드를 배포할 때도 설정할 수 있습니다.

 

이번 글에서는 어떻게 루트 계정을 비활성화하고 안전한 파드를 만드는지 알아보고자 합니다.

Dockerile 을 작성할 때 보안 관련 옵션들은 따로 설정하지 않습니다.

예를 들면 USER 1000 

 

렛츠두더코드~

 

 

SecurityContext

---

k8s pod spec 으로 securityContext 라는 필드가 있습니다. 파드 내 모든 보안 설정은 이 필드 내에서 설정이 가능합니다. 

설명하는 것보다 한번 보는 게 훨씬 나으니 바로 한번 보시죠.

이미지를 만들 때의 보안은 신경쓰지 않습니다

 

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  volumes:
    - name: data-log
      emptyDir: {}
  containers:
    - name: secure-pod
      imagePullPolicy: Always
      image: kingbj0429/busybox:1.28
      volumeMounts:
        - name: data-log
          mountPath: /data/log
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        privileged: false
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: false
        capabilities:
          add: [ "NET_ADMIN", "SYS_TIME" ]

 

Dockerfile

FROM amd64/ubuntu:20.04

RUN apt update \
    && apt install -y sudo \
    && apt install -y libcap2-bin \
    && chmod 4755 /bin/cat \
    && useradd -s /bin/sh -u 1000 user

CMD ["/bin/sh", "-c", "sleep 1d"]

 

 

우선 Dockerfile 부터 하나하나 알아보죠.

 

sudo 패키지는 pod.yaml 에서 .allowPrivilegeEscalation 를 false 와 true 을 주었을 때 각각 어떻게 동작하는 지 확인하기 위함입니다. 

 

libcap2-bin 패키지는 .capabilities[] 를 확인하기 위함입니다.

 

그리고 chmod 4755 /bin/cat 은 /bin/cat 바이너리에 set uid 를 지정함으로써 .allowPrivilegeEscalation 가 어떻게 동작하는 지 확인하기 위함입니다. 

 

setuid 는 파일의 owner 권한을 빌려 실행하는 기능입니다.
만약 어느 파일의 권한이 4755 라면 owner 가 아닌 사용자는 owner 의 권한을 빌려 파일을 실행할 수 있습니다.

이외 setgid(2), sticky bit(1) 도 존재합니다.

 

마지막으로 루트 계정과 비교하기 위한 uid 1000 의 user 계정을 생성합니다.

 

 

그럼 이제 pod.yaml 에 대해 알아보죠. 

.securityContext 의 더 많은 옵션이 궁금하다면 여기, .securityContext 자체가 궁금하다면 여기!

 

.runAsNonRoot: true 로 하게 되면, 만약 루트 계정으로 파드를 실행 시 에러를 토해냅니다.

.runAsUser: 1000 로 하게 되면, 파드를 1000 계정으로 실행합니다. 만약 0 으로 하게되면 루트 계정이므로 위에 .runAsNonRoot: true 으로 인해 파드 생성이 안됩니다.

 

.runAsGroup: 1000 로 하게되면 파드는 1000 gid 를 가진 그룹에 포함됩니다.

 

나머지 옵션들에 대해선 좀 더 자세히 알아보죠.

 

.privileged 옵션은 파드를 실행하는 사용자에게 root 와 같은 권한을 사용할 수 있게 해줍니다. 즉, sudo 와 같은 명령어 사용이 가능하며, 루트 권한을 가질 수 있게 됩니다.

 

.privileged: false 일 경우

 

capsh --print 를 통해 어느 privileged 가 할당되었는 지 확인할 수 있죠.

 

만약 privileged 가 true 이면, .allowPrivilegeEscalation 과 .capabilities[] 의 옵션을 무의미해지며, .allowPrivilegeEscalation 를 false 로 준다면 파드 생성 시 에러가 발생합니다.

 

.capabilities[] 옵션은 사용자에게 특정 capability 를 주는 옵션인데 privileged 가 true 라면 이미 모든 capability 를 할당받았기 때문에 의미가 없겠죠?

 

.capabilities[] 에 [ "NET_ADMIN", "SYS_TIME" ] 을 주었는 데 이럴 경우 루트 계정으로 파드의 Date 를 변경할 수 있게 됩니다.

 

루트가 아니라면 .capabilities[] 을 주어도 capability 를 가지고 어떠한 액션을 할 순 없습니다.

 

 

.allowPrivilegeEscalation

 

.allowPrivilegeEscalation 에 대해 좀 더 알아보죠. .allowPrivilegeEscalation 가 사실 이번 글의 핵심이라고 볼 수 있습니다.

.allowPrivilegeEscalation 은 권한 상승을 선택하는 옵션입니다. 만약 false 라면 권한 상승을 통해 프로세스를 실행할 수 없죠.

 

근데 이렇게 글로만 봐서는 잘 이해가 안가니 바로 실습을 해보죠.

 

우선 .allowPrivilegeEscalation 을 true 로 해보겠습니다. 아까 위 Dockfile 을 보면 chmod 4755 를 통해 cat 바이너리에 set uid 를 설정했습니다. set uid 를 통해 권한 상승을 테스트할 수 있습니다.

 

cat 바이너리를 보면 set uid 가 설정되어 있습니다. 

stat /bin/cat

 

그리고 cat /etc/shadow 를 실행해보겠습니다.

stat /etc/shadow

 

cat 명령어는 부모의 권한을 빌릴 수 있으므로 cat /etc/shadow 가 정상적으로 출력됩니다.

cat /etc/shadow

 

shadow 파일은 640 이기 때문에 root 가 아니거나 해당된 그룹에 있는 사용자가 아니라면 접근이 불가능해야 합니다.

하지만, .allowPrivilegeEscalation 을 true 로 줌으로써 권한 상승을 할 수 있게 해주었고, set uid 또한 설정되었기 때문에 root 가 아니여도 접근이 가능합니다.

 

하지만!

.allowPrivilegeEscalation 을 false 를 준다면, cat 바이너리에 set uid 가 설정되어 있다 할지라도 cat /etc/shadow 를 실행할 수 없습니다. 왜냐 권한 상승을 막았기 때문이죠.

cat /etc/shadow

 

sudo 또한 set uid 가 설정되어있고, root 권한을 빌리는 것이기 때문에 .allowPrivilegeEscalation 을 false 로 준다면 sudo 는 사용할 수 없게 됩니다.

stat /usr/bin/sudo

 

이제 .allowPrivilegeEscalation 옵션에 대해 감이 오시죠?

 

그럼 다음으로는 또 중요한 옵션 중 하나인 .readOnlyRootFileSystem 에 대해 알아보죠.

 

 

.readOnlyRootFileSystem

 

이름 그대로 파일 시스템에 read 만 가능합니다. 따라서 파일들을 읽을 순 있지만, 쓸 수는 없어요.

보안을 생각해보면 당연히 파드 내 파일을 수정할 수 없게 하는 것이 맞겠죠?

 

그런데 한가지 문제가 있습니다. 로그를 출력해주는 애플리케이션이 있다고 가정해보죠. 로그는 /data/log 에 저장됩니다.

하지만 .readOnlyRootFileSystem 을 true 한다면 루트가 아닌 이상 /data/log 에 무언가를 쓸 수 없습니다.

 

즉, touch /data/log/log.text 가 불가능합니다. .runAsNonRoot 가 true 이기 때문에 루트로 접근할 수도 없습니다.

touch text

 

그럼 이럴 경우 어떻게 해야 할까요?

 

바로 emptyDir 를 사용하면 이 문제를 해결할 수 있습니다.

emptyDir 은 같은 파드 내 존재하는 컨테이너끼리 볼륨을 공유할 때 사용되는 옵션입니다. 여기서 한가지 알아야 할 것은 이 볼륨이 마운트 될 때 tmpfs 로 마

운트된 다는 것이죠.

 

아무나 이 마운트 경로에는 읽거나 쓸 수 있습니다.

df -h

 

특별히 권한을 주지 않았는데 777 로 설정되어 있는 것을 확인할 수 있습니다.

stat /data/log

 

만약 busybox:1.28 에서 로그를 쓰고 싶다면 /data/log 경로를 .volumeMounts 해주면 됩니다.

 

 

마무리

---

pod 를 배포할 때 신경써야 할 아주 기본적인 보안을 설정해보았는데요. 크게 어렵지 않습니다.

 

그리고 pod.yaml 보단 애초에 이미지를 만들 때 보안을 신경써서 만드는 것이 더 일반적입니다.

 

그래도 pod.yaml 의 securitContext 를 통해 보안을 강화한 파드 배포 방법에 대해 알아봤습니다.

 

위에 나와있는 옵션 말고도 더 다양한 securityContext 옵션들이 존재하며, AppArmor 나 Falco, Trivy, OPA GateKeeper 를 통해서 쿠버네티스 보안을 더 강화할 수 있습니다.

 

이에 대해선 나중에 차근차근 알아보도록 하죠!

 

그럼 오늘은 여기까지!