[Kubernetes] ConfigMap, Secret - Env, Mount

Kubernetes

 

 

이번 포스팅에서는 ConfigMap과 Secret에 관한 설명이다.

 

설명하기에 앞서 해당 오브젝트를 사용해야 하는 상황은 어떤 경우일까?

 

개발 환경과 상용 환경이 있다고 하자.

또한, A라는 서비스가 있다고 가정하자. 이때, A 서비스에는 일반 접근과 보안 접근이 가능하다.

 

A 서비스(개발 환경)

• SSH: False
• User: Dev
• Key: LS0tLs...

 

따라서, 개발 환경에서는 해당 보안 접근을 해제할 수 있는 옵션이 있다.(SSH : False)

만약, 보안 접근을 한다면 접근 유저와 키를 세팅할 수도 있다.(User: Dev, Key: LS0tLs)

 

 

개발 환경에서는 위처럼 사용한다고 하고, 상용 환경에서 배포를 해야 한다면 해당 값은 변경되어야 할 것이다.

 

A 서비스(상용 환경)

• SSH: True
• User: Prod
• Key: MII3Ld...

 

다시 보안 접속으로 설정을 해야 될 것이며, 유저와 키 값도 변해야 한다.

 

그러나, 이 값은 컨테이너 안에 있는 서비스 이미지에 들어있는 값이기 때문에,

해당 내용을 바꾼다는 건 개발 환경과 상용 환경에 관한 컨테이너 이미지를 각각 관리하겠다는 것을 말한다.

 

 

Container for Dev 

• A 서비스(개발 환경)
  • SSH: False
  • User: Dev
  • Key: LS0tLs..

 

Container for Prod

• A 서비스(상용 환경)
  • SSH: True
  • User: Prod
  • Key: MII3Ld...

 

이런식으로 각각 관리해주어야 한다.

 

값 몇 개 때문에 큰 용량의 이미지를 별도로 관리하는 것은 정말 부담되는 일이다.

 

 

따라서, 환경에 따라 변하는 값들을 외부에서 결정할 수 있게 도와주는 것이 ConfigMap과 Secret이라는 오브젝트이다.

 

분리해야 되는 일반적인 상수들을 모아 ConfigMap을 만들고,

키와 같이 보안적인 관리가 필요한 값을 모아 Secret를 만든다.

 

그리고 Pod가 생성될 때 이 두 오브젝트를 연결하여 컨테이너의 환경변수에 해당 데이터들을 넣는다.

그러면 A 서비스 입장에서는 해당 환경변수 값을 읽어서 로직을 처리함으로 위와 똑같은 작업을 할 수 있게 된다.

 

즉, 이미지를 하나 만들어 넣으면 개발 환경/상용 환경에 맞춰 사용이 가능하다.

(상용 환경에서는 ConfigMap과 Secret에 데이터만 바꿔주면)

(똑같은 컨테이너 이미지를 사용해 원하는 기능을 사용이 가능하다.)

 

 

ConfigMap 및 Secret 사용 방법

 

ConfigMap과 Secret을 만들 때 데이터로 상수를 넣을 수 있고 파일을 넣을 수 있다.

그리고 파일을 넣을 때는 환경 변수로 세팅하는 게 아닌 볼륨을 마운트해서 사용을 할 수 있다.

 

ConfigMap

 

ConfigMap은 키와 밸류로 고정이 되어있다.

그래서, 위의 그림처럼 필요한 상수들을 정의해 놓으면 Pod를 생성할 때,

해당 ConfigMap을 가져와 컨테이너 안의 환경변수로 세팅을 할 수 있다.

 

 

Secret

 

그리고 Secret도 똑같은 역할을 하는데 이름처럼 뭔가 보안적인 요소의 값들을 저장하는 용도이다.

주로 패스워드라든지 인증키들은 Secret에 담는다.

 

Secret은 평문으로 쿠버네티스 DB(etcd)에 저장된다.

Secret의 보안적 요소는 Secret를 Pod에 파일로 마운팅해서 사용할 때, Pod 내부에서는 파일이 보이지만,

 

이런 기능을 구현하기 위해서 Kubernetes 입장에서는 workernode에 Secret 파일을 만들어 놓고,

Pod에 이 파일을 마운팅한다. 이때, workernode에 Secret 파일을 인메모리 파일시스템(tmpfs) 영역에

올려놓고 있다가 Pod가 삭제되면 지운다.

 

이렇게 민감한 데이터를 디스크에 저장하지 않기에 Secret의 경우 ConfigMap보다 보안에 유리할 수 있다.

 

주의

Secret은 사용할 때 ConfigMap과 달리 Value를 넣을 때 base64 encoding을 해서 넣어야 한다.

