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

Configmap, Secret 개념 설명

 

• ConfigMap 과 Secret 모두 Object 의 속성을 보면 데이터를 담을수 있음. (ConfigMap:data / Secret:stringData)
• envForm 은 Pod의 환경변수를 저장하는 공간.
• Pod 에서 envForm 을 보면 Configmap 의 data가 주입되어 있다.
• Volume 은 Pod 와 특정 저장소를 연결하는 속성. 

 

Configmap 기능 설명

 

• 앞선설명 처럼 ConfigMap의 값은 Pod의 환경변수로 들어간다.
• "key" : "value" 의 쌍으로 저장하고 있다.
  • ex) spring-profiles-active : "dev" -> pod 실행환경을 dev(개발) 환경으로 설정.
• 보통 ConfigMap 으로 관리되는 값에는 크게 다음과 같이 나열할 수 있다.
  1. 인프라 환경에 따른 값 (spring-profiles-active)
  2. 앱의 기능을 제어하기 위한 값 (application_role)
  3. 외부환경을 앱으로 주입해주는 값 (postgresql_filepath)
• ConfigMap 의 동작
  • Pod 실행과 동시에 ConfigMap 의 값이 Pod 에 주입된다.
  • 어플리케이션 실행에 필요한 환경변수들이 해당 환경변수를 사용하여 어플리케이션이 기동된다.
  • 만약 값이 없다면 null 이 주입된다.

Secret 기능 설명

 

• Secret 의 동작
  • stringdata 를 통해 특정 yaml 파일을 생성함.
  • 오브젝트 저장시 stringdata 파일을 기반으로 ConfigMap 처럼 data 파일을 생성하는데 이때 value 정보를 Base64 방식으로 인코딩 처리하여 저장한다.
  • Pod 에 mountPath 를 설정하면 컨테이너 안에 path 가 생성된다.
  • 이 path 와 volume 이 매챙되어 Secret 과 연결되어 Secret 에서 생성하는 yaml 파일이 pod 에 생성된다.
  • 생성되는 파일안에 value 값은 다시 디코딩 된상태로 생성된다.
  • 이름이 Secret 이라고 해서 꼭 암호화적인 내용이 해당값에 설정되는 것은 아니다.
  • 기능적으로 Secret 을 envForm 에 연결하여 사용할 수도 있지만 권장되는 이용방식은 아니다.

동작 확인

• 이전에 설치한 k8s dashboard 를 통해 기동되는 k8s 의 ConfigMap과 Secret 안에 값을 설정할 수 있다.
• 동작확인 링크 (link)
• Pod 안에서 env 를 통해 내부 환경변수 확인도 가능하다.
• 만약 k8s dashboard 안에서 ConfigMap 의 값을 변경한다 하더라도 이미 기동된 Pod 에는 해당값이 적용되지 않는다.
  • 환경변수 값은 Pod 기동시 한번만 주입되기 때문.
  • Pod  안에서 export 를 통해 환경변수를 직접 변경하더라도 해당 환경변수를 사용하는 어플리케이션은 이미 이전 내용으로 기동이 된 상태이기에 기동 값은 변경되지 않는다.
• Secret 의 경우 만약 VolumeMount 로 설정한 상태라면 dashboard 에서 값을 변경할 시 곧 바로 적용이 된다.

 

영역 파괴의 주범 ConfigMap

 

• VM 환경과 쿠버네티스 환경으로 ConfigMap 활용을 비교.

기존 VM 환경(k8s이전환경) 에서의 배포

• 기존 VM 환경 (꼭 VM 은 아니더라도 k8s 환경이전) 에서는 각 환경변수를 개발자 / DevOps / 운영관리자 가 각자 자기가 사용하는 환경에 맞게 환경변수를 구성한다.
• 개발자는 각 환경에 맞는 값을 Properties 파일을 분리하여 관리하게 된다.

• CI/CD 와 인프라 환경에서도 동일하게 개발자가 배포한 properties 의 내용을 바탕으로 각 환경의 구성값들을 나누어 관리하게 된다.
• 이때 모든 환경값의 설정은 각 데브옵스/인프라 담당자가 직접 관리해야 하며, 서로의 설정값들은 공유되지 않는다.

 

k8s 환경에서의 배포

• k8s 환경에서는 이러한 설정값을 ConfigMap 하나로 편햐게 관리할수 있게 구성된다.
• 쿠버네티스 환경에서의 배포는 아래와 같다.

 

• 개발 환경에서는 VM 환경과 동일하게 개발자가 Properties 를 통해 환경값을 관리한다.
• 이후 형상관리를 통해 개발자가 소스를 커밋하게 되면 파이프라인 CI/CD 환경을 통해 서버로 배포가 진행된다.
• 이 파이프라인 관리는 데브옵스가 진행하게 된다.

• 파이프라인을 거친 프로덕트(jar or api) 는 도커허브에 이미지로 올라가며 이 이미지는 쿠버네티스에서 사용하는 configMap의 값에 따라 Pod 에 각 환경에 맞는 이미지로 실행되게 된다.
• 여기까지 보면 쿠버네티스 환경 이전에는 각자의 영역에서 담당자들이 관리하는 환경변수들이 있었는데, 쿠버네티스가 나오고 이 ConfigMap에서 모든 역할을 다 할 수가 있게 된 것.
• ConfigMap을 담당하는 사람이 다른 영역을 넘나들 수 있게 되고 이런 소지를 주는 Configmap을 좀 과격한 표현으로 영역 파괴의 주범이라고 표현할 수 있다.
• 개발자 입장에서 k8s에 익숙하다면 configMap 관리를 통해 이미지 빌드없이 사용될수 있는 편리함은 있지만, 이러한 남용적인 사용은 다른 담당자들의 영역을 침범할수 있는 오해의 소지가 있으므로 잘 조절하여 사용해야 한다.

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

• Secret 은 중요한 데이터를 관리하기 위한 목적.
• 이라고.. 하는데 말로 설명하기가 애매한 점들이 많음.
• 케이스를 통해 이해해보기가 필요하다.

Secret 이 사용되는 케이스

• Secret 은 ConfigMap 과 달리 type 속성이 있다.
• opaque : type 지정을 안하면 설정되는 Default 값으로 이경우에는 ConfigMap 의 기능과 동일하게 동작한다 볼수 있다.
• docker-registry  :  Private-Docker hub 사용시에 입력하는 값. data 값으로 private-registry  값을 설정하여 넣어야 하며 Pod 는 이미지를 private docker hub 에서 가져와 사용하게 된다.
• 이처럼 각 Secret 타입에는 필요한 key value 값들이 있으며 이는 추후에 정리할 예정이다.
• tls : 보안 인증서 정보를 입력할때 사용하는 타입.

 

하지만 이러한 타입들은 모두 암호화와는 관련이 없다.

실제 암호화 관리는 다음과 같다.

 

1. 클러스터 내에서 암호화를 직접하여 관리하는 방법 
   • 파이프라인에서 사용하지 않고 클러스터 생성과 별개로 Secret 을 생성한다.
   • 이렇게 생성한 Secret에 대한 접근을 각 계정에 분리하여 사용하게 하면 계정간 중요정보를 분리할 수 있다.
2. 기존 암호화 방식처럼 암호화 키를 이용하여 관리하는 방법
3. 암호화 관련 서드파티를 사용하는 것 ex) Vault