Chat Conversation

kube-prometheus-stack operator가 광범위한 클러스터 권한을 요구하는 이유를 체계적으로 분석해보겠습니다. kube-prometheus-stack operator가 광범위한 클러스터 권한을 필요로 하는 이유를 체계적으로 분석해드리겠습니다.

다음과 같은 작업 계획으로 진행하겠습니다:

작업 계획

1단계: kube-prometheus-stack operator 기능 및 역할 분석

• Operator의 핵심 기능과 담당 영역 설명
• 클러스터 전반적 모니터링이 필요한 이유

2단계: 광범위한 클러스터 권한이 필요한 구체적 이유 분석

• 리소스 검색 및 발견 권한
• 메트릭 수집을 위한 권한
• CRD 관리 권한
• RBAC 구성 권한

3단계: 각 권한 유형별 사용 사례와 예시 제공

• ClusterRole에서 요구되는 구체적 권한들
• 실제 YAML 구성 예시
• 각 권한의 실사용 시나리오

4단계: 보안 고려사항과 권한 최소화 방안

• 보안 위험요소 분석
• 권한 제한 방법
• 모범 사례 제시

이 계획으로 진행해도 괜찮으신가요? 아니면 특정 부분에 더 집중하고 싶으신 부분이 있나요?

1단계: kube-prometheus-stack operator 기능 및 역할 분석

kube-prometheus-stack operator는 Kubernetes 클러스터에서 완전한 모니터링 스택을 자동으로 배포하고 관리하는 역할을 합니다.

핵심 기능들

Prometheus Operator 관리

• 여러 Prometheus 인스턴스를 동적으로 생성, 수정, 삭제
• 각 Prometheus의 구성을 자동으로 관리
• 고가용성을 위한 샤딩 및 복제 구성

ServiceMonitor/PodMonitor 자동 발견

• 클러스터 전체에서 모니터링 대상을 자동으로 식별
• 라벨 셀렉터를 통한 동적 타겟 관리
• 네임스페이스 간 모니터링 구성

AlertManager 통합 관리

• 알림 규칙의 전역적 관리
• 라우팅 및 억제 규칙 구성
• 다중 AlertManager 인스턴스 조정

Grafana 자동 구성

• 데이터소스 자동 등록
• 대시보드 자동 프로비저닝
• 사용자 및 권한 관리

이러한 기능들은 클러스터 전체를 대상으로 하기 때문에 단일 네임스페이스 권한으로는 불가능합니다.

---

1단계가 완료되었습니다. 다음 2단계로 진행해도 될까요?

2단계: 광범위한 클러스터 권한이 필요한 구체적 이유 분석

리소스 검색 및 발견 권한

전체 클러스터 스캔 필요성

• Services: 모든 네임스페이스의 서비스를 스캔하여 메트릭 엔드포인트 발견
• Pods: 직접적인 Pod 모니터링을 위한 PodMonitor 구성
• Endpoints: 실제 메트릭 수집 대상의 IP:Port 정보 획득
• Nodes: 클러스터 노드 상태 및 리소스 사용량 모니터링

# 예시: 전체 클러스터에서 메트릭 대상 발견
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kubernetes-apiservers
spec:
  selector:
    matchLabels:
      component: apiserver
      provider: kubernetes
  namespaceSelector:
    matchNames:
    - kube-system  # 시스템 네임스페이스 접근 필요

메트릭 수집을 위한 권한

클러스터 메트릭 접근

• API Server 메트릭: /metrics 엔드포인트 접근
• Kubelet 메트릭: 각 노드의 kubelet으로부터 컨테이너/노드 메트릭
• cAdvisor 데이터: 컨테이너 리소스 사용량 정보
• ETCD 메트릭: 클러스터 상태 저장소 모니터링

# Prometheus가 필요로 하는 클러스터 권한 예시
rules:
- apiGroups: [""]
  resources: ["nodes", "nodes/proxy", "services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch"]

CRD 관리 권한

Custom Resource Definitions 전역 관리

• PrometheusRule: 알림 규칙을 모든 네임스페이스에서 수집
• ServiceMonitor: 서비스 모니터링 구성을 전역적으로 관리
• PodMonitor: Pod 직접 모니터링 설정
• Probe: 블랙박스 모니터링 구성

# CRD 관리를 위한 클러스터 권한
rules:
- apiGroups: ["monitoring.coreos.com"]
  resources: ["prometheuses", "prometheusrules", "servicemonitors", "podmonitors"]
  verbs: ["*"]  # 전체 CRUD 권한 필요

