Secret
ConfigMap 처럼 키 - 값 형태로 저장하는 저장소이다. 그렇지만 ConfigMap과는 사용하는 목적이 다른데, Secret은 소량의 민감한 데이터를 안전하게 저장하기 위한 목적으로 사용한다. 따라서 패스워드, 인증서, 키, 토큰과 같은 정보를 담는데 적합하며, 1MiB 까지 저장할 수 있다.
Secret 은 ConfigMap와 동일하게 특수한 볼륨의 한 형태라고 이해할 수 있으며, Pod에 볼륨으로 연결하여 사용할 수 있다.
또한 configMap은 Plain text로 저장되는 반면 secret은 base64 방식으로 인코딩되어 저장된다.
Base 64 방식 인코딩과 디코딩을 하는 명령어는 다음과 같다.
$ echo "minjee" | base64
bWluamVlCg==
$ echo "bWluamVlCg==" | base64 --decode
minjee
Secret Object의 종류
1. Generic : configMap과 같이 일반적인 데이터를 저장할 수 있는 타입이다.
2. Docker-registry : Docker registry 인증에 필요한 ID, PASSWORD와 같은 정보를 저장할 수 있다.
3. TLS : HTTPS 통신에 필요한 TLS key 파일이나 인증서 파일을 저장할 수 있다.
Secret Object를 생성하는 방법
1. 명령어로 생성하기
configmap 을 생성하는 방식과 비슷하지만 타입에 따라서 생성 방식이 다르다! 따라서 타입을 지정해주어야 한다.
$ kubectl create secret TYPE NAME [OPTIONS]
Generic Type
$ kubectl create secret generic --from-file=[=key]FILE_NAME
$ kubectl create secret generic --from-literal=[=key]FILE_NAME
명령어로 생성하는 경우 직접 base64로 인코딩 하지 않아도 자동으로 인코딩된다.
Docker-Registry
kubectl create secret docker-registry SECRET_NAME --docker-username=user \
--docker-password=password --docker-email=email \
[--docker-server=string]
마지막 줄의 --docker-server=string 부분은 현재 사용하고자 하는 Docker Registry 가 Docker Hub일 경우에 생략해도 된다
TLS
tls 인증서 파일과 key 파일을 묶어서 secret 오브젝트로 생성할 수 있다. 이 오브젝트는 https 프로토콜을 사용하는 경우에 Pod에 직접 연결해서 사용하거나, 또는 Ingress 서비스에 직접 연결해서 HTTPS Termination Proxy로 사용할 수 있다.
kubectl create secret tls SECRET_NAME --cert=인증서파일 --key=KEY파일
2. Manifest File로 생성하기
주의할 점은 Manifest File로 시크릿 오브젝트를 만들때는 직접 Base64 인코딩한 값을 넣어야 한다.
apiVersion: v1
kind: Secret
metadata:
name: SECRET_NAME
type: Opaque
data:
username: BASE64_ENCODING_VALUE
password: BASE64_ENCODING_VALUE
Secret 오브젝트 정보 확인하기
다른 오브젝트들과는 달리 kubectl describe 명령어를 써도 value 값이 보이지 않는다. key와 value값을 확인하고 싶다면 -o 옵션을 지정하여 설정파일을 볼 수 있다.
$ kubectl get secrets my-secret -o yaml
Secret Object 의 UseCase
1) Secret 파일을 사용하여 HTTPS 웹서비스를 제공할 수 있다. TLS 인증서와 키 파일을 Secret 오브젝트에 저장하고, TLS가 적용된 웹서버를 제공하는 Pod의 volume으로 연결하여 사용할 수 있다.
2) 위와 비슷한 경우로 HTTPS 웹서비스를 제공하는 경우에, TLS Termination Proxy를 구현할 수 있다.
1)의 경우에는 각각의 웹서버, 즉 Pod가 직접 TLS를 구성하고 있다. 그런데 이 웹서버가 여러개인 경우에는 각각의 web server 마다 인증서가 필요하고, 이 인증서를 갱신해주어야 하며, 클라이언트 측에서 접속할때 각각의 인증서가 필요하다는 문제가 발생한다.
따라서 이를 인그레스 컨트롤러를 사용하여 각각의 웹서버들 앞단에서 TLS Termination Proxy로 인증서를 처리해 줄 수 있다. 웹 클라이언트와 Proxy 사이에서만 TLS로 암호화하므로 내부 네트워크의 웹서버들은 암호화를 처리하지 않아도 되는 장점이 있다.
인증서에 대한 관리도 편하며, 웹서버의 부하가 줄게 된다는 장점이 있다.
'Cloud Engineering > Kubernetes ⚙️' 카테고리의 다른 글
[Kubernetes] CrushLoopBackOff 에러 해결법 (0) | 2023.02.24 |
---|---|
[Kubernetes] Deployment Object (디플로이먼트 오브젝트) 와 Rolling Update 전략 (0) | 2023.02.22 |
[Kubernetes] ConfigMap 오브젝트 생성하기 (0) | 2023.02.21 |
[Kubernetes] Persistent Volume 과 Persistent Volume Claim (0) | 2023.02.20 |
[Kubernetes] Ingress 컨트롤러 (0) | 2023.02.19 |