[Cloud] Kubernetes Volumes II (Storage Class, ConfigMap, Secret)

Storage Class

• PVC: 사용자가 PV를 배정해 달라고 요청하는 것을 Spec으로 정의해 놓은 것
• Storage Class: 관리자가 리소스를 통해 생성할 수 있는 PV 유형을 정의해 놓은 것 (PV 생성 및 연결을 추상화한 것)
  • 이후 사용자가 PVC를 통해 원하는 Volume을 정의해 놓으면 후에 Pod가 생성될 때 자동으로 PV가 생성되고 PVC에 매핑되어 자동으로 Pod에 마운트 되게 됨

 

ConfigMap, Secret

• 사용 목적: 설정 정보와 애플리케이션 코드를 분리하기 위함
• 필요 상황 예시: database의 위치정보(IP 주소 or URL)가 이를 이용하는 응용 프로그램 코드 상에 기록하여 사용하는 상황에서 해당 DB의 service IP 주소가 변경되거나 URL이 변경되면 아래의 과정이 필요

• 이를 Key-value 형식으로 저장해서 설정 데이터를 미리 저장하여 코드 빌드를 다시 할 필요 없이 쿠버네티스 리소스만 수정하면 설정이 바뀔 수 있게 함 
  • 리소스 형태: 둘 다 key, value 쌍으로 데이터를 저장하는 쿠버네티스 리소스
  • 사용 방식: 환경 변수(env), 볼륨 마운트(volumeMount), API 호출 등 애플리케이션에서 불러오는 방식이 거의 동일
  • 저장소: 물리적으로는 둘 다 마스터 노드의 etcd라는 데이터베이스에 저장
• Config vs Secret: Style은 똑같은데 보안이 있고 없고의 차이
  • Secret은 credentials, passwords, certificates 등을 포함
• storage 종류에 속하는데 특수한 경우라 별도로 volume을 만들지 않고 원천적인 storage(etcd)에 들어감
  • 다른 volume처럼 file로 사용할 수 있음
  • environmental variables(환경 변수)로 사용할 수도 있음
    • 인프라 환경 속에서 제공되는 값들(환경 변수)에 직접 값을 줘서 사용할 수 있음
    • 환경 변수는 자유롭게 환경 속에서 사용할 수가 있음

구분	ConfigMap	Secret
데이터 성격	공개되어도 무관한 설정값	보안이 필요한 민감한 데이터
인코딩 여부	일반 텍스트 (Plain Text)	Base64 인코딩
물리적 위치	etcd에 평문 저장	etcd에 저장 (암호화 설정 가능)
용량 제한	1MB 내외	1MB 내외

 

ConfigMap

• Key-Value로 비밀(Secret)이 아닌 데이터를 저장하는 데 사용되는 객체
  • etcd 저장소 안에 생성됨
• 사용 방법: Pod는 ConfigMap을 환경 변수, 볼륨 Mount로 사용 가능
  • Environment variable: 변수로 가져옴
  • Volume mount: 파일로 가져옴
• 사용 목적
  • ConfigMap 사용 시 환경별 구성을 컨테이너 이미지에서 분리 가능
    • >> 배포되는 환경에 따라 설정의 유연한 전환 가능

TEST, DEV, PROD로 저장해놔서 configMap만 변경하면 해당 설정값으로 유연한 전환 가능

• 사용 방법
  • kubectl 명령어로 배포
    kubectl apply -f configMap.yaml

env yaml file setting

yaml 파일로 etcd에 MariaDB 기반 ConfigMap 생성

• data
  • ROOT_PASSWORD: 실제 MariaDB에 사용되는 PW
  • other_variables: 그냥 만들어놓은 환경 변수 (MariaDB가 필요한 변수가 아님)
    • 그냥 저 configMap의 key 값으로 쓰이는 것

MARIADB_ROOT_PASSWORD 환경변수 미설정 시 발생하는 에러

 

env1(whole)  in deployment.yaml

envFrom으로 whole(전체)를 가져감

env2(part)  in deployment.yaml

configMapKeyRef 사용해서 Key reference로 일부만 가져가라

 

volume mount configMap yaml file setting

env(whole)같이 전체를 mount함

