[1-6] Application 기능으로 이해하기 - Configmap, Secret

📒 Configmap

• Pod에 바로 연결이 됨
• env-from은 파드 안에 환경 변수로 들어가게 하는 속성
• configmap을 연결하고 파드 안에 들어가서 env라는 명령을 쳐보면 이 configmap에 데이터가 주입된 것 확인 가능
• 인프라 환경에 따른 값, 앱의 기능을 제어하기 위한 값, 외부 환경을 앱으로 주입시키기 위한 값 3가지로 나뉨
• 데이터의 내용을 보면 Key Value 형식으로  되어있음

Spring Profiles Active

• 인프라에는 다양한 환경, 그러니까 개발 검증, 운영 환경 등이 있음
• 이 앱이 어느 환경에서 돌아가는 건지 앱이 기동되는 시점에 알려주기 위한 변수

ApplicationRole

• 이 앱의 역할을 지정
• 예를 들어 한 앱에 크게 세 가지 기능이 있음
• 이 앱 하나로 모든 기능을 다 쓸 수도 있지만
• 스케일링 모드라고 해서 이 앱을 기능별로 각각 하나씩 세 개를 띄움
• 이러면 부하가 많이 가는 기능만 별도로 더 띄울 수가 있음
• 요즘은 마이크로 서비스 아키텍처를 반영해서 이렇게 만들어진 오픈소스가 많음

PostgreSQL_filepath

• secret 데이터로 연결할 파일의 경로
• 이 경로는 Pod의 mountPath에서 정함
• 이 경로를 환경 변수로 주면 앱에서 기동할 때 환경 변수 값을 보고 DB의 정보를 확인해서 접속할 수 있도록 로직이 되어 있음
• Pod에서 mountPath의 경로를 바꾸고 싶을 때 앱을 다시 빌드하지 않고 configmap만 수정해서 간단하게 처리를 할 수가 있음

 

---

 

📕 Secret

• Pod에 바로 연결이 됨
• 그리고 volume은 pod와 특정 저장소를 연결하는 속성
• secret을 연결하고 pod 안에 들어가서, 마운팅된 패스를 조회해보면 secret에 stringData 확인 가능

 

stringData

• 데이터베이스 정보가 있음
• 위의 그림처럼 저장시키면 쓰기 전용 속성
• 실제 저장은 Confinmap과 같이 data라는 속성으로 저장이 됨
• 키값은 그대로 있고 뒤에 Value에 해당하는 부분이 Base64 인코딩된 값으로 바뀌어서 저장이 됨
• 하지만 이 값은 쉽게 디코딩해서 실제 값으로 바꿀 수가 있음(보안적인 요소가 적음)

 

mountPath와의 관계

• Pod에 mountPath 속성을 주면 컨테이너 안에 path가 만들어짐
• volume이 매칭이 돼서 secret이랑 연결이 되고 컨테이너 안에 파일이 만들어짐
• 앱이 기동할 때 이 파일을 읽어서 DB를 연결하도록 로직 처리

 

Secret 뭐하러 사용하나.. configmap에 비밀번호를 넣어서 쓰면 안될까?
A : 그래도 된다, secret은 보안 목적 외에도 활용되는 케이스가 많아 데이터 암호화 부분은 이 object들과 별개로 생각하자.
방금 이 DB 정보를 configmap에 담고 volume 형태로 연결해도 된다고 했듯이, 반대로 Secret을 envfrom으로 환경 변수로 넣을 수도 있음. 이건 기능적으로는 가능하지만, 파드에 들어가서 env라고 치면 누구나 쉽게 DB 정보를 볼 수 있게 되고, App 기동 log로 나한테 적용된 환경 변수를 다 찍는 경우도 많음. 이렇게 환경 변수는 의도하지 않은 상황에서 중요한 데이터를 볼 수 있는 소지가 생기니까 지양하자.

 

 

---

 

Pod가 생성될 때

• configmap에 있는 데이터의 모든 내용이 컨테이너 내부의 환경 변수로 주입
• java 실행 파일 명령이 컨테이너 생성 후에 자동으로 동작하면서 환경 변수 값들이 매칭 돼서 들어감(없다면 null로 처리)
• 환경 변수는 Pod가 생성될 때, 한 번만 주입되기에 Configmap의 값만 수정한다고 바뀌지 않음
• export application_role=GET 와 같이 강제로 환경변수 값을 변경하더라도
• App을 실행시킬 때, 이미 값이 들어가고 끝났기 때문에 반영 X 

 

---

 

⭐️ k8s에서 configmap

 

• 각 환경마다 파드가 만들어지고
• 이 파드에 들어가는 컨테이너는 도커 허브에서 모두 같은 이미지를 다운받음
• 하지만 환경마다 다른 값을 주려고 이렇게 Configmap을 만드는 것
• 그래서 이미지 안에 변수 값을 받아서 실행하는 명령어가 있음

 

Configmap이 목적만 보면 간단해 보일 수가 있지만 프로젝트 상황에 따라서 이렇게 영역을 넘나들 수 있고 또 정답이 없기 때문에 영역 파괴의 주범이다. 따라서 프로젝트 전체적으로 봤을 때 어떻게 관리하는게 유리한지 깊은 고민을 해보자.

 

 

---

 

🌳 Secret의 여러 용도

 

• secret은 사용자 편의에 따라 커스텀하게 관리할 수 있는 요소를 제공해줌
• 아래 이외의 3,4가지 정도 type이 더 있으나 데이터 암호화를 제공해 주는 것은 없음

opaque

• Secret은 사실 ConfigMap이랑 달리 type이라는 속성이 있음
• 기본적으로 넣지 않았을 때 opaque라고 해서 투명이라는 의미의 값이 들어감
• ConfigMap을 써도 되는 모든 상황에 조금 중요한 데이터라는 생각이 되면 이 타입의 Secret으로 대체를 할 수가 있음
• 따라서 이 타입을 쓰면 configmap과 똑같다고 볼 수가 있음

docker-registry

• Private Docker Registry를 설치하고 이미지를 가져오고 싶을 때
• 위의 정해진 키와 value 값을 넣어서 pod에 붙이면 됨

tls

• pod마다 각각 다른 보안 인증서를 심을 때 사용함

 

---

 

🔐 데이터 암호화 방법

1. secret에 대한 object 생성을 파이프라인에 태워서 만들지 말고 k8s 클러스터 내에서 직접 만들고 관리

• 문제는 object를 yaml 파일로 배포하려면 형상관리 서버나 배포 서버를 거쳐야 됨
• 모든 object를 k8s 내에서만 사용할 수가 없음
• 그래서 비밀번호를 넣은 Secret의 경우에 한해서만 클러스터 내에서 만들고 관리하자
• 접근 제어를 통한 보안 관리 방법

2. 문자를 자체적으로 암호화함

• 특정 키를 가지고 문자를 암호화해 놓고, 이 암호화된 문자를 secret으로 관리
• 파이프라인을 태우다가 중간에 이 문자를 누가 보더라도 실제 비밀번호는 알 수가 없음
• 이런 방식이라면 configmap에 비밀번호를 담아도 괜찮음

3. 암호화를 관리해주는 서드파티 도구 사용

• HashiCrop 의 vault가 대표적
• 앱이 기동하면서 서드파티 앱에 비밀번호를 요청
• 지정한 파드에만 값을 주도록 세팅 가능

 

두번째와 세번째 방법의 장점은 누가 클러스터에 접근 했더라도 앱에 중요 데이터가 노출되는 일은 막을 수 있음

 

 

---

 

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로