Configmap과 Secret

Configmap과 Secret는 Pod에 바로 연결되고, 사용자가 데이터를 넣고 Pod에 값을 주입시킬 수 있다.

envFrom: Pod 안에 환경변수로 들어가는 속성

Confingmap을 연결하고 Pod 안에 들어가서 env 명령을 사용하면 Configmap의 데이터가 주입된 걸 볼 수 있다.

data의 내용은 key:value 형식으로 저장된다.

Pod가 생성되면 Configmap의 모든 data가 Pod의 환경 변수로 주입된다

실행 명령이 컨테이너 생성 후 자동으로 동작한다, 만약 환경 변수 값이 없으면 실행 명령에 Null로 들어간다

환경 변수 값

spring_profiles_active: App이 인프라의 개발/검증/운영 환경 중 어느 환경에서 기동되는지 알려주기 위한 변수

application_role: App의 역할 (App 하나로 모든 기능을 다 사용할 수 있음 / 스케일링 모드: App 기능 별로 각각 하나씩 기동하면 → 부하가 많이 가는 기능만 별도로 더 기동할 수 있다 )

postgresql_filepath: Secret 데이터로 연결할 파일의 경로, Pod의 mountPath에서 정한다

⇒ App에서 기동할 때 환경 변수 값을 보고 DB의 정보를 확인해서 접속할 수 있음

⇒ Pod의 mountPath를 수정하고 싶을 때 App을 재기동하지 않고 Configmap만 수정해서 간단히 처리할 수 있다

Confingmap에 들어가는 데이터 값

인프라 환경 값

App의 기능을 제어하기 위한 값

외부 환경을 App으로 주입시키기 위한 값

Volume: Pod와 특정 저장소를 연결하는 속성

Secret을 연결하고 Pod안에 들어가서 마운팅된 Path를 조회하면 Secret에 stringData가 있는 것을 볼 수 있다.

stringData는 쓰기 전용 속성이고 실제 저장은 Configmap과 동일하게 data 속성으로 저장되지만, value는 Base64로 인코딩되어 저장된다. - 이 값은 쉽게 디코딩하여 실제 값으로 바꿀 수 있다.

Pod에 mountPath 속성을 주면 컨테이너 안에 path가 만들어지고, volume과 매칭되어 Secret과 연결된다. → 이후 컨테이너 안에 value값이 디코딩된 파일이 생성된다. → App이 기동할 때 DB를 연결(App의 로직)

데이터 암호화 부분은 오브젝트와 별개로 선택해야하는 영역이다. 암호화 방법은 다양하기 때문에 Configmap에 중요한 데이터를 담아서 사용할 수 있다. Secret은 보안 목적 외에도 활용되는 케이스가 다양하다.

Secret을 envForm으로 환경변수로 넣을 때 주의점

기능적으론 가능하지만 Pod에 들어가 env로 누구나 쉽게 정보를 볼 수 있고, App 기동 log로 모든 환경 변수를 출력하는 경우도 많다.

환경 변수는 의도하지 않는 상황에서 중요한 데이터를 볼 수 있는 소지가 발생하므로 Secret을 envForm으로 넣는 방법은 지양하는게 좋다.

대시보드에서는 base64가 아닌 복호화된 데이터로 보여준다

Configmap 확인 실습

Secret 확인 실습

Secret data에서 postgresql-info가 Key인 Value값만 조회 하기 실습

Secret data에서 postgresql-info가 Key인 Value값을 Base64 디코딩해서 보기 실습

Secret 확인 실습

API 확인 실습

datasource는 외부에서 받아와야하는 정보이다.

application의 role, version은 외부에서 값을 받지 못할 경우 default 값 적용

Configmap 수정 실습

환경변수는 Pod가 생성될 때 한 번만 주입되기 때문에 Configmap을 수정한 후 Pod에 접속하면 이전에 수정한 값이 반영되지 않는다

환경 변수를 수동으로 변경하기 실습

강제로 환경 변수를 변경해도 이미 값이 주입되었기 때문에 App에 다시 반영되지 않는다.

Secret 변경 실습

Secret을 볼륨 마운팅으로 연결해 놓은 관계이므로 수정이 반영된다.

App에서는 해당 파일을 5초 간격으로 계속 조회하도록 구성됨

환경 변수는 App 기동 시에 주입되므로 변경되지 않음

Pod 재생성으로 환경 변수 변경 반영 실습

Pod가 재기동된 후 환경 변수의 값이 수정된다.

환경 변수로 주입하는가, 볼륨으로 연결하는가에 따라 실시간으로 App의 값을 반영할 수 있는지 / 없는지 영향을 준다.

쿠버네티스 환경에서 배포와 쿠버네티스 이전 환경(VM 환경)의 배포 차이

쿠버네티스 환경에서는 각 인프라 환경마다 Pod가 생성된다.

각 환경의 컨테이너는 모두 Docker Hub에서 동일한 컨테이너 이미지를 다운로드 받으며, 환경마다 다른 값을 주려고 Confingmap을 만든다

CI/CD 환경에서 컨테이너가 빌드되고, 환경 변수에 맞게 App이 실행된다.

인프라 담당자가 환경마다 서버를 생성한다.

인프라 담당자가 각 환경 변수를 관리한다.

Jar package 파일을 VM 환경에 복사하고 인프라 담당자가 실행 명령을 직접 전송한다.

개발자는 각 환경마다 Properties, DevOps 담당자는 환경 변수 스크립트, 인프라 담당자는 VM 환경 변수를 관리한다 → ConfigMap으로 관리 포인트가 하나로 통일된다.

Secret의 type

기본적으로 type을 지정하지 않으면 epaque(투명) 값이 지정된다.

epaque: Configmap을 사용하는 모든 상황에서 조금 중요한 값이라고 생각되면 이 타입의 Secret으로 대체 가능, Configmap과 거의 유사하다

docker-registry: 컨테이너를 만들 때 Private docker-registry에서 이미지를 가져오고 싶을 때 사용

tls: Pod마다 각 각 다른 보안 인증서를 사용하고 싶을 때 사용

중요한 데이터를 암호화하는 방법

type들 중에서 데이터 암호화를 제공해주는 type는 없다.

1. Secret 오브젝트를 파이프라인에서 생성하지 말고 K8s 클러스터 내에서 생성한다

admin 권한으로 dashboard나 kubectl을 사용하고 있었기 때문에 이 정보를 쉽게 볼 수 있는 것일 뿐, 여러 사람이 사용하더라도 K8s 권한을 철저히 적용하면 아무나 다른 사람의 Secert을 조회하거나 Pod에 접근할 수 없다.

오브젝트를 YAML 파일로 배포하려면 형상관리 서버나 배포 서버를 거쳐야하기 때문에 모든 오브젝트를 K8s내에서만 사용할 수는 없음 → 비밀번호 Secret에 한해 클러스터 내에서 생성하고 관리 : 접근 제어를 통한 보안 관리

2. 문자를 자체적으로 암호화하고, 암호화된 문자를 Secret으로 관리하면 파이프라인를 통해도 실제 비밀번호는 아무도 알 수 없다.

암호화된 Secret을 App 내에서 자체적으로 북호화할 수 있어야하고, 이 기능을 코드로 직접 구현하거나 WAS에서 제공해주기도 한다. 이 방식은 비밀번호를 Secret이 아닌 Configmap에 담아도 괜찮다.

3. 암호화를 관리해주는 써드파티 도구(Hashicorp Valut)를 사용한다.