[Kubernetes] 시크릿을 사용하는 다양한 방법 - Secrets

 

쿠버네티스에서는 환경 변수나 새롭게 작성한 파일을 컨테이너 내부에 전달해주기 위해서 Configmap, Secret 을 사용합니다. 

 

이름에서 유추할 수 있듯 Configmap 은 보안적으로 중요치 않은 데이터들을 사용할 때, Secret 은 보안적으로 중요한 데이터를 사용할 때 사용합니다. 따라서 Configmap 은 Plain Text 로 데이터가 저장되는 반면, Secret 은 인코딩 되어 저장됩니다.

 

그래서 이번 글에서는 Secret 을 생성 후 어떻게 파드에게 전달하는 지를 알아보려고 합니다.

 

여담으로 Secret 의 인코딩 되는 방법은 사실 디코딩 하면 어떤 값인지 알 수 있기 때문에 보안적으로 안전하지는 않습니다. 쿠버네티스는 이렇게 굳이 Secret 의 값을 인코딩해서 저장하는 이유는 해커에게 혼돈을 주기 위해서라고 합니다.

만약, 정말 보안적으로 안전하게 Secret 을 관리하고 싶다면, RBAC 를 통해 접근 권한을 제한하거나 Vault 와 같은 키 매니저 툴을 이용하면 됩니다.

 

그럼 렛츠두더코드~

렛츠두더코드

 

 

시작하기 전에

---

쿠버네티스에서는 Secret 을 주입하는 방법으로 크게 2가지가 있습니다.

• Env 을 이용한 방법
• Volume 을 이용한 방법

 

차례대로 하나씩 알아보도록 하죠 !

 

(공식 문서가 궁금하다면 여기)

 

 

Env 을 이용한 방법

 

가장 기본적인 Secret 의 데이터 처리

(공식 문서가 궁금하다면 여기)

 

apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi # 39528$vdg7Jb
  username: bXktYXBw # my-app
kind: Secret
metadata:
  creationTimestamp: null
  name: env-each-secret
---
apiVersion: v1
kind: Pod
metadata:
  name: env-each-secret
spec:
  containers:
  - name: tester
    image: nginx
    env:
    - name: SECRET_USERNAME # 컨테이너 내에서 등록 될 환경변수의 이름
      valueFrom:
        secretKeyRef:
          name: env-each-secret # secret 의 이름
          key: username # secret data 에 명시된 키
    - name: SECRET_PASSWORD # 컨테이너 내에서 등록 될 환경변수의 이름
      valueFrom:
        secretKeyRef:
          name: env-each-secret # secret 의 이름
          key: password # secret data 에 명시된 키

 

df -h

 

Volume 이 아닌 Env 방식이기 때문에 마운트된 경로는 따로 없습니다.

 

 

env

 

env 를 실행한 결과 SECRET_USERNAME 과 SECRET_PASSWORD 값을 볼 수 있습니다.

 

위에서 언급했던 것처럼 Secret 이 값이 컨테이너 내에선 이런 식으로 완전히 노출되기 때문에 RBAC 를 통해 접근 제한을 반드시 해야합니다.

 

위에 방법은 가장 기본적이고 깔끔합니다. 하지만 Secret 의 data 갯수만큼 .spec.containers[].env 의 리스트 또한 늘어난다는 단점이 있습니다. 만약 Secret 의 data 가 100개라면 pod.yaml 의 코드가 상당해지죠.

 

그럼 바로 이어서 data 갯수가 많은 경우에는 어떻게 처리해야 하는 지 알아보겠습니다.

 

 

한꺼번에 Env 로 Secret 의 data 처리

(공식 문서가 궁금하다면 여기)

 

apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi # 39528$vdg7Jb
  username: bXktYXBw # my-app
kind: Secret
metadata:
  creationTimestamp: null
  name: env-all-secrets
---
apiVersion: v1
kind: Pod
metadata:
  name: env-all-secrets
spec:
  containers:
  - name: tester
    image: nginx
    envFrom:
    - secretRef:
        name: env-all-secrets

 

확연히 pod.yaml 의 코드 수가 적어졌습니다.

 

df -h

 

Volume 이 아닌 Env 방식이기 때문에 마운트된 경로는 따로 없습니다.

 

env

 

env 를 실행한 결과 SECRET_USERNAME 과 SECRET_PASSWORD 값을 볼 수 있습니다.

 

