ConfigMap and Secret

ConfigMap과 Secret이란?

ConfigMap 과 Secret은 쿠버네티스에서 Pod에 동적으로 환경변수를 제공하거나, 설정 파일을 전달하기 위한 리소스라고 할 수 있다. 이 두 리소스는 애플리케이션 설정 값이나 보안 자격증명을 분리해 관리하기 위해 사용된다. 얘네는 PVC와 같은 레벨의 스토리지에 해당하기 때문에 미리 준비시키는게 아니라 쓰는 입장에서 가상으로 준비된다

ConfigMap

📌목적

비밀정보가 아닌 애플리케이션의 환경설정 데이터(DB 위치, API key)를 Pod에 전달하기 위해서이다.

📌특징

암호화 없이 평문으로 저장된다. 그리고 etcd에 Key:Value 형식으로 저장된다. 뭐 예시라고 한다면 Pod의 환경변수로 참조, 파일 형태로 마운트 이런 사용 예시가 있다.

📌활용 예시

• MongoDB의 URL 설정
• API Endpoint 정보를 제공

Secret

📌목적

**비밀정보(ID, password, token)**을 안전하게 Pod에 전달하기 위해서이다.

📌특징

Base64로 인코딩된다. (이게 암호화는 아니라는 것을 꼭 기억해야함!!!!) 그래서 별도의 암호화 방법을 추가로 적용해야 진정한 보안이 가능하다.

📌한계

기본적으로 암호화가 없기 때문에, 루트 접근으로 etcd를 읽으면 Base64 디코딩만으로 비밀정보를 확인할 수 있다.

<aside> 💭

ConfigMap과 Secret의 차이??

일단 둘다 키-값 쌍으로 저장되는 것과, etcd에 저장된다는 것에서 공통점이 있지만, ConfigMap은 데이터를 아예 평문으로 저장해 별도의 인코딩, 암호화가 없고, Secret은 적어도 인코딩은 해준다는 점에서 차이가 있다.

</aside>

Secret의 데이터 전달 방법

1. 환경변수로 전달

Secret 데이터를 환경변수로 Pod에 전달한다. spec.env: 안의 필드에 넣어서 사용한다.

다만 치명적인 한계가 Secret 변경할 때마다 pod를 죽였다가 살려야 한다.

2. Volume mount로 전달

secret 데이터를 볼륨에 마운트하여 Pod에서 파일로 사용한다. 환경변수 방식과는 다르게 secret 변경 시 Pod 재생성 없이 업데이트가 가능하다.

그렇다면 왜 Pod를 재생성하지 않고 업데이트 할 수 있는걸까??

볼륨을 통해 컨테이너에 연결되기 때문에 볼륨을 Pod 내부에 챱 붙여놓는 방식이라고 표현할 수 있겠다. kube-proxy가 주기적으로 읽어서 변경된 설정을 반영한다.

근데 또 여기서 발생할 수 있는 문제가, 변경된 파일을 만약 알아차리지 못한다면? 이를 해결하기 위해 사이드카 컨테이너를 활용한다.

<aside> 💭

사이드카 컨테이너? Pod내 메인 컨테이너와 함께 동작하는 보조 컨테이너이다. 메인 애플리케이션을 지원하기 위한 목적으로 설계된 컨테이너이다. Configmap이나 secret 파일을 주기적으로 감시해서, 변경되었을 때 애플리케이션(메인 컨테이너)에 신호를 보내고, 애플리케이션이 이를 적용한다. 사이드카가 파일 변경 작업을 처리해주기 때문에, 메인은 Pod를 재시작하지 않고도 업데이트 할 수 있게 된다!! (like 해그리드 오토바이 사이트카 느낌?)

</aside>

3. Client API Consumption

secret 데이터가 etcd에 저장되고, 이를 안전하게 접근하기 위해서는 API Server를 통해야 한다. 예를 들어 Spring Cloud Kubernetes는 API server와 통신하여 secret데이터를 읽어올수 있다. 이는 RBAC를 통해 권한을 부여해서 그런거다. 근데 추천하는 방법은 아니다. 추가적으로 관리해야 할게 많고, 애플리케이션이 API server와의 연결을 직접 관리해야 하기 때문이다.

Secret 데이터의 보완 강화

그냥 단순히 etcd에 저장된 secret 데이터는 앞서 말했듯이 인코딩만 되어 있으며, 등급 높은 사용자(root 계정)가 읽을 수 있다는 문제점이 존재한다.

이를 해결하기 위해서

Vault라는 오픈소스를 사용한다. 얘는 Secret 데이터를 암호화해서 저장해준다.