RBAC 구성 권한

Prometheus 인스턴스를 위한 권한 부여

• Prometheus 서비스 계정 생성
• 메트릭 수집을 위한 ClusterRole 생성
• ClusterRoleBinding으로 권한 바인딩
• 여러 네임스페이스에서 동작하는 Prometheus 인스턴스 관리

# Operator가 Prometheus를 위해 생성하는 RBAC
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources: ["nodes", "nodes/proxy", "services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

네임스페이스 간 협업 권한

크로스 네임스페이스 모니터링

• 한 네임스페이스의 Prometheus가 다른 네임스페이스 모니터링
• 중앙집중식 AlertManager가 모든 네임스페이스의 알림 처리
• Grafana가 전체 클러스터 데이터에 접근

이러한 권한들이 없으면 부분적이고 불완전한 모니터링만 가능하게 됩니다.

---

2단계가 완료되었습니다. 3단계로 진행하시겠습니까?

3단계: 각 권한 유형별 사용 사례와 예시 제공

ClusterRole에서 요구되는 구체적 권한들

핵심 API 그룹별 권한 분석

# kube-prometheus-stack operator의 실제 ClusterRole 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-operator
rules:
# 1. 기본 Kubernetes 리소스 권한
- apiGroups: [""]
  resources: 
    - configmaps
    - secrets
    - nodes
    - nodes/proxy
    - nodes/metrics
    - services
    - endpoints
    - pods
    - serviceaccounts
    - persistentvolumeclaims
    - persistentvolumes
  verbs: ["get", "list", "watch"]

# 2. 확장 API 권한
- apiGroups: ["apps"]
  resources: ["daemonsets", "deployments", "replicasets", "statefulsets"]
  verbs: ["get", "list", "watch"]

# 3. Monitoring CRD 권한
- apiGroups: ["monitoring.coreos.com"]
  resources: 
    - alertmanagers
    - alertmanagerconfigs
    - prometheuses
    - prometheusrules
    - servicemonitors
    - podmonitors
    - probes
    - thanosrulers
  verbs: ["*"]

# 4. RBAC 관리 권한
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles", "clusterrolebindings"]
  verbs: ["create", "get", "list", "watch", "update", "patch", "delete"]

실제 사용 시나리오별 권한 활용

시나리오 1: 전체 클러스터 노드 모니터링

# Node Exporter를 통한 노드 메트릭 수집
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: node-exporter
  namespaceSelector:
    any: true  # 모든 네임스페이스에서 node-exporter 발견
  endpoints:
  - port: metrics
    path: /metrics
    interval: 30s

필요한 권한: nodes, services, endpoints에 대한 클러스터 전체 get, list, watch

시나리오 2: API Server 메트릭 수집

# Kubernetes API Server 모니터링
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-apiserver
spec:
  selector:
    matchLabels:
      component: apiserver
      provider: kubernetes
  namespaceSelector:
    matchNames: ["default"]
  endpoints:
  - port: https
    scheme: https
    tlsConfig:
      caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      serverName: kubernetes
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

필요한 권한: services에 대한 default 네임스페이스 접근 + API Server 메트릭 엔드포인트 접근

시나리오 3: 동적 알림 규칙 관리

# 여러 네임스페이스의 PrometheusRule 수집
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-main
spec:
  ruleSelector:
    matchLabels:
      prometheus: main
  ruleNamespaceSelector:
    any: true  # 모든 네임스페이스에서 규칙 수집

필요한 권한: 모든 네임스페이스의 prometheusrules에 대한 get, list, watch

Prometheus 인스턴스를 위한 자동 RBAC 생성

Operator가 생성하는 Prometheus ServiceAccount 권한

# Operator가 자동으로 생성하는 Prometheus용 ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-main
  labels:
    app.kubernetes.io/name: prometheus
rules:
- apiGroups: [""]
  resources:
    - nodes
    - nodes/proxy  # kubelet 메트릭 접근
    - nodes/metrics  # 노드 메트릭 접근
    - services
    - endpoints
    - pods
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]  # API Server 메트릭
  verbs: ["get"]

---
# 해당 권한을 Prometheus ServiceAccount에 바인딩
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-main
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-main
subjects:
- kind: ServiceAccount
  name: prometheus-main
  namespace: monitoring

네임스페이스별 세부 권한 예시

특정 네임스페이스만 모니터링하는 경우