Secret 의 data 를 하나하나 처리할 필요없이 한꺼번에 처리할 수 있다는 장점이 있습니다.

 

그럼 이제는 Env 가 아닌 Volume 을 통해 Secret 를 처리하는 방법에 대해 알아보겠습니다.

 

 

기본적인 Volume 을 통한 Secret 의 데이터 처리

(공식 문서가 궁금하다면 여기)

 

apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi # 39528$vdg7Jb
  username: bXktYXBw # my-app
kind: Secret
metadata:
  name: volume-basic-secret
---
apiVersion: v1
kind: Pod
metadata:
  name: volume-basic-secret
spec:
  containers:
    - name: tester
      image: nginx
      volumeMounts:
        - name: test-secret
          mountPath: /etc/secret-volume
          readOnly: true
  volumes:
    - name: test-secret
      secret:
        secretName: volume-basic-secret

 

df -h

 

Volume 을 이용했기 때문에 Env 와 달리 마운트 경로가 존재합니다. 기본적으로 마운트는 tmpfs 로 됩니다.

Configmap 과 달리 Secret 은 Volume Mount 할 경우 tmpfs 로 마운트 됩니다.
tmpfs 는 RAM 기반의 가상 파일 시스템으로 물리적인 하드웨어가 탈취 당해도 공격자가 시크릿을 취득하기 어렵습니다.

 

 

 

그리고 Env 와 달리 Secret 의 data 가 password, username 의 파일로 존재합니다. 이 파일은 심볼릭 링크가 걸려있는 걸 볼 수 있습니다. 실제 파일은 ..data 경로에 있는 파일입니다.

 

이 방법은 Secret 의 data 가 한꺼번에 처리됩니다. 만약 하나하나 다른 경로에 처리하고 싶다면 아래와 같은 방법을 이용해 볼 수 있습니다.

 

Volume 을 통해 하나하나 Secret 의 데이터 처리

(공식 문서가 궁금하다면 여기)

 

apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi # 39528$vdg7Jb
  username: bXktYXBw # my-app
kind: Secret
metadata:
  name: volume-basic-secret
---
apiVersion: v1
kind: Pod
metadata:
  name: volume-basic-secret
spec:
  containers:
  - name: tester
    image: nginx
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: volume-basic-secret
      items:
      - key: username
        path: my-group/my-username

 

df -h

 

Volume 을 이용했기 때문에 Env 와 달리 마운트 경로가 존재합니다.

 

 

 

/etc/foo 밑에 /my-group/my-username 에 usernmae 의 data 만 마운트 될 걸 확인할 수 있습니다.

 

또 쿠버네티스에선 posix 로 파일을 마운트하기 때문에 권한 설정도 할 수 있습니다.

 

Volume 을 통해 전달된 Secret 의 데이터 권한 설정

(공식 문서가 궁금하다면 여기)

 

apiVersion: v1
data:
  password: Mzk1MjgkdmRnN0pi # 39528$vdg7Jb
  username: bXktYXBw # my-app
kind: Secret
metadata:
  name: volume-posix-secret
---
apiVersion: v1
kind: Pod
metadata:
  name: volume-posix-secret
spec:
  containers:
  - name: test
    image: nginx
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: volume-posix-secret
      defaultMode: 0400

 

df -h

 

Volume 을 이용했기 때문에 Env 와 달리 마운트 경로가 존재합니다.

 

 

어? 이상합니다.. 0400 으로 설정했는데 실제로 보니 0777 입니다.

 

이는 사실 제대로 된 것이 맞습니다. 보면 심볼릭 링크가 걸려 있는데 심볼릭 링크의 특징을 생각해보면 크게 문제될 것은 없어보입니다.

 

 

심볼릭 링크의 대상 파일은 실제로 0400 이 잘 설정되어있습니다.

 

 

이번 글에서는 Secret 의 data 를 처리하는 방법에 대해 알아보았습니다. 매번 헷갈리는 부분이죠..

Configmap 의 data 를 처리하는 방법은 Secret 과 99% 유사합니다. Secret 을 알면 Configmap 또한 쉽게 처리가 가능하죠.

 

특이한 점은 Configmap 의 경우 Volume 을 사용해도 마운트가 되진 않습니다. (df -h 의 결과값이 없음)

 

그럼 오늘은 여기까지!