팀 프로젝트) EBS 권한 문제 - Prometheus, Kafka, ElasticSearch 차이

☁️ EBS 사용 시 securityContext가 필요한 경우와 아닌 경우 -> Prometheus, Kafka, Elasticsearch 비교

AWS EKS 환경에서 EBS를 StorageClass로 사용하는 경우,
어떤 애플리케이션은 별도 설정 없이 잘 동작하지만
어떤 애플리케이션은 permission denied 에러로 실행이 안 되는 경우가 있다.

이번 글에서는 Prometheus, Kafka, Elasticsearch 세 가지 대표적인 워크로드를 기준으로
EBS와 관련된 PVC 권한 제어 방식의 차이점을 정리했다.

---

⚙️ 1️⃣ Prometheus (수동 권한 설정 필요)

문제 현상

level=error err="opening storage failed: lock DB directory: open /prom-agent/lock: permission denied"

 

Prometheus는 기본적으로 nobody(UID 65534) 유저로 실행된다.
따라서 PVC가 root 권한으로 마운트되면 /prom-agent 경로에 쓰기 권한이 없어 WAL 파일이나 lock 파일을 생성하지 못하고 CrashLoopBackOff가 발생한다.

 

해결 방법
Deployment에 아래 코드를 추가하여 PVC 마운트 시 자동으로 권한을 변경한다.

spec:
  securityContext:
    runAsUser: 65534
    runAsGroup: 65534
    fsGroup: 65534

 

이 설정을 추가하면 쿠버네티스가 PVC 마운트 시 내부적으로 chown -R 65534:65534를 수행하여 쓰기 권한을 확보할 수 있다.

 

✅ 요약:
Prometheus는 root로 실행되지 않기 때문에, EBS 같은 블록 스토리지를 쓸 때 반드시 securityContext를 지정해야 한다.

---

🧱 2️⃣ Kafka (Strimzi Operator가 자동 처리)

Kafka는 일반적으로 Strimzi Operator로 배포한다.
Strimzi는 Operator 패턴을 사용해 PVC를 자동으로 초기화한다.

Operator가 내부적으로 root 권한의 initContainer를 추가해 PVC 경로를 초기화하고, /var/lib/kafka/data의 소유권을 미리 kafka:kafka로 변경해준다.

즉, 개발자가 별도로 fsGroup을 지정할 필요가 없다.

예시 (Strimzi 내부 자동 생성 pod 일부)

initContainers:
- name: volume-permissions
  image: strimzi/operator:latest
  securityContext:
    runAsUser: 0
  command:
    - sh
    - -c
    - chown -R 1001:0 /var/lib/kafka/data

 

✅ 요약:
Kafka는 Strimzi Operator가 root 권한으로 PVC 초기화를 수행하므로 securityContext 설정이 불필요하다.

---

🧩 3️⃣ Elasticsearch (ECK Operator가 자동 처리)

Elasticsearch도 ECK (Elastic Cloud on Kubernetes) Operator를 통해 배포된다.
ECK 역시 Prometheus와 달리, 자동으로 PVC 초기화 과정을 처리한다.

Operator가 Pod 생성 시 다음과 같은 root initContainer를 삽입한다:

initContainers:
- name: elastic-internal-init-filesystem
  securityContext:
    runAsUser: 0
  command:
    - bash
    - -c
    - chown -R 1000:0 /usr/share/elasticsearch/data

 

이 과정을 거쳐 /usr/share/elasticsearch/data의 소유자가 elasticsearch 사용자(UID 1000)로 바뀌기 때문에,
비-root로 실행되는 Elasticsearch 프로세스도 문제없이 접근할 수 있다.

 

✅ 요약:
Elasticsearch는 ECK Operator가 PVC 권한을 자동 조정하므로 추가적인 securityContext 설정이 필요 없다.

---

📊 4️⃣ 정리: EBS + PVC + 권한 모델 비교표

항목실행	유저	Operator 존재	PVC 권한 초기화	securityContext 필요 여부
Prometheus	nobody (65534)	❌ 없음	❌ 수동 설정 필요	✅ 필요
Kafka (Strimzi)	kafka (1001)	✅ 있음	✅ 자동 chown 처리	❌ 불필요
Elasticsearch (ECK)	elasticsearch (1000)	✅ 있음	✅ 자동 chown 처리	❌ 불필요

---

🧠 결론

AWS EBS를 PersistentVolume으로 사용하는 경우,
“Operator가 PVC를 대신 초기화해주는지 여부”가
securityContext 필요 여부를 결정한다.

• Operator가 없는 워크로드(Prometheus, Loki 등) → ✅ 직접 fsGroup 설정 필요
• Operator가 있는 워크로드(Kafka, Elasticsearch 등) → ❌ 자동으로 권한 세팅됨

---

📘 핵심 문장 요약

“EBS 자체의 문제라기보다, 컨테이너의 실행 유저가 root인지,
Operator가 PVC 초기화를 해주는지에 따라 securityContext가 필요한지 달라진다.”