[쿠버네티스 교과서] Chapter 4. 컨피그맵과 비밀값으로 애플리케이션 설정하기

4.4. 비밀값을 이용하여 민감한 정보가 담긴 설정값 다루기

• Secret(비밀값): ConfigMap과 비슷한 API를 가진 별개의 resource로, configmap과 달리 민감한 정보를 다루므로 클러스터 내부에서 별도로 관리됨 -> 노출의 최소화
• secret은 해당 값을 사용해야 하는 node에만 전달 -> node에서도 저장하지 않고, 메모리에만 담김
• 전달 & 저장 과정에 모두 암호화 적용
  • 항상 암호화 상태 유지 X -> 비밀값 객체에 접근할 권한이 있다면, 비밀값의 평문 읽기 가능
  • but 난독화 계층 하나 추가
• 비밀값의 평문 -> Base64로 인코딩된 상태로 취급

Base64: 6비트 이진 데이터를 문자 코드에 영향 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식

출처: https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464 

 

-> ConfigMap과 달리 kubectl describe 명령에도 데이터 값 출력 X

-> 데이터 값을 확인하려 해도 Base64로 인코딩된 값만 출력

-> 완전한 평문을 보려면 Base64 디코더로 값을 piping해야 함

-> application의 정의에서 비밀값을 사용하는 방법 - secret의 특정 항목을 원하는 이름의 환경 변수로 들여올 수 있음

-> 해당 정의를 따르면 지정된 secret에 저장된 데이터의 평문이 container로 전달됨

• 환경 변수 -> container에서 동작하는 모든 processes에서 접근이 가능, application에 치명적 오류가 발생했을 때 모든 환경 변수를 로그로 남기는 경우도 존재 
  
  • 비밀값의 데이터를 환경변수로 넘기는 것의 대안 -> 비밀값을 파일 형태로 전달 -> 파일 권한 설정으로 민감한 정보 보호(application이 설정 파일을 지원한다면)

실습

• to-do application을 별도의 pod에서 동작하는 DB 서버를 사용하게끔 업데이트
• DB는 PorstgreSQL의 Docker hub image 사용 -> 해당 이미지는 로그인 정보를 secret 혹은 configMap으로 주입 가능

• Opaque: 일반적인 용도의 secret
  
  • configMap과 동일 목적으로 사용 가능, 민감한 데이터를 컨테이너에 전달하는 목적
  • Dockerconfigjson: 도커 이미지 저장소 인증 정보, registry 서비스에 있는 private 이미지를 가져올 때 필요한 정보를 secret에 저장
  • TLS: TLS 인증서를 Secret으로 관리, pod이나 service같은 오브젝트에서 해당 secret에 저장된 TLS 인증서 정보를 가져다 통신 암호화 수행 가능
  • Service-account-token: RBAC, 즉 사용 접근 제어를 해야할 때 사용하는 대표적인 쿠버네티스 API resource인 Service Account와 연관
    • serviceAccount는 pod에 연결이 되어, 해당 pod의 권한을 설정해주는 역할 수행
    • serviceAccount를 연결시켜주게 되면 serviceAccount에 대한 인증 정보를 담은 토큰이 Secret으로 자동 생성
• 비밀값을 YAML로 관리 -> 일관적인 application 배치 가능, but 모든 민감한 데이터가 형상 관리 도구(Git, ..)에 노출
• 실제 서비스 운영에서는 운영 환경의 민감한 데이터가 들어갈 자리 표시 -> application에 배치할 때 추가 처리
  • ex) github secret

-> 비밀값 객체의 annotation에는 평문이 그대로 저장됨

(annotation: k8s 시스템에서 사용하는 resource의 메타데이터, 모든 정보가 저장됨)

 

• 저장된 secret을 PostgreSQL DB의 패스워드로 사용하는 방법은 두 가지.
  1. 이상적인 방법은 아니지만, 컨테이너 환경에 POSTGRES_PASSWORD라는 환경 변수로 직접 전달하는 방법
  2. 컨테이너 환경에서 파일 형태로 전달한 후, 이 설정 파일의 경로를 환경 변수 POSTGRES_PASSWORD_FILE에 지정하는 방법

-> 2번 방법의 예제

 

• 로컬 파일 DB 대신, PostgreSQL 사용하도록 application을 실행

 

4.5. 쿠버네티스의 application 설정 관리

• k8s에서 configMap과 secret을 배치 절차에 활용할 만한 유연성을 갖추기 위해, 설계 단계에서 염두에 둘 두 가지 질문
  • application의 중단 없이 설정 변경에 대응이 필요한가?
  • 민감 정보를 어떻게 관리할 것인가?
• 파드 교체가 없는 무중단 업데이트가 중요하다면 -> 선택 범위가 제한적
  • 설정 업데이트에 pod 교체가 반드시 필요해지는 환경 변수 활용 불가능 -> volume mount를 이용하여 설정 파일을 수정하는 방법 사용 -> 기존 configmap이나 secret을 업데이트하는 방식
• configmap이나 secret 등 설정 객체를 업데이트하지 않는 대안
  • 설정 객체의 이름에 버전 명명법 도입하고, application을 업데이트할 때 새로운 설정 객체를 배치한 후, 해당 객체를 가리키게 application 정의 수정
  • 대신 설정값 변경의 이력이 남으며, 만일의 경우 이전 설정으로 돌아가는 선택지 발생

• "민감 정보를 어떻게 관리할 것인가?"
  • 대규모 조직에는 설정 파일 배포를 관리하는 설정 관리 전담 팀 존재 -> configmap과 secret의 버전 관리 정책이 적합
  • 대안으로 형상 관리 도구에 저장된 YAML 템플릿 파일로 configmap과 secret 정의가 생성되는 완전 자동화된 배치
    • YAML 템플릿 파일에는 실제 민감 정보 대신 해당 정보가 채워질 빈칸을 두고, 해당 빈칸을 Azure KeyVault 같은 안전한 곳에 보관되어 있던 실제 민감 정보로 채워 YAML 파일을 완성하는 방식

Azure KeyVault: 보안 비밀 저장소로, 하드웨어 보안 모듈에서 지원하는 비밀, 키 및 인증서 등을 안전하게 관리할 수 있게 해 주는 서비스

 

• kubectl delete 명령에는 YAML 파일을 읽고 해당 파일에 정의된 리소스를 삭제하는 기능 존재
  • directory 안에 여러 개의 YAML 파일이 있다면 directory를 인자로 지정하여 해당 directory 안에 있는 모든 YAML 파일에 정의된 resources를 삭제(반대로 배치도 가능)할 수도 있음

---

참고자료

• 엘튼 스톤맨 저/심효섭 역 | 길벗 | 2023년 08월 30일 | 원서 : Learn Kubernetes in a Month of Lunches