# 제한된 네임스페이스만 모니터링
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-limited
spec:
  serviceMonitorNamespaceSelector:
    matchNames: ["default", "kube-system", "monitoring"]
  ruleNamespaceSelector:
    matchNames: ["default", "kube-system", "monitoring"]

하지만 여전히 필요한 클러스터 권한:

• nodes: 노드 메트릭을 위해
• nonResourceURLs: ["/metrics"]: API Server 메트릭을 위해
• CRD 관리: ServiceMonitor, PrometheusRule 검색을 위해

권한 사용의 실제 흐름

1. Operator 시작 → 전체 클러스터 CRD 스캔
2. ServiceMonitor 발견 → 해당 Service/Endpoints 조회
3. Prometheus 구성 업데이트 → ConfigMap/Secret 생성
4. RBAC 자동 생성 → Prometheus용 ClusterRole/Binding 생성
5. 지속적 감시 → 리소스 변경사항 실시간 반영

각 단계마다 클러스터 전반적인 권한이 필요한 이유를 보여줍니다.

---

3단계가 완료되었습니다. 마지막 4단계로 진행하시겠습니까?

4단계: 보안 고려사항과 권한 최소화 방안

보안 위험요소 분석

클러스터 전체 권한의 잠재적 위험

1. 과도한 권한 남용 가능성

# 위험한 권한 예시 - 모든 Secret 접근 가능
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]  # 클러스터 모든 Secret 조회 가능

2. 측면 공격(Lateral Movement) 위험

• Operator가 침해될 경우 전체 클러스터 접근 가능
• ServiceAccount 토큰 탈취 시 광범위한 정보 수집 가능

3. 의도하지 않은 리소스 수정

# 잠재적 위험 - CRD 전체 권한
- apiGroups: ["monitoring.coreos.com"]
  resources: ["*"]
  verbs: ["*"]  # 모든 모니터링 리소스에 대한 전체 권한

권한 제한 방법

방법 1: 네임스페이스 기반 권한 분리

# 제한된 네임스페이스만 관리하는 Role 사용
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: prometheus-operator-limited
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["monitoring.coreos.com"]
  resources: ["prometheuses", "servicemonitors"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

---
# 여러 네임스페이스에 동일한 Role 적용
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prometheus-operator-limited
  namespace: monitoring
subjects:
- kind: ServiceAccount
  name: prometheus-operator
  namespace: monitoring
roleRef:
  kind: Role
  name: prometheus-operator-limited
  apiGroup: rbac.authorization.k8s.io

방법 2: 동사(Verbs) 제한

# 읽기 전용 권한으로 제한
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]  # create, update, delete 제거
  resourceNames: ["prometheus-config", "alertmanager-config"]  # 특정 리소스만

방법 3: 리소스 이름 기반 제한

# 특정 이름의 리소스만 접근 허용
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]
  resourceNames: 
    - "prometheus-*"  # prometheus 관련 secret만
    - "alertmanager-*"  # alertmanager 관련 secret만

모범 사례 제시

1. 단계적 권한 부여 (Graduated Permissions)

# 초기 설치: 최소 권한으로 시작
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-operator-minimal
  namespace: monitoring

---
# 기본 모니터링만 가능한 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-operator-minimal
rules:
- apiGroups: [""]
  resources: ["nodes", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["monitoring.coreos.com"]
  resources: ["servicemonitors", "prometheusrules"]
  verbs: ["get", "list", "watch"]

---
# 필요시에만 추가 권한 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-operator-extended
rules:
- apiGroups: [""]
  resources: ["secrets", "configmaps"]
  verbs: ["create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch"]

2. 네임스페이스 기반 격리

# 프로덕션 환경을 위한 분리된 구성
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-production
  namespace: monitoring-prod
spec:
  # 특정 네임스페이스만 모니터링
  serviceMonitorNamespaceSelector:
    matchNames: ["production", "kube-system"]
  
  # 프로덕션용 AlertManager만 사용
  alerting:
    alertmanagers:
    - namespace: monitoring-prod
      name: alertmanager-production
      port: web

3. 감사 및 모니터링

# Operator 자체에 대한 모니터링
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-operator-metrics
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prometheus-operator
  endpoints:
  - port: https
    scheme: https
    path: /metrics
    tlsConfig:
      insecureSkipVerify: true

4. 정기적인 권한 검토

# 현재 부여된 권한 검토 스크립트
kubectl get clusterrolebinding -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.subjects[*].name}{"\n"}{end}' | grep prometheus

