[IT-방법] 데몬셋 보안 설정 핵심 가이드 – 권한 최소화와 취약점 차단 실무 적용법

데몬셋 보안, 왜 클러스터 전체의 운명을 결정할까요?

클라우드 환경으로 막 마이그레이션을 마친 엔지니어라면 한 번쯤 이런 상황을 마주하게 돼요. 모니터링이나 로그 수집을 위해 배포한 데몬셋(DaemonSet) 하나가 탈취되었는데, 그 영향이 해당 노드를 넘어 클러스터 전체로 번지는 끔찍한 시나리오예요. 데몬셋은 모든 노드에 동일하게 실행된다는 특성 때문에, 단 하나의 설정 실수만으로도 클러스터 전체의 권한을 탈취당할 수 있는 거대한 공격 통로가 될 수 있어요.

보통 로그 수집기나 네트워크 플러그인 같은 필수 구성 요소들을 데몬셋으로 운영하죠. 이들은 노드의 시스템 자원에 접근해야 한다는 명목하에 높은 권한을 요구받는 경우가 많아요. 하지만 ‘작동만 하면 된다’는 생각으로 무심코 설정한 privileged: true 한 줄이 보안 감사에서 가장 큰 지적 사항이 되고, 실제 사고 발생 시에는 돌이킬 수 없는 피해를 불러와요. 권한이 높은 데몬셋은 노드의 커널을 직접 건드리거나 호스트 파일 시스템에 접근할 수 있는 강력한 힘을 가졌기 때문이에요.

지금 이 글을 읽고 계신 분들도 클러스터 운영 중에 데몬셋의 권한 범위를 어디까지 허용해야 할지, 어떻게 하면 보안을 강화하면서도 서비스 운영에 차질을 주지 않을지 고민이 많으실 거예요. 단순히 이론적인 보안이 아니라, 실제 운영 환경에서 바로 적용할 수 있는 실전적인 방법들을 정리해 드릴게요. 이 가이드를 끝까지 따라오시면 보안 사고의 위험을 획기적으로 낮출 수 있어요.

이번 가이드에서 함께 살펴볼 핵심 내용은 다음과 같아요.

• 데몬셋이 가지는 보안 위협의 근본적인 원인 분석
• 권한 최소화 원칙에 기반한 보안 컨텍스트(SecurityContext) 설계
• RBAC와 서비스 어카운트를 활용한 접근 제어 전략
• 실제 운영 시 바로 적용 가능한 보안 설정 예시와 검증 절차

보안 설정을 시작하기 전 반드시 알아야 할 체크리스트

데몬셋의 보안 설정을 무턱대고 시작하기 전에, 우리가 무엇을 보호해야 하는지 그리고 어떤 기준을 가지고 설정을 구성해야 하는지 명확히 이해해야 해요. 무작정 설정을 강화했다가 운영 중인 로그 수집기가 멈춰버리면 운영팀의 거센 항의를 받게 될 테니까요. 보안과 가용성 사이의 균형을 맞추는 것이 실무자의 가장 큰 숙제예요.

우선 데몬셋이 노드의 자원을 사용해야 하는 ‘정당한 이유’를 정의해야 해요. 예를 들어, 노드의 로그 파일을 읽어야 한다면 호스트 경로를 읽는 권한만 필요하지, 노드의 네트워크 설정을 변경할 권한까지는 필요하지 않아요. 이렇게 필요한 만큼만 권한을 쪼개는 것이 최소 권한 원칙(Principle of Least Privilege)의 핵심이에요.

설계 시에는 현재 운영 중인 환경의 보안 수준을 먼저 파악해야 해요. 아래 표는 데몬셋을 구성할 때 고려해야 할 보안 수준별 설정 차이를 보여줘요. 여러분의 서비스 성격에 맞는 기준을 선택해 보세요.

