Kubernetes에서 Secret 암호화

Kubernetes에서는 Secret이라는 Ojbect가 있다.

 

시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트이다. 

 

만약 Secret을 사용하지 않으면 Pod 생성 시 이러한 중요한 정보가 Pod 명세에 포함되어 배포해야 한다. 그래서 Secret에 중요 정보를 저장하고 Secret Mount를 통한 연동을 Pod 명세에 포함한다.

 

아래와 같이 사용한다.

 

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
  labels:
    name: secret-test
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: ssh-key-secret
  containers:
  - name: ssh-test-container
    image: mySshImage
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

 

Secret에 저장되는 정보는 아래와 같다.

 

• Database ( Mysql 등) 인증 정보
• SCM ( Git, SVN 등 ) 인증 정보
• AWS/Azure 등의 Access key
• TLS 인증서 정보 
• Docker Registry 인증 정보

출처 : https://cloud.google.com/kubernetes-engine/docs/concepts/secret

 

실제 생성된 Secret을 한번 살펴보자.

 

kind: Secret
apiVersion: v1
metadata:
  name: mysecret
data:
  password: cGFzc3dvcmQ=
  username: aWQ=
type: kubernetes.io/basic-auth

 

위에서 username과 password는 base64 encoding으로 아래와 같이 decoding을 사용하여 볼 수 있다.

 

# echo -n 'cGFzc3dvcmQ=' | base64 -d
password

 

Secret 조회 권한이 있는 사용자는 Kubernetes에 생성된 Secret을 조회하여 ID, Password를 알 수 있기 때문에 이는 보안에 문제가 될 수 있다.  Kubernetes 매뉴엘에는 아래와 같은 경고 사항이 있다.

 

주의
쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. 또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.

시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.

1. 시크릿에 대한 암호화 활성화.
2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 RBAC 규칙 활성화 또는 구성.
3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.

 

* 여기서 RBAC 규칙을 통한 Secret Object를 조회를 통제하는 방식은 적절하게 보일 수 있으나 실제 데이터가 저장되는 곳인 ETCD 데이터를 직접 조회 시에는 중요 데이터가 누출 될 수 있는 위험성을 가지고 있다.

 

* 시스릿에 대한 암호화를 위한 Kubernetes에서 가이드하는 내용은 아래와 같다.

 

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Encrypting Secret Data at Rest

 

이 방식으로 Secret 데이터를 암호화 할 수 있으나, 이미 존재하는 Secret은 별도로 암호화를 진행해야 하고, 암호화를 위한 Key값을 변경 시 다시 암복호화를 진행해야 하는 불편함이 있다. 그리고 해당 Key가 기본적으로  Control Plane 서버에 있기 때문에 Key가 누출될 위험성을 가지고 있다. 그래서 이러한 Key 관리를 위한 외부 KMS Provider를 사용해야 할 수 있다.

 

https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/

Using a KMS provider for data encryption

 

Key 변경 또는 기존 Secret 정보를 암복호화 하는 과정에서 잘못된 설정으로 진행되는 경우 모든 데이터를 복구 할 수 없는 위험성을 가지고 있다.

 

Secret 암호화 설정은 반드시 ETCD 데이터를 주기적으로 백업한 후 설정하는 것을 권장한다.