# 실제 사용되는 권한 감사
kubectl auth can-i --list --as=system:serviceaccount:monitoring:prometheus-operator

대안적 접근 방법

1. 다중 Operator 배포

• 네임스페이스별로 별도의 Operator 인스턴스 배포
• 각각 최소한의 권한만 보유

2. Sidecar 패턴 활용

# Prometheus Sidecar를 통한 제한적 권한 사용
spec:
  containers:
  - name: prometheus
    # 메트릭 수집만 담당
  - name: config-reloader
    # 설정 변경 감지 및 재로드만 담당

3. External Secret Operator 연동

# Secret 관리를 별도 Operator에 위임
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: prometheus-config
spec:
  secretStoreRef:
    name: vault-backend
    kind: SecretStore

결론: 균형있는 보안 접근

kube-prometheus-stack operator의 광범위한 권한은 기능적 필요성에서 비롯되지만, 다음과 같은 방식으로 보안을 강화할 수 있습니다:

• 점진적 권한 부여: 초기에는 최소 권한으로 시작
• 네임스페이스 격리: 중요한 워크로드는 별도 네임스페이스에서 관리
• 정기적인 감사: 실제 사용되는 권한과 부여된 권한 비교
• 모니터링: Operator 자체의 활동을 모니터링
• 업데이트: 최신 버전 사용으로 보안 패치 적용

이러한 방식으로 모니터링 기능과 보안 사이의 적절한 균형을 유지할 수 있습니다.

---

4단계가 완료되었습니다. 전체 분석이 마무리되었는데, 추가로 궁금한 부분이나 더 자세히 알고 싶은 영역이 있으신가요?

Kubernetes Operator의 RBAC 설정을 위한 Best Practice 문서들을 찾아드렸습니다. 다음은 참고할 만한 주요 문서들입니다:

공식 Kubernetes 문서

1. Kubernetes RBAC Good Practices

• URL: https://kubernetes.io/docs/concepts/security/rbac-good-practices/
• 내용: 최소 권한 원칙, 권한 상승 방지, 클러스터 하드닝 방법
• 핵심: Operator를 위한 최소한의 RBAC 권한 설계 가이드라인

2. Using RBAC Authorization

• URL: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• 내용: RBAC의 기본 개념과 구현 방법, Role/ClusterRole 설정
• 핵심: RBAC 구성 요소와 바인딩 방법에 대한 상세 가이드

CNCF 및 Operator Framework 문서

3. CNCF Operator White Paper

• URL: https://tag-app-delivery.cncf.io/whitepapers/operator/
• 내용: Operator 보안 설계 원칙, RBAC 최소 권한 부여 방법
• 핵심: "최소한의 권한만 부여하되, ClusterRole은 절대 필요한 경우에만 사용"

4. Operator SDK Best Practices

• URL: https://sdk.operatorframework.io/docs/best-practices/
• 내용: Multi-tenancy, Pod Security Standards, 리소스 관리 방법
• 핵심: 네임스페이스 스코프 vs 클러스터 스코프 선택 가이드

정부 기관 보안 가이드

5. NSA/CISA Kubernetes Hardening Guidance

• URL: https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF
• 내용: 국가 보안 기준의 Kubernetes 하드닝 가이드
• 핵심:
  • 최소 권한으로 컨테이너/Pod 실행
  • 고유한 역할별 RBAC 정책 생성
  • 감사 로깅 활성화

산업계 Best Practice 가이드

6. Snyk - Principle of Least Privilege with RBAC

• URL: https://snyk.io/blog/applying-the-principle-of-least-privilege-to-kubernetes-using-rbac/
• 내용: 실무적인 최소 권한 원칙 적용 방법
• 핵심: 단계적 권한 부여와 정기적 권한 검토

7. Trilio - Kubernetes RBAC Best Practices

• URL: https://trilio.io/kubernetes-best-practices/kubernetes-rbac/
• 내용: 개발/운영 환경별 RBAC 구성 예시
• 핵심: 네임스페이스 기반 역할 분리와 실제 구현 사례

이 문서들을 통해 단계적 권한 부여, 네임스페이스 격리, 정기적 권한 감사 등의 모범 사례를 학습하실 수 있습니다. 특히 NSA/CISA 가이드는 보안 관점에서, Operator SDK 문서는 실무 구현 관점에서 매우 유용합니다.