위 표에서 보듯, 데몬셋의 용도에 따라 보안 수준이 완전히 달라져요. 네트워크 플러그인(CNI)처럼 노드의 네트워크 스택을 직접 제어해야 하는 경우에는 어쩔 수 없이 낮은 보안 수준을 선택해야 하지만, 이때는 다른 보안 설정(RBAC, 네트워크 정책)을 통해 보완하는 전략을 세워야 해요. 단순히 ‘안 된다’라고 말하는 것이 아니라, ‘이 기능은 필요하니 다른 방식으로 보호하겠다’라는 논리가 필요해요.

데몬셋 보안 강화를 위한 5단계 실행 가이드

이제 본격적으로 데몬셋을 안전하게 만드는 구체적인 방법들을 알아볼게요. 각 단계는 독립적인 것이 아니라 서로 겹쳐져서 강력한 보안 계층을 형성해요. 하나라도 빠지면 보안의 구멍이 생길 수 있으니 꼼꼼하게 적용해 주세요.

STEP 1. 보안 컨텍스트(SecurityContext)를 통한 프로세스 격리

가장 먼저 해야 할 일은 파드와 컨테이너 수준에서 실행될 프로세스의 권한을 제한하는 것이에요. 많은 엔지니어가 데몬셋을 배포할 때 컨테이너가 루트(root) 권한으로 실행되도록 방치하곤 해요. 하지만 이는 공격자가 컨테이너를 뚫었을 때 노드의 루트 권한을 바로 손에 넣게 만드는 지름길이에요.

먼저 runAsNonRoot: true 설정을 통해 컨테이너가 반드시 루트가 아닌 사용자로 실행되도록 강제하세요. 또한, runAsUser와 runAsGroup를 명시하여 특정 UID와 GID를 지정하는 것이 좋아요. 이렇게 하면 컨테이너 내부의 프로세스가 노드의 시스템 파일에 접근하려고 해도 권한 부족으로 거부당하게 돼요.

주의할 점은, 로그 수집기처럼 호스트의 특정 디렉토리에 접근해야 하는 경우에는 해당 디렉토리의 권한과 컨테이너 실행 사용자의 권한을 미리 맞춰두어야 한다는 것이에요. 또한, allowPrivilegeEscalation: false 설정을 반드시 추가하세요. 이 설정은 프로세스가 자신의 권한을 높이는 것을 막아주기 때문에, 보안 사고의 확산을 방지하는 데 결정적인 역할을 해요.

STEP 2. RBAC 설정을 통한 API 서버 접근 제한

데몬셋은 보통 클러스터의 상태를 관찰하거나 노드 정보를 가져오기 위해 쿠버네티스 API 서버와 통신해요. 이때 사용하는 서비스 어카운트(ServiceAccount)의 권한이 너무 넓으면 큰 문제가 생겨요. 예를 들어, 데몬셋이 단순히 노드 정보를 읽기만 하면 되는데 ‘cluster-admin’ 권한을 가지고 있다면, 공격자는 데몬셋을 통해 클러스터의 모든 리소스를 삭제하거나 생성할 수 있게 돼요.

따라서 반드시 최소 권한의 Role을 생성해야 해요. 데몬셋이 필요한 동작이 ‘노드 목록 조회’라면, ClusterRole에 `get`, `list`, `watch` 권한을 `nodes` 리소스에 대해서만 부여하세요. 그리고 이 역할을 데몬셋 전용 서비스 어카운트에 연결해야 해요. 기본(default) 서비스 어카운트를 사용하는 습관은 반드시 버려야 해요.

STEP 3. 호스트 네임스페이스 및 파일 시스템 격리

데몬셋은 특성상 노드의 자원을 직접 써야 하는 경우가 많아요. 이때 사용하는 hostPath 볼륨과 호스트 네임스페이스 설정은 가장 위험한 요소 중 하나예요. 만약 hostNetwork: true를 설정하면 컨테이너가 노드의 네트워크 인터페이스를 직접 사용하게 되어, 노드에서 돌아가는 다른 서비스의 트래픽을 가로챌 수 있는 위험이 생겨요.

