[CNCF 하드닝 04] Secret이면 암호화된 걸까요? etcd 저장과 백업의 경계

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

기존 CNCF 시리즈 에서 인증서와 배포 구성을 봤다면, 그 설정이 어디에 어떤 형태로 남는지 도 확인해야 합니다. 오늘 목표는 Secret의 base64 표시, 저장 암호화, 조회 권한을 구분하는 것입니다. 세 가지 질문 가상의 앱 비밀번호가 Kubernetes Secret에 있다고 해 보겠습니다. YAML에서 읽기 어려운 문자열이 보이지만, base64는 누구나 되돌릴 수 있는 표현입니다. 저장 암호화가 설정되지 않으면 etcd 저장 데이터가 보호되는 것은 아닙니다. Secret 조회 권한과 Pod 생성 권한도 함께 검토해야 합니다. Secret 관리 원칙 질문 별도로 필요한 통제 디스크·스냅샷을 가져가면? 저장 암호화와 백업 접근 제한 API로 조회할 수 있다면? 최소 권한과 감사 앱이 로그로 출력한다면? 앱·관측 파이프라인의 비밀 제외 암호화를 켜도 정상 권한으로 API를 호출하면 서버가 복호화한 값을 돌려줍니다. 따라서 RBAC가 없어도 된다는 결론은 나오지 않습니다. API 경로와 저장 경로를 각각 따라가며 보호해야 합니다. 백업 파일뿐 아니라 복호화 키를 사용할 수 있는 주체도 경계 안에 들어갑니다. KMS v2 설정을 읽어 보기 아래는 자체 관리 control plane의 설정 형태를 이해하기 위한 합성 예제 입니다. Kubernetes에 kubectl apply 하는 일반 리소스가 아닙니다. 이미 구축한 호환 KMS 플러그인, Unix 소켓, 모든 API 서버의 설정 배포 절차가 전제입니다. 관리형 Kubernetes에서는 공급자의 암호화 설정 경로를 따라야 합니다. apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: ["secrets"] providers: - kms: apiVersion: v2 name: study-kms endpoint: unix:///var/run/study-kms/socket.sock timeout: 3s - identity: {} 첫 provider가 새로운 쓰기에 사용됩니다. 예제의 identity 는 초기 이관 중 기존 평문을 읽는 경로를 표현합니다. 완료 후 계속 필요한지 검토해야 하며, 첫 번째로 옮기면 새 쓰기가 암호화되지 않습니다. 설정 도입만으로 기존 객체가 모두 다시 쓰이지도 않습니다. 저장 암호화 설정과 이관 KMS v2는 Kubernetes 1.29부터 stable입니다. provider가 외부 키 서비스와 통신하는 구조이므로 플러그인 연결, 키 접근 정책, 장애 시 가용성도 설계 대상입니다. 소켓 경로 문자열만 맞으면 암호화가 동작하는 것은 아닙니다. KMS provider 구조 검증할 때 비밀을 출력하지 않기 이 글에는 전체 Secret을 JSON으로 출력해 재입력하는 실행 명령을 넣지 않았습니다. 대규모 이관은 권한이 좁게 통제된 별도 작업으로 준비하고, 실제 값이 터미널·CI 로그·아티팩트에 남지 않게 해야 합니다. 독자 실습에서 다음 순서로 결과를 검토하세요. Secret 값 대신 합성 canary 하나와 기대하는 저장 형식을 정의합니다. 각 API 서버에서 provider 구성·플러그인 상태를 확인합니다. 담당자가 제한된 절차로 canary의 저장 형식만 확인하고 원문을 기록하지 않습니다. 기존 객체 이관의 완료 범위와 실패 목록을 값 없이 기록합니다. 백업 복원 시 같은 암호문을 읽을 키와 권한이 준비됐는지 별도 실습으로 확인합니다. 다음은 Secret 이름 목록만 확인하는 독자용 조회 안내입니다. 존재를 확인할 뿐 암호화 증명이 아닙니다. 실제 사용자 환경에는 실행하지 않았습니다. kubectl get secrets -n secret-study -o name 변경과 되돌림에서 놓치기 쉬운 것 키를 교체할 때 이전 암호문이 남아 있는데 예전 복호화 경로를 지우면 데이터가 읽히지 않을 수 있습니다. 되돌림 자료에는 이전 키 사용 권한과 암호화 설정의 호환 관계가 필요합니다. 파일 하나의 복원만으로 끝난다고 가정하지 마세요. 백업은 암호화하고 별도 저장소 접근 권한·보존 기간·복원 담당자를 지정하는 운영 설계를 권합니다. 백업 파일을 보호해도 키가 같이 유출되면 경계가 약해집니다. 반대로 키를 너무 일찍 폐기하면 복원이 불가능해집니다. 보호와 복원 가능성을 함께 테스트해야 합니다. 확인 문제 Secret의 base64 문자열은 저장 암호화 증거일까요? KMS provider를 첫 순서에 추가하면 과거 객체도 즉시 모두 바뀔까요? 저장 암호화가 API 조회 권한을 대신할까요? 답과 해설: 1. 아니요. 표현 형식입니다. 2. 기존 데이터는 검토된 재쓰기 이관이 필요합니다. 3. 별도 경계입니다. 정상 API 권한은 복호화된 데이터를 받을 수 있습니다. 오늘은 저장·조회·로그 경로를 그려 보세요. 내일은 키 서비스 장애 때 필요한 증거를 적고, 일주일 뒤에는 복원 기록에서 비밀값이 빠졌는지 확인하세요. 버전과 검증 범위 2026-10-04 공식 문서 확인. 예제는 KMS v2 및 Kubernetes 1.29 이상 구조입니다. 로컬 YAML 파싱, Secret 범위, provider 순서, identity 를 앞으로 옮긴 잘못된 구성 반례를 검사했습니다. 암호화·KMS 연결·etcd 읽기·백업 복원은 실행하지 않았습니다.

Детали предложения