[CKAD] section 3. Configuration (2) - Secret & Security Contexts

kubernets

 

이번엔 ConfigMap 으로 민감정보(패스워드 같은) 만을 따로 저장하도록 만들어보자

 

그 전에 쿠버네티스에서는 종종 kubectl get rs 나 kubectl get cm 같은 축약어의 형태가 있다는 것을 최근에 눈치 챘다.

해당 링크를 통해 각 리소스 타입별로 축약어를 확인할 수 있었다.

 

대표적으로 kubectl get pods 는 kubectl get po 로 사용할 수 있긴한데,, 2글자라 큰 차이는 없는 것 같다.

 

그럼 Secret Key 를 저장하는 방법에 대해 알아보자

 

Secret

Secret 은 기본적으로 민감 정보를 다루고 있기 때문에, 값을 그대로 노출하면 안된다.

값을 노출하면 ConfigMap 을 사용하는 것과 다를 바가 없다.

그래서, 1. 한번 암호화 한 후, 2. Pod 에 넣을 땐 복호화된 값을 집어넣어야 하겠다.

 

앞으로 명령식 사용 방법에 대해서 Imperative, 매니페스트 파일 사용은 declarative 로 표현하도록 하겠다.

 

1. Imperative

 

# 예시1
$ kubectl create secret generic \
	<secret-name> --from-literal=<key>=<value>

# 실제 사용1
$ kubectl create secret generic \
	app-secret --from-literal=DB_HOST=mysql \
    		   --from-literal=DB_User=root \
    		   --from-literal=DB_Password=paswrd
               

# 예시2
$ kubectl create secret generic \
	<secret-name> --from-file=<path-to-file>
    
# 실제 사용2
$ kubectl create secret generic \
	app-secret --from-file=app_secret.properties

 

참고로 Imperative 로 생성한 경우 자동으로 base64 로 encoding 이 되는 걸 확인할 수 있었다.

 

2. Declarative

 

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
data:
  # 해당 값들은 echo "mysql" | base64 로 encode 되었다.
  DB_Host: bXlzcWwK
  DB_User: cm9vdAo=
  DB_Password: cGFzd3JkCg==
  
---
$ kubectl create -f secret-data.yaml

# 이후 확인
$ kubectl get secrets
$ kubectl describe secrets
$ kubectl get secret app-secret -o yaml

 

키 값에 대한 암호화를 자동으로 해주는 줄 알았는데 그건 아니었다~

base64 로 인코딩을 해야된다.

 

이후 매니페스트 파일에

 

spec:
  containers:
  ...
  envFrom:
    - secretRef:
        name: app-secret

 

이렇게 사용하면 된다.

실무에선 envFrom, secretRef 등 사용방법이 생각나지 않으면

$ kubectl explain pods --recursive | less

명령어로 확인할 수 있다고 하니 참고.. (아니면 검색)

 

이전 글에서 volume 으로 마운트 하게 되면

파일로 생성이 된다고 한다.

 

쿠버네티스의 Secret 은 base64 로만 encode 된다고 한다고 하는데 별로 안전한 방법은 아닌 것 같다.

위의 패스워드를 echo -n "cGFzd3JkCg==" | base64 --decode 하면 복호화가 되니까 말이다.

 

그래서 강좌에선 etcd 를 사용해서 저장하거나 다른 방법들로 저장하여 활용하는 방법에 대해서도 제안하고 있다.

나중에 좀 더 참고해보기로 하자..

 

참고로 요즘 자주 쓰는 명령어 인데, pod 가 삭제완료 될 때 까지 기다리는 명령어다.

 

kubectl wait --for=delete <pod-resource>

 

Security 에 대한 내용이 저번 ConfigMap 과 크게 차이 나지 않아 Security Contexts 의 내용을 추가해본다.

 

Security Contexts 

도커 얘기를 잠깐 해보면, 도커 컨테이너를 생성하여 실행하게 됐을 때 기본적으로 root 유저로 실행이 된다.

 

FROM ubuntu

# root 가 싫다면 USER 를 만들어서 사용할 수 있다.
USER 1000

 

 

그리고 --cap-add 나 --cap-drop 을 사용하여 기능 추가나 삭제를 할 수 있고,

$ docker run --cap-add MAC_ADMIN ubuntu
$ docker run --cap-drop KILL ubuntu

 

시스템 자원의 접근을 막기 위해 Unprivileged 모드로 실행이 되기 때문에 --privileged 로 접근 가능하게 설정할 수도 있다.

$ docker run --privileged ubuntu

 

하지만 이 모든 것들이 쿠버네티스에서는 매우 쉽게 설정할 수 있다. (역시 도커 말고 쿠베를 쓰는 이유....)

 

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep", "3600"]
    # 추가된 설정
    securityContext:
      runAsUser: 1000
      capabilities:
        add: ["MAC_ADMIN"]
        drop: ["KILL"]

 

Security Context 는 생각보다 많은 내용이 있지 않았다.

 

쿠베 강좌를 보면서 도커의 내용도 같이 학습을 할 수 있는게 좋았고

Secret 은 실무에서 그대로 사용하기는 좀 어려울 것 같고, 반면 Security Context 는 보안 및 운영 측면에서 실무에서도 제법 사용할 수 있을 것 같다.