이를 방지하기 위해 다음과 같은 전략을 써보세요.

• hostPath 사용 최소화: 꼭 필요한 경로만 지정하고, 해당 경로는 읽기 전용으로 마운트하세요.
• hostPID, hostIPC 금지: 노드의 프로세스 목록을 보거나 프로세스 간 통신을 가로채는 것을 막기 위해 이 설정들은 가급적 false로 유지하세요.
• 네트워크 정책(NetworkPolicy) 적용: 데몬셋 파드가 통신할 수 있는 대상 IP와 포트를 엄격하게 제한하세요.

STEP 4. 리소스 제한을 통한 DoS 공격 방어

보안은 단순히 해킹을 막는 것뿐만 아니라, 서비스의 가용성을 지키는 것도 포함해요. 만약 데몬셋의 특정 프로세스가 버그를 일으키거나 악성 코드가 실행되어 노드의 CPU나 메모리를 전부 점유해버린다면 어떻게 될까요? 해당 노드에서 실행 중인 다른 중요한 파드들이 모두 중단되는 서비스 거부(DoS) 상태에 빠지게 돼요.

이를 막기 위해 반드시 resources.limits와 resources.requests를 설정해야 해요. 데몬셋은 모든 노드에서 실행되므로, 리소스 제한을 조금만 과하게 잡아도 클러스터 전체의 자원 낭비가 심각해질 수 있어요. 따라서 실제 사용량을 정밀하게 측정하여 적절한 임계치를 설정하는 노하우가 필요해요.

STEP 5. 정책 도구를 활용한 자동화된 보안 강제

엔지니어가 일일이 모든 데몬셋을 검사하는 것은 불가능에 가까워요. 그래서 정책 엔진을 사용해 보안 기준에 맞지 않는 데몬셋이 배포되는 것 자체를 막아야 해요. 과거에는 Pod Security Policy(PSP)를 썼지만, 이제는 Pod Security Admission(PSA)을 사용하는 것이 표준이에요.

클러스터에 ‘Restricted’ 또는 ‘Baseline’ 정책을 적용하면, 보안 설정이 누락된 데몬셋이 배포될 때 API 서버 단계에서 거부되어 안전한 상태를 유지할 수 있어요. 만약 더 세밀한 제어가 필요하다면 Kyverno나 OPA(Open Policy Agent) 같은 도구를 활용해 ‘특정 UID를 사용하지 않는 파드는 배포 불가’ 같은 커스텀 규칙을 만들어 적용해 보세요.

자주 하는 실수와 해결법

실무 현장에서 데몬셋을 운영하며 가장 흔하게 범하는 실수들을 정리했어요. 비슷한 상황을 겪고 있다면 바로 해결책을 적용해 보세요.

• ❌ 실수: 모든 데몬셋에 privileged: true를 설정함
  왜 발생하는가: 시스템 자원에 접근해야 한다는 이유로 편의상 권한을 통째로 넘겨줌
  ✅ 해결법: 필요한 권한만 capability로 부여하거나, hostPath를 특정 경로로 한정하여 권한을 쪼개세요.
• ❌ 실수: 기본(default) 서비스 어카운트를 그대로 사용함
  왜 발생하는가: 별도의 RBAC 설정을 하는 것이 번거롭기 때문
  ✅ 해결법: 반드시 데몬셋 전용 ServiceAccount를 생성하고, 필요한 권한만 담은 Role을 연결하세요.
• ❌ 실수: 리소스 제한(Limits)을 설정하지 않음
  왜 발생하는가: 데몬셋이 자원을 많이 먹을 것이라는 예상을 못 했거나 설정이 귀찮아서
  ✅ 해결법: 최소한 CPU와 메모리의 Limit은 반드시 설정하여 노드 전체의 가용성을 보호하세요.