kube-prometheus-stack Operator의 RBAC 베스트프랙티스 관련 문서들을 찾아드렸습니다:

공식 kube-prometheus-stack RBAC 이슈 및 개선사항

1. Namespace 기반 권한 제한 이슈

• URL: https://github.com/prometheus-community/helm-charts/issues/4156
• 제목: "Restrict secrets access to namespace"
• 내용: ClusterRole 대신 Role 사용으로 Secret 접근을 네임스페이스로 제한
• 핵심 베스트프랙티스:

  # 네임스페이스 스코프 설정
  grafana:
    rbac:
      namespaced: true
  
  kubeStateMetrics:
    rbac:
      useClusterRole: false
  
  prometheusOperator:
    rbac:
      namespaced: true
    namespaces:
      releaseNamespace: true
  

2. Prometheus Operator 최소 권한 요청

• URL: https://github.com/prometheus-operator/prometheus-operator/issues/3544
• 제목: "Support and document tighter RBAC permissions for Operator"
• 내용: ClusterRole의 과도한 권한(특히 * verbs) 최소화 요구
• 핵심 보안 우려사항:
  • Secret에 대한 클러스터 전체 * 권한
  • ConfigMap, StatefulSet에 대한 광범위한 권한
  • 네임스페이스 스코프 옵션 필요성

실무적 RBAC 베스트프랙티스

3. 네임스페이스 기반 제한 구성

# values.yaml 예시 - 최소 권한 구성
prometheusOperator:
  rbac:
    namespaced: true  # 네임스페이스 스코프로 제한
  namespaces:
    releaseNamespace: true  # 설치된 네임스페이스만 관리
    additional: []  # 추가 네임스페이스 필요시만 지정
  kubeletService:
    enabled: false  # 클러스터 전체 kubelet 접근 비활성화

prometheus:
  rbac:
    namespaced: true  # Prometheus 인스턴스도 네임스페이스 스코프

grafana:
  rbac:
    namespaced: true  # Grafana RBAC도 네임스페이스로 제한

kubeStateMetrics:
  rbac:
    useClusterRole: false  # 클러스터 권한 대신 네임스페이스 권한 사용

# 시스템 컴포넌트 모니터링 비활성화 (클러스터 권한 불필요)
kubelet:
  enabled: false
coreDns:
  enabled: false  
kubeApiServer:
  enabled: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeProxy:
  enabled: false
kubeScheduler:
  enabled: false

4. 단계적 권한 부여 전략

# 1단계: 최소 권한으로 시작
prometheusOperator:
  rbac:
    namespaced: true
  namespaces:
    releaseNamespace: true

# 2단계: 필요시에만 추가 네임스페이스 허용
prometheusOperator:
  namespaces:
    additional: ["production", "staging"]

# 3단계: 특정 기능만 클러스터 스코프 허용
nodeExporter:
  enabled: true  # 노드 메트릭은 클러스터 스코프 필요
kubeStateMetrics:
  rbac:
    useClusterRole: true  # 필요시에만 클러스터 권한

보안 강화 구성 예시

5. Secret 접근 제한

# 커스텀 Role로 Secret 권한 제한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-operator-secrets
  namespace: monitoring
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
  resourceNames: 
    - "prometheus-*"
    - "alertmanager-*"
    - "grafana-*"

6. 권한 감사 및 모니터링

# 현재 부여된 권한 확인
kubectl auth can-i --list --as=system:serviceaccount:monitoring:prometheus-operator

# 실제 사용되는 권한 모니터링
kubectl get events --field-selector reason=Forbidden

# RBAC 위반 감사
kubectl logs -n monitoring deployment/prometheus-operator | grep "forbidden"

주요 베스트프랙티스 요약

7. 권장 설정 패턴

• 개발/테스트 환경: 완전한 네임스페이스 스코프
• 프로덕션 환경: 하이브리드 접근 (핵심 기능만 클러스터 스코프)
• 멀티 테넌트: 테넌트별 별도 Operator 인스턴스

8. 지속적인 개선사항

• PR #4283: 네임스페이스 기반 Role 추가 (진행 중)
• Issue #3080: StatefulSet 권한 스코프 축소
• Issue #3158: 최소 권한 문서화

이러한 베스트프랙티스를 따르면 기능성을 유지하면서도 보안 위험을 최소화할 수 있습니다. 특히 namespaced: true 설정과 불필요한 시스템 컴포넌트 모니터링 비활성화가 핵심입니다.