volume mount in deployment.yaml

 

 

Secret

• ConfigMap과 스타일은 비슷하지만 보안적인 측면에서 강화하기 편하게 설계된 storage
• etcd에 저장되어 mount 중인 Secret은 k8s가 암호화해주지 않음
  • 직접 암호화해야 함
  • key 관리를 잘해야 함
    • SKT가 이걸 암호화 잘못해서 털렸어요

k8s는 Secret을 암호화하지 않고 관리자가 직접 하게끔 함

• ConfigMap보다 안전한 점
  • 눈 가리고 아웅 (Base64): kubectl get secret을 쳐도 값이 YWRtaW4=처럼 깨져 보여서, 옆 사람이 어깨너머로 슬쩍 봐도 비밀번호를 바로 알 수 없음 (물론 디코딩하면 바로 나오지만, 최소한의 방어선)
  • 흔적 지우기 (tmpfs): Secret을 볼륨으로 마운트 하면, 노드의 디스크(HDD/SSD)가 아니라 RAM(메모리) 공간에 파일을 생성 
    • Pod가 삭제되면 메모리에서 즉시 증발하므로, 서버의 물리적인 디스크에 비밀번호 흔적이 남지 않음

Encryption 방식을 도입해야 함

 

a) Environment variables

Part(Selective) 방식

• 돌아가는 환경에서 사용하는 변수로 Secret을 가져옴
• Secret 객체에 대한 정보는 Pod가 껐다 켜지지 않는 이상 바뀌지 않음

envFrom:                     # 'env'가 아니라 'envFrom'을 사용
  - secretRef:
      name: mysecret         # 이 Secret 안의 모든 Key가 환경 변수로 들어감

• 다음과 같이 설정하면 Whole Secret(전체)을 가져올 수 있음

 

b) Volumes mount

• 환경 변수는 Pod 재시작이 필수지만, 볼륨 마운트는 파일이 시스템상에서 업데이트해 줌
  • kubectl edit 등으로 원본을 수정
    1. Kubelet이라는 관리자가 노드에서 이 변화를 감지
    2. 잠시 후(보통 1분 내외), Pod 내부 마운트 경로에 있는 파일 내용이 자동으로 업데이트됨
    3. 이때 파드는 죽지 않고 그대로 Running 상태를 유지

Secret 객체에 대한 수정 정보를 Pod 재시작 없이 알 수 있는 방법 (Volume Mount)

• Side-car: 옆에 다른 컨테이너(side-car)가 돌아가면서 계속 확인을 하다가 수정됐다면 Inter Process 해서 알려주는 방식
• Polling: 프로세스 내부에 바뀐 부분이 있는지 주기적으로 확인하는 기능을 탑재하는 방식

Polling 방식

• Built-in Type: secret에서 사용하는 암호와 관련된 비밀스러운 정보를 type을 정의해 놓음
  • Opaque (일반형): 가장 범용적으로 쓰이는 타입으로, 자유로운 키-값(DCN, PW 등)을 넣을 수 있음
  • 타입 강제성: kubernetes.io/tls나 kubernetes.io/ssh-auth 같은 특정 타입은 쿠버네티스가 내부적으로 특정 키 값(ex. tls.key, tls.crt)이 있는지 검사함
    • token 쓸 거면 너가 알아서 이름 짓지 마라, 내가 정의해 놓은 거 써라

 

Base64

key 값은 DCN, PW는 1234 / PW는 base64로 encoded 되어있음 (아스키 코드로 보여져서 이상하게 나옴, 암호화 아님)

• MTIzNA==: 암호화한 게 아니라 base64를 아스키로 읽어서 이상하게 나온 것
  • 상용화할 땐 암호화해서 사용해야 함

 

구분	ConfigMap	Secret
데이터 성격	일반 설정 (포트, 로그 레벨, 호스트)	보안 정보 (DB 비번, API 키, 인증서)
저장 방식	시스템 일반 저장소	메모리(tmpfs)에 저장 (보안 강화)
접근 제어(RBAC)	비교적 관대하게 허용함	권한을 가진 사용자 / Pod만 접근하도록 엄격히 제한
데이터 시각화 / 암호화	PlainText / X	Base64 / X