• ❌ 실수: 호스트 파일 시스템을 읽기/쓰기 모드로 마운트함
  왜 발생하는가: 로그를 기록하거나 설정을 변경해야 한다는 이유로
  ✅ 해결법: 읽기 전용 작업이라면 readOnly: true를 사용하고, 쓰기가 필요하다면 전용 디렉토리만 허용하세요.
• ❌ 실수: 보안 검증 없이 이미지를 배포함
  왜 발생하는가: 최신 이미지를 쓰는 것이 무조건 좋다고 생각해서
  ✅ 해결법: 이미지 스캔 도구를 사용하여 취약점이 발견되지 않은 베이스 이미지만 사용하세요.

자주 묻는 질문

Q. 데몬셋 보안 설정이 복잡한데, 가장 먼저 해야 할 한 가지를 꼽는다면 무엇인가요?

가장 우선순위가 높은 것은 runAsNonRoot: true와 allowPrivilegeEscalation: false를 설정하는 것이에요. 이 두 가지만 제대로 해도 컨테이너가 탈취되었을 때 공격자가 권한을 상승시켜 노드를 장악하는 시나리오를 상당 부분 차단할 수 있어요.

Q. 보안 설정을 강화하면 데몬셋이 제대로 동작하지 않을 수 있는데, 어떻게 테스트하나요?

먼저 스테이징(Staging) 환경에서 실제 운영과 동일한 데이터와 트래픽을 사용하여 테스트해야 해요. 특히 파일 시스템 권한이나 네트워크 차단이 서비스 기능에 영향을 주는지 확인하기 위해, 기능 테스트와 함께 로그를 면밀히 관찰하는 과정이 필수적이에요.

Q. 이미 운영 중인 데몬셋이 많은데, 한꺼번에 바꾸기 부담스러워요.

한 번에 모든 설정을 바꾸기보다는, 가장 위험도가 높은 데몬셋부터 순차적으로 적용하는 전략을 추천해요. 먼저 RBAC 권한을 검토하고, 그 다음에 컨텍스트 설정을 변경하는 식으로 단계를 나누어 진행하면 리스크를 줄일 수 있어요.

Q. Pod Security Admission(PSA)을 쓰면 자동으로 보안이 유지되나요?

PSA는 규칙에 어긋나는 파드가 배포되는 것을 ‘차단’해주는 도구이지, 이미 배포된 파드를 자동으로 수정해주지는 않아요. 따라서 PSA를 도입하기 전에 기존 파드들이 정책을 준수하고 있는지 먼저 점검하는 과정이 반드시 선행되어야 해요.

안전한 클러스터 운영을 위한 마지막 점검

데몬셋 보안은 단순히 한 번의 설정으로 끝나는 숙제가 아니에요. 클러스터의 규모가 커지고 새로운 서비스가 추가될 때마다 보안 수준을 지속적으로 검토하고 업데이트해야 하는 운영의 영역이죠. 오늘 다룬 내용들을 잊지 않도록 핵심 요약을 정리해 드릴게요.

이제 여러분이 해야 할 일은 명확해요. 지금 바로 운영 중인 클러스터에서 데몬셋 리스트를 뽑아보세요. 그리고 방금 배운 기준에 따라 각 데몬셋의 보안 컨텍스트와 RBAC 권한이 적절한지 하나씩 대조해 보는 거예요. 당장 모든 것을 바꿀 수는 없겠지만, 가장 위험해 보이는 것부터 하나씩 고쳐나가는 실행력이 여러분의 클러스터를 안전하게 만들 거예요.

실습 환경에서 직접 설정을 적용해 보다가 잘 안되거나, 특정 설정이 서비스 동작을 방해한다면 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하며 최선의 답을 찾아갔으면 좋겠어요.

더 깊이 있는 쿠버네티스 운영 지식이 필요하시다면, 쿠버네티스 데몬셋 기본 개념 글이나 클러스터 구축 입문 글도 함께 읽어 보시는 것을 추천해요.