🤔 allowPrivilegeEscalation: false - 쓰기만 하면 정말 안전할까? (privileged: true와 완벽 비교)

안녕하세요! 쿠버네티스 보안 설정을 다루다 보면 securityContext 필드에서 비슷한 이름의 두 옵션, allowPrivilegeEscalation과 privileged를 마주하게 됩니다. 둘 다 권한과 관련된 것 같아 헷갈리기 쉽죠.

 

"그냥 둘 다 false로 두면 가장 안전한 거 아니야?" 라고 생각할 수도 있지만, 이 둘의 정확한 역할을 이해하면 훨씬 더 정교하고 안전한 보안 정책을 수립할 수 있습니다. 🔒

 

오늘은 allowPrivilegeEscalation: false가 정확히 어떤 역할을 하는지, 그리고 가장 강력한 옵션인 privileged: true와는 무엇이 다른지 속 시원하게 파헤쳐 보겠습니다!

 

---

1. allowPrivilegeEscalation: false - 내부 권한 상승 차단기 🛡️

이 옵션의 핵심은 컨테이너 내부에서 실행된 프로세스가 부모 프로세스보다 더 많은 권한을 획득하는 것을 막는 것입니다.

조금 어렵나요? 비유를 들어보겠습니다.

평사원(자식 프로세스)이 회사에 입사(컨테이너 실행)했습니다. 그런데 이 평사원이 회사 내부의 비밀 통로(setuid 바이너리)를 이용해 갑자기 사장(root) 권한을 얻으려고 시도합니다. allowPrivilegeEscalation: false는 바로 이 비밀 통로를 이용한 '내부 승진'을 원천 차단하는 보안 요원과 같습니다.

어떻게 작동하나요?

이 설정은 리눅스 커널의 no_new_privs 플래그를 제어합니다. allowPrivilegeEscalation: false로 설정하면, 해당 컨테이너에서 실행되는 모든 프로세스에 no_new_privs 플래그가 활성화됩니다. 이 플래그가 켜지면, execve() 시스템 콜을 통해 다른 프로그램을 실행하더라도 UID나 GID를 변경하는 것(예: setuid, setgid 비트가 설정된 파일 실행)이 금지됩니다.

간단한 예시: 컨테이너가 appuser(UID 1000)로 실행 중이라고 가정해 봅시다.

• allowPrivilegeEscalation: true (기본값): 컨테이너 내부에 sudo나 passwd처럼 setuid가 설정된 파일이 있다면, appuser는 이 파일을 실행하여 컨테이너 내부의 root(UID 0) 권한을 획득할 수 있습니다.
• allowPrivilegeEscalation: false: appuser가 같은 파일을 실행하더라도, 커널이 권한 변경을 막아버립니다. 결국 프로세스는 root가 되지 못하고, 권한 상승 시도는 실패합니다.

즉, 이 옵션은 컨테이너가 시작된 권한 그대로만 작동하도록 강제하는 역할을 합니다.

---

2. privileged: true - 호스트 권한 마스터키 🔑

privileged: true는 allowPrivilegeEscalation과는 차원이 다른 이야기입니다. 이 옵션은 컨테이너와 호스트(Node) 사이의 모든 보안 경계를 허물어 버립니다.

아까의 비유를 다시 사용해 볼까요? privileged: true는 평사원에게 회사 건물 전체의 마스터키를 줘버리는 것과 같습니다. 회사 내부의 어떤 방이든 열 수 있고, 서버실, 사장실 등 모든 곳에 접근할 수 있게 됩니다.

어떤 일이 일어나나요?

privileged: true로 설정된 컨테이너는 다음과 같은 막강한 권한을 갖습니다.

• 호스트의 모든 장치(/dev)에 접근할 수 있습니다.
• Seccomp, AppArmor 등 컨테이너를 격리하는 모든 리눅스 보안 프로파일이 비활성화됩니다.
• 호스트 커널의 모든 capabilities를 획득합니다.

사실상 컨테이너가 아닌, 호스트에서 직접 실행되는 프로세스와 거의 동일한 권한을 갖게 되는 것입니다. 따라서 이 옵션은 CNI 플러그인이나 스토리지 드라이버처럼 호스트 레벨의 제어가 반드시 필요한 시스템 데몬 외에는 절대로 사용해서는 안 됩니다. 😨

---

3. 핵심 비교: 그래서 둘의 차이점은?

이제 두 옵션의 차이점을 표로 명확하게 정리해 보겠습니다.

구분	allowPrivilegeEscalation: false	privileged: true
관점	컨테이너 내부 (프로세스가 부모보다 강해지는 것을 방지)	컨테이너 vs 호스트 (컨테이너가 호스트의 권한을 갖는 것을 허용)
작동 방식	리눅스 커널의 no_new_privs 플래그 제어	컨테이너 격리 메커니즘 전면 비활성화
비유	🕵️‍♂️ 내부 승진(권한 상승)을 막는 보안 요원	🗝️ 건물 전체를 여는 마스터키
주요 사용처	모든 일반 애플리케이션 파드의 기본 보안 강화	⚙️ CNI, 스토리지 드라이버 등 시스템 파드

 

---

두 옵션의 관계와 Best Practice

• privileged: true 컨테이너는 자동으로 allowPrivilegeEscalation이 true인 것처럼 동작합니다. 이미 호스트의 모든 권한을 가진 마스터키가 있는데, 컨테이너 내부에서 권한을 올리는 것은 아무 의미가 없기 때문이죠.
• 따라서 쿠버네티스는 privileged: true 와 allowPrivilegeEscalation: false 를 동시에 설정하는 것을 허용하지 않습니다.

⭐ Best Practice:

대부분의 일반적인 애플리케이션 컨테이너에는 privileged: false와 allowPrivilegeEscalation: false를 모두 명시적으로 설정하여 보안을 최대한 강화하는 것이 가장 좋습니다.

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: my-app
    image: my-image
    securityContext:
      privileged: false
      allowPrivilegeEscalation: false # 이것이 바로 Best Practice!

 

이제 두 옵션의 차이가 명확히 이해되셨나요? allowPrivilegeEscalation: false는 컨테이너의 내부 보안을 단단히 하는 중요한 설정이며, privileged: true는 컨테이너의 경계를 허무는 강력하지만 위험한 옵션이라는 점을 꼭 기억해 주세요!

---