이게 Secret의 보안적인 요소는 아니고 단순히 Secret의 Value를 만들어야 된다는 규칙이다.

Secret이 Pod로 주입이 될 때는 자동으로 decoding이 되어 환경 변수에서는 원래의 값으로 보인다.

 

 

상수 사용

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-dev
data:
  SSH: 'false'
  User: dev

 

YAML 파일 내용을 보면 ConfigMap을 만드는데 이름을 지정하고 이 데이터에 키-벨류 형태의 상수를 넣는다.

 

Secret

apiVersion: v1
kind: Secret
metadata:
  name: sec-dev
data:
  Key: MTIzNA==

 

 마찬가지로, Secret도 이름을 넣고 데이터에 키를 넣고 Value에는 값을 Base64로 변환해서 넣으면 된다.

 

 

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
  - name: container
    image: kubetm/init
    envFrom:
    - configMapRef:
        name: cm-dev
    - secretRef:
        name: sec-dev

 

이제는 Pod를 생성할 때 우리가 앞서 만든 ConfigMap과 Secret를 지정하여 사용하면 된다.

 

컨테이너 안에 env-from이라는 속성으로 ConfigMap을 래퍼런스하고 가져올 ConfigMap의 이름은 cm-dev이다.

마찬가지로, Secret로 래퍼런스하는데 그 이름은 sec-dev이다.

 

 

파일 사용

 

다음으로는 파일을 환경변수에 넣는 방법이다.

 

위의 그림처럼 파일을 통으로 ConfigMap에 담을 수가 있는데 이럴 때 파일 이름이 키가 된다.

파일 안의 내용은 Value가 되어 ConfigMap이 만들어진다.

 

파일을 ConfigMap으로 만드는 것은 대시보드에서 지원해주지 않기 때문에

직접 마스터 콘솔로 들어가 kubectl 명령어를 사용해주어야 한다.

 

kubectl create configmap cm-file --from-file=./file.txt

 

cm-file이라는 ConfigMap을 만들며 ./file.txt 파일을 넣을 거다라는 명령이다.

 

 

Secret의 경우 아래와 같이 명령을 날리면 된다.

kubectl create secret generic sec-file --from-file=./file.txt

 

여기서 한가지 주의할 점은 파일 텍스트 안의 내용이 Base64로 변경이 되기 때문에

만약, 이 파일 안에 내용이 이미 Base64였다면 두번 인코딩이 된다.

 

 

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-file
spec:
  containers:
  - name: container
    image: kubetm/init
    env:
    - name: file-c
      valueFrom:
        configMapKeyRef:
          name: cm-file
          key: file-c.txt
    - name: file-s
      valueFrom:
        secretKeyRef:
          name: sec-file
          key: file-s.txt

 

그래서 Pod를 만드는 것을 살펴보면 컨테이너에 환경변수를 넣을 건데,

이 환경변수의 이름은 file-c이고 그리고 이 파일의 값 valueFrom을 가져올 건데,

그 값은 ConfigMap의 키를 래퍼런스할 것이며(configMapKeyRef) 이름은 cm-file이다.

 

 

Volume Mount

 

마지막으로, 파일을 마운팅하는 방법이다.

 

파일을 ConfigMap에 담는 것까지는 똑같다.

 

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-mount
spec:
  containers:
  - name: container
    image: kubetm/init
    volumeMounts:
    - name: file-volume
      mountPath: /mount
  volumes:
  - name: file-volume
    configMap:
      name: cm-file

 

그러나, 다른 부분은 Pod를 만들 때 컨테이너 안에 Volume을 마운트 할건데

그 /mountPath는 /mount가 되고 마운트할 Volume의 내용을 보면

해당 Volume 안에는 ConfigMap을 담는다.

 

해당 ConfigMap의 이름은 cm-file이다.

 

 

이렇게만 보면 VolumeMount와 파일 사용의 차이를 정확히 알기 어려울 수 있다.

 

만약 Pod를 생성한 다음에 각각의 ConfigMap에 적용된 파일의 내용을 변경하게 된다면 어떻게 될까?

 

환경변수 방식은 한번 주입을 하면 끝이기 때문에 ConfigMap의 데이터가 변해도

Pod의 환경변수 값에는 영향이 없다.

 

해당 Pod가 죽어 재생성이 되어야지만, 이 변경된 값을 다시 받아와서 수정을 할 수 있다.

 

반면에 VolumeMount 방식은 마운트라는게 원본과 연결시켜준다는 개념인것처럼

ConfigMap의 데이터 내용이 변하게 되면 해당 Pod에 마운팅된 내용도 변하게 된다.

 

