Google Kubernetes Engine: Secret

1. Secrets의 용도:

Secret 은 ConfigMap 과 유사하다.

 

차이점은 Secret 은 민감한 정보를 다룰 때 (e.g 패스워드, SSH Key 등) 사용한다는 점이다.

 

Secret 은 Control Plane 에서 관리되어서 역할 기반 접근 제어(Role-Based Access Control, RBAC) 를 통해서 접근을 제어할 수 있다.

 

Secret 은 쿠버네티스 시스템 로그 (= 어플리케이션 컨테이너의 로그와는 다르다.) 에도 출력되지 않는다고 한다.

 

2. Secrets의 한계:

High Value 자산을 가진 키나 데이터라면 Kubernetes 의 Secret 으로 관리하지 말고 Google Cloud KMS 를 통해서 관리하는 것을 추천한다고 함. 

• Google Cloud KMS 의 보안 수준이 더 높기 때문에 권장하는 것 같다.
• K8s 의 Secret 은 Base64 인코딩 정도로만해서 저장하는 반면에 Google Cloud KMS 는 키를 암호화해서 저장하니까. 

 

3. Secrets의 유형:

Secret 의 다음과 같이 3가지 유형이 있다:

• Generic Type
• TLS Type
• Docker Registry Secret Type

 

Generic Type:

• 일반적인 목적으로 사용할 수 있는 Secret 이며 Key-Value 로 저장된다.
• ConfigMap 과 같이 File, Directory, Literal Value 를 통해서 생성할 수 있는 Secret 이다.

 

TLS Type:

• Public, Privte Encryption Key Pair 를 저장할 때 사용하는 Secret 이다.
• PEM format 으로 인코딩 된 Public Key certificate 와 Private Key certificate 를 명싱해야한다.

 

Docker Registry Secret Type:

• Private Docker Registry 에서 Image 를 가지고 올 때 인증 Credential 을 저장하려고 사용하는 Secret 이다.
• GKE 에서 Google Container Registry 를 통해서 Container Image 를 관리하고 있다면, GKE 에서 사용하는 동일한 인증 매커니즘을 사용할테니 이 Secret 은 필요하지 않을 수 있다.

 

4. Secrets의 생성 및 저장:

Generic Type 의 Secret 생성 방법:

• 생성 방법은 ConfigMap 과 유사하다.
• Secret 으로 등록할 값은 Base64 로 인코딩해서 넣어줘야한다.
• Secret 으로 만들어진 값은 GCP Console 이나 kubectl get 또는 describe 명령을 내려도 출력되지 않는다.

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=         # base64 인코딩된 값 "admin"
  password: MWYyZDFlMmU2N2Rm  # base64 인코딩된 값

 

 

5. Secrets의 사용:

Secret 또한 ConfigMap 과 같이 Contaienr 의 Environment 로 사용될 수 있다:

• Secret 을 등록할 때 Encoding 해서 넣었었다. 여기서 환경변수로 넣을 때는 자동으로 쿠버네티스가 Decoding 해서 넣어준다.
  

  

 

 

Secret 은 Volume 으로도 사용할 수 있다:

• Volume 으로 사용할 때 ConfigMap 과 같이 Kubelet 이 주기적으로 Secret 이 업데이트 되었는지 확인하고, 업데이트 되었다면 이를 Volume 에 반영하도록 한다.
  

  

 

 

Secret 을 Volume 으로 사용할 때 이를 일부만 가져올 수도 있다.

• item 필드를 이용해서 전체 Secret 을 가지고 오지 않고 해당 키만 가지고온다.