[CNCF 하드닝 10] 상태를 보여 주는 화면도 잠가야 할까요? 관측 데이터와 비밀

Об этом предложении

기존 GitOps 운영 글 에서 Prometheus와 Loki로 상태를 보는 흐름을 다뤘습니다. 오늘 목표는 관측 서비스 접근 경계와 수집 데이터의 비밀 제외 를 함께 확인하는 것입니다. 앱을 보호하면서 로그 화면은 누구나 볼 수 있게 두면 경계가 남습니다. 읽기 화면에도 운영 정보가 있습니다 Prometheus API·metrics·디버그 경로에는 시스템 정보가 있습니다. 공개 노출을 피하고 필요한 접근 통제를 구성해야 합니다. 운영자만 써야 하는 관리·재로딩 경로도 따로 점검하세요. 대시보드의 보기 권한만 설정했다고 데이터 소스의 접근이 제한됐다고 단정하면 안 됩니다. Prometheus 보안 모델 전제는 실습 관측 namespace, 이미 검토된 인증 프록시와 TLS, 합성 telemetry 데이터입니다. 실제 토큰과 사용자 데이터를 테스트 입력으로 사용하지 않습니다. 그림의 각 경계는 독립적으로 확인합니다. Collector에서 하나의 속성을 지웠다고 앱 로그와 모든 backend 데이터가 정제되는 것은 아닙니다. Loki의 tenant 헤더는 로그인 비밀번호가 아닙니다 Loki의 multi-tenant 모드에서 X-Scope-OrgID 는 tenant 식별에 쓰입니다. 클라이언트가 임의로 헤더를 넣을 수 있는 경로를 그대로 신뢰하면 안 됩니다. 인증 프록시가 확인한 신원에서 tenant를 결정하고 전달 경로를 통제하는 설계가 필요합니다. auth_enabled: true 하나가 완성된 사용자 인증 시스템은 아닙니다. Loki 인증 안내 인증 프록시를 두어도 backend를 다른 주소로 직접 호출할 수 있다면 우회 경로가 남습니다. Kubernetes Service·Ingress·NetworkPolicy와 실제 route를 같이 점검하세요. Loki mTLS는 전송 계층 신원 검증이며 tenant 권한 매핑은 별도입니다. Collector 속성 삭제 예제 아래는 해당 processor가 포함된 Collector 배포판 의 설정 조각입니다. receiver·exporter·TLS와 인증 구성은 별도로 준비해야 합니다. 모든 Collector 배포판에 같은 component가 있다고 가정하지 마세요. processors: attributes/remove-sensitive: actions: - key: http.request.header.authorization action: delete - key: user.email action: delete - key: session.id action: delete service: pipelines: traces: receivers: [otlp] processors: [attributes/remove-sensitive, batch] exporters: [otlp/approved] processor를 정의하는 것과 pipeline에서 사용하는 것은 다릅니다. 예제는 trace pipeline에 연결했습니다. logs·metrics를 함께 받는다면 그 경로와 attribute 위치도 따로 검토해야 합니다. 가능하면 앱에서 처음부터 민감값을 수집하지 않는 것이 출발점입니다. OpenTelemetry 민감 데이터 처리 삭제할 key 이름은 사용한 instrumentation과 실제 수집 형태에 맞춰야 합니다. log body, resource attribute, URL query에 비밀이 있다면 위 세 속성 삭제로 해결되지 않습니다. 알려진 키를 지우는 예제를 전체 데이터 익명화라고 부르지 않았습니다. 합성 입력으로 확인하기 합성 attribute 예제 처리 목표 http.request.header.authorization 삭제 user.email 삭제 session.id 삭제 http.request.method 유지 로컬에서는 이 표대로 속성 집합이 바뀌는지만 검사했습니다. 실제 Collector에 합성 span을 보내 backend에 남은 값을 읽는 통합 검증은 별도입니다. 민감값이 들어 있는 원본을 테스트 로그로 출력하면 검증 과정에서 유출이 생길 수 있으므로 값 대신 제거 여부만 기록하세요. 다음은 독자용 설정 조회 안내입니다. 사용자 환경에는 실행하지 않았습니다. kubectl get service -n observability kubectl get ingress -n observability kubectl get networkpolicy -n observability 그다음 승인된 실습에서 인증 없는 조회가 거부되는지, 허용 사용자가 자기 tenant만 읽는지, 다른 tenant 헤더를 시도해도 범위가 바뀌지 않는지 검사합니다. 존재하지 않는 경로의 404와 인증 거부를 구분해야 합니다. 적용과 복구 합성 데이터부터 시작해 좁은 pipeline에 정제를 적용하고 필요한 운영 정보가 남는지 확인합니다. 대시보드 장애가 생기면 익명 접근을 여는 대신 인증 전달·권한·TLS 신뢰와 프록시 우회 경로를 확인합니다. 되돌림은 검토된 이전 Collector 구성에서 필요한 측정값을 복원하는 작업입니다. 비밀 수집을 다시 켜는 방식으로 화면을 복구하지 않습니다. 이미 저장된 민감 데이터는 새 processor로 소급 삭제되지 않으므로 별도 보존·삭제 절차가 필요합니다. 확인 문제 auth_enabled: true 만으로 Loki 사용자 로그인까지 완성될까요? processor를 정의만 해도 모든 telemetry가 지나갈까요? 세 attribute를 삭제하면 log body의 비밀도 없어질까요? 답과 해설: 1. 신원 인증과 tenant 매핑은 별도입니다. 2. 각 pipeline에 연결해야 합니다. 3. body와 다른 위치는 따로 점검해야 합니다. 오늘은 수집 위치를 나누고, 내일은 다른 tenant 반례를 설명해 보세요. 일주일 뒤에는 공개 route와 telemetry 필드 목록을 다시 검토하세요. 버전과 검증 범위 2026-10-04 Prometheus·Loki latest 및 OpenTelemetry 공식 문서 확인. 설치 버전·Collector 배포판 지원은 실환경에서 확인해야 합니다. 로컬 YAML, processor 연결, 합성 attribute 제거·pipeline 누락 반례를 검증했습니다. 인증 프록시·Collector·backend 통합 동작은 실행하지 않았습니다.