따라서, 위의 특성을 잘 알고 필요한 상황에 따라 활용을 잘 해야 한다.

 

 

실습

ConfigMap과 Secret에 관한 실습을 진행하겠다.

 

 

ConfigMap

 

ConfigMap은 특별한 거 없이 아래 YAML 처럼 키-벨류 형태로 값을 넣어주면 된다.

 

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-dev
data:
  SSH: 'false'
  User: dev

 

여기서 한가지 주의할 점이 있는데 키-벨류는 모두 스트링 값이다.

그렇기 때문에 만약 boolean 값을 넣고 싶다면 위의 YAML 파일 내용처럼 ''을 달아서 넣어줘야 한다.

만약, 뺀다면 에러가 발생한다.

 

 

 Secret

 

Secret도 마찬가지로 주의해야 할 점은 Key의 Value값에 Base64 Enconding을 하지 않게 되면 오류가 발생한다.

apiVersion: v1
kind: Secret
metadata:
  name: sec-dev
data:
  Key: MTIzNA==

 

 

대시보드에서는 Key의 값을 볼 수 있는 기능이 있어 실습시 편리하지만,

실질적으로 대시보드를 실제 운영에서 사용하지 않는 이유가 이런 중요한 값이 쉽게 노출되기 때문이다.

따라서, 보안상의 이유로 대시보드는 잘 사용하지 않는다고 한다.

 

 

이제는 해당 ConfigMap과 Secret을 연동한 Pod를 생성해보자.

 

 

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
  - name: container
    image: kubetm/init
    envFrom:
    - configMapRef:
        name: cm-dev
    - secretRef:
        name: sec-dev

 

YAML 파일을 살펴보면 Pod의 컨테이너 안에 환경변수로 방금 만든 ConfigMap과 Secret의 이름을 지정해주었다.

 

그래서, 실제로 접속해서 환경변수를 확인해보면 아래와 같이 잘 적용이 된 것을 확인할 수 있다.

Key값을 보면 base64 decoding이 된것을 확인할 수 있다.

 

 

 

다음으로는 file로 ConfigMap과 Secret을 만들어보자.

 

 

ConfigMap(file)

 

앞서, 이론에서 언급했던 것처럼 파일로 ConfigMap을 만드는 것은 대시보드에서 지원해주지 않는다.

따라서, 직접 마스터의 콘솔로 만들어야 한다.

 

 

이런식으로, ConfigMap에 사용될 파일을 만든 뒤 kubectl 명령어를 활용하여 ConfigMap을 생성한다.

 

 

 

실제로, Key는 파일 이름으로 되어있는 형태로 ConfigMap이 잘 생성되었다.

 

 

Secret(file)

Secret도 마찬가지로, 콘솔에서 kubectl 명령어를 통해 만들어준다. 

 

 

이때, base64 encoding을 하지 않아도 명령어에 의해 알아서 encoding을 해준다.

 

 

Secret도 Key값을 파일이름으로 갖으며 잘 생성이 되었다.

 

 

자, 이제는 관련해서 `Pod를 생성해보자.

 

 

Pod(file)

apiVersion: v1
kind: Pod
metadata:
  name: pod-file
spec:
  containers:
  - name: container
    image: kubetm/init
    env:
    - name: file-c
      valueFrom:
        configMapKeyRef:
          name: cm-file
          key: file-c.txt
    - name: file-s
      valueFrom:
        secretKeyRef:
          name: sec-file
          key: file-s.txt

 

기존의 envFrom 키워드와는 달리 env 키워드를 사용해서 환경변수를 명시를 한다.

이때, 이 환경변수에 방금 만든 ConfigMap의 키를 매칭시킨다.

 

Secret도 마찬가지로, 키를 매칭시켜준다.

 

 

생성한 Pod를 살펴보면 ConfigMap과 Secret의 내용이 잘 들어가있는 것을  확인할 수 있다.

 

 

마지막으로는 VolumeMount(File)에 관해 알아보겠다.

 

 

VolumeMount(File)

 

Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-mount
spec:
  containers:
  - name: container
    image: kubetm/init
    volumeMounts:
    - name: file-volume
      mountPath: /mount
  volumes:
  - name: file-volume
    configMap:
      name: cm-file

 

 

마운트 경로에 file-c.txt가 잘 있는 것을 확인할 수 있다.

 

이론에서 설명했던 것처럼 VolumeMount의 경우 file의 데이터가 변경되었을 때 적용이 된다고 말했었다.

한번 확인해보자.

 

file-c.txt의 값을 변경한 뒤 확인해보면

 

 

잘 변경된 것을 확인할 수 있다.