[Kubernetes] Application 기능으로 이해하는 ConfigMap, Secret

ConfigMap, Secret 기본 개념

ConfigMap

컨테이너 내부의 환경 변수를 주입하기 위해 ConfigMap을 사용한다.

ConfigMap의 data 속성 내에 key:value 형식으로 주입할 수 있다.

 

ConfigMap에 들어가는 데이터에는 크게 아래와 같은 종류가 있다.

• 인프라 환경에 따른 변수
• App의 기능을 제어하기 위한 변수
• 외부 환경을 App으로 주입시키기 위한 변수

환경 변수는 Pod가 생성될 때 한 번만 주입되기 때문에,

Pod가 생성된 이후 ConfigMap의 값을 바꾼다고 해서 Pod의 환경 변수가 변경되진 않는다.

Secret

조금 더 중요한 환경 변수를 담기 위해 Secret을 사용한다.

Secret의 stringData 속성에 파일일 이름과 해당 파일에 담을 내용을 기입하는 형태로 구성하고,

해당 파일을 Pod에서 Volume Mount 하여 사용한다.

(ConfigMap처럼 각 변수를 나열하는 형태로 구성하는 것도 가능하지만, 이렇게는 잘 사용하지 않는다.)

 

stringData 속성은 쓰기 전용 속성이고, 실제 저장은 ConfigMap과 같이 data 속성으로 저장된다.

이때 내용을 보면 key값은 그대로 있고, value에 해당하는 부분이 base64로 인코딩 되어 저장된다.

 

base64 인코딩은 암호화가 아니고, Secret의 다른 보안 요소가 조금 더 있지만 크게 도움이 되지는 않는다.

따라서 중요한 데이터를 암호화하는 것은 ConfigMap, Secret과는 별개로 생각해야 한다.

(암호화 방법은 다양하기 때문에 ConfigMap에 중요한 데이터를 넣어서도 안전하게 사용할 수 있는 방법이 있다.)

 

Secret은 Volume Mount가 되어 있으므로 파일의 내용이 바뀌면 Pod에서 반영된 결과를 확인할 수 있다.

또한 Secret은 보안 목적 외에도 활용되는 케이스가 많다는 점을 기억하고 넘어가자.

 

영역 파괴의 주범 ConfigMap

쿠버네티스가 아닌 환경에서는 개발 환경, CI/CD 환경, 인프라 환경마다 각각 환경 변수들을 관리한다.

반면 쿠버네티스에서는 ConfigMap에서 위의 환경 변수를 한 번에 관리할 수 있다.

기존 프로젝트를 쿠버네티스로 전환하는 경우에는,

각 환경 담당자들의 쿠버네티스 이해도가 부족할 수 있고 영향도가 클 수 있기 때문에,

각 담당자들에게 잘 설명해 가며 자주 변경될 소지가 있는 부분부터 ConfigMap으로 하나씩 바꾸는 것을 권장한다.

 

이름 때문에 기대가 너무 컸던 Secret

Secret은 조금 더 중요한 환경 변수를 담기 위해 사용된다고 했는데, 사실 와닿지가 않는다.

따라서 Secret이 어떤 경우에 사용되는지 더 알아보며 이해해 보자.

Secret은 ConfigMap과 달리 type 속성이 존재한다.

type 속성이 없으면 기본으로 opaque가 들어가는데, 이는 ConfigMap과 비슷한 기능을 한다고 보면 된다.

 

하지만 다른 type을 사용한다면 ConfigMap과 기능이 전혀 달라진다.

이는 아래와 같이 쿠버네티스에서 사용자 편의에 따라 커스텀하게 관리할 수 있는 요소를 제공하는 것인데,
이를 사용할 때 Secret이 key와 value를 설정하는 템플릿 역할을 수행한다.

(아래의 예시들 말고도 몇 가지 타입들이 더 존재한다.)

 

type : docker-registry

docker-registry 타입을 선택하면 data로 반드시 아래와 같은 key를 추가해야 한다.

• docker-username
• docker-password
• docker-email

해당 타입은 컨테이너를 만들 때 private docker registry를 사용하는 경우 Pod에 연결하여 사용한다.

해당 타입의 Secret이 Pod에 연결되어 있는 경우 쿠버네티스가 해당 docker registry에서 이미지를 다운로드한다.

 

type : tls

tls 타입을 선택하면 data로 반드시 아래와 같은 key를 추가해야 한다.

• tls.crt
• tls.key

해당 타입은 Pod마다 각각 다른 보안 인증서를 심을 때 사용한다.

 

데이터 암호화

안타깝게도 이런 type들 중에 데이터 암호화를 제공해 주는 것은 없다.

따라서 중요 데이터에 대한 암호화는 아래와 같은 방식을 통해 진행해야 한다.

1. Secret 생성을 파이프라인에서 관리하지 않고 Cluster에서 직접 관리
   • 사실 admin 권한으로 dashboard나 kubectl을 사용하지 않는 경우 데이터에 접근하기 쉽지 않다.
   • 여러 사람이 사용하더라도 쿠버네티스 관리 권한을 철저히 적용하면 아무나 남의 Secret을 조회하고 Pod에 들어갈 수 없다.
   • 다만 Object를 yaml 파일로 배포하려면 형상관리나 배포 서버를 거쳐야 하기 때문에, 중요 정보가 포함된 Secret에 한해서만 이에서 제외하고 Cluster에서 직접 관리하여 접근 제어를 통한 보안 관리를 할 수 있다.
2. 자체 암호화
   • 이는 문자를 자체적으로 특정 key를 가지고 암호화하는 방식이다.
   • 이 때는 App 안에서 해당 값들을 복구해 줄 수 있는 로직을 포함해야 한다.
   • 이런 방식은 Secret이 아닌 ConfigMap을 사용해도 무방하다.
3. 서드파티 암호화 도구 사용 (Vault 등)
   • 관리자에 한해서 ID 및 password로 접속하여 App에서 사용할 비밀번호를 관리한다.
   • 관리자가 지정한 Pod에만 값을 주도록 세팅할 수 있다.

2번, 3번의 장점은 누가 Cluster에 접근했다고 하더라도 App의 중요 데이터가 노출되는 일을 막을 수 있다.

---

출처

https://www.inflearn.com/course/쿠버네티스-어나더-클래스-지상편-sprint1

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 | 일프로 - 인프런