Fundamentals

Created

2024/04/11 07:24

1) About

보안이란 “누가 접근할 수 있는가”, 그리고 “무엇을 할 수 있는가”를 구성하는 것

→ 전자는 인증 (Authentication)

→ 후자는 인가 (Authorization)

ID/PW

ID/Token

인증서

LDAP

Service Account

등의 인증 방법이 있음

RBAC (Role Based Access Control)

ABAC (Attribute Based Access Control)

Node

Webhook Mode

등의 인가 방법이 있음

2) Authentication

사용자는 크게

•

Admin

•

Developer

•

Application End User

•

Bot

으로 나뉘는데, 엔드 유저의 경우 어플리케이션 로직에 의해서 관리되기 때문에 쿠버네티스 인증에서는 제하고 고려하면 됨

남은 사용자들은 크게

•

User - Admin / Developer

•

Service Account - Bot

으로 나뉘게 됨

쿠버네티스는 사용자 계정에 대한 구현체가 있는 것은 아니고, 껍데기인 인터페이스만 있음

따라서 LDAP이나 인증서 등의 외부 소스에 의존하여 관리하게 됨

즉, Admin, Developer에 대해선 쿠버네티스가 직접 관리할 수는 없음

하지만 Service Account의 경우 쿠버네티스가 관리할수 있음

따라서 Kube API를 이용하여 직접 Service Account를 생성할 수 있음

Static File

정적 파일은 크게 패스워드 파일과 토큰 파일로 나뉘는데, 이는 CSV와 같은 포맷으로 작성되어 있음

작성된 파일은 Kube API Server가 서비스로 기동될 때 —-basic-auth-file 옵션으로 기재하여, 특정 파일을 이용하여 인증하겠다는 것을 명시해야함

** 토큰이라면 —-token-auth-file을 이용

# user-detail.csv
password,user1,u0001,group1

# user-token-detail.csv
token,user1,u0001,group1
Plain Text
복사

위 형태로 작성된 파일을 운용하는 것인데, 그렇게 권장되지는 않음

TLS Certificates

대칭키의 역할과 비대칭키의 필요성

개인 정보와 민감함 정보 등이 패킷에 평문로 전송된다면, Sneaker가 평문을 그대로 확인할 수 있게 되고 해킹으로 이어짐

따라서 암호화가 필요하고, 무작위 문자로되어 있는 키를 이용하여 암호화를 진행하게 됨

암호화된 데이터를 보내면 해커는 데이터를 해석할 수 없지만 서버도 데이터를 해석할 수 없기에 복호화할 수 있도록 암호화에 사용한 키를 보내줘야 함 (암호화에 사용한 키는 대칭키이고, 이는 암호문에 적용하면 평문을 얻을 수 있음)

하지만 키를 평문으로 전송하게 되면 또 다시 해킹의 위험성에 노출 되기 때문에 키를 위한 키가 필요한 무한의 굴레에 빠지게 됨

이러한 문제를 극복하고자 비대칭키를 이용하여 대칭키를 암호화하여 전송하게 됨

비대칭 암호화는 개인키와 공용키로 나뉘게 되는데, 대칭키를 암호화할 때는 공용키를 이용하여 진행하고, 개인키를 이용하여 복호화하게 됨 (공용키는 공개적으로 노출되어도 상관 없고, 개인키는 노출되면 아무나 복호화를 할 수 있기 때문에 노출되어선 안 됨)

서버가 데이터를 복호화 해서 데이터를 볼 수 있어야하기 때문에, 서버의 개인키가 복호화하도록 하고 서버의 공개키를 이용하여 데이터를 암호화하여 전송 (공개키는 노출되어도 되므로 해커가 취득해도 무방하고, 이를 이용하여 복호화할 수는 없음)

인증서의 적법성

대칭키의 역할과 비대칭키의 필요성을 인지했는데, 이것들만 있으면 문제가 없을까?

만일 해커가 사설 서버를 운영하고 자신의 웹 사이트가 진짜인 것처럼 해서 사용자가 속게 되면? → 이 역시도 진짜 웹 사이트처럼 대칭키를 이용하고, 대칭키 전달을 위한 비대칭키도 운용한다면? 사용자는 해커가 운용하는 사이트에 자신의 정보를 넘기는 것이 되고, 이를 인지하지 못할 수 있음

이러한 이유 때문에 접속하려는 웹 사이트가 안전한지 확인할 수 있도록 인증서가 있는 것 → 서버에서 제공받은 공개키가 합법적인지 판별할 수 있도록

따라서 실제로 웹 사이트에서 제공받는 것은 공개키를 받는 것이 아니라, 공개키가 기록된 인증서를 받게 됨

인증서에는 서버 위치, 공개키, 누구에게 발급된 것인지 등의 정보가 기록되어 있는데, 문제는 아무나 이러한 인증서를 만들 수 있다는 것

그렇다면 아무나 만들 수 있는 이 인증서를 보고선 어떻게 진짜 인증서인지 알 수 있을까? 인증서에는 서명 값이 존재하고, 서명 값이 올바르다는 것을 확인해주는 기관이 존재

즉, 별도의 기관 (Certificate Authority)에 인증서를 등록하게 되면 서명 값을 부여해주고, 서명 값을 CA에서 확인 받아서 안전한 인증서인지 확인

서명 값을 받기 위해선 개인키를 이용하여 인증서 요청서 (Certificate Signing Request)를 만들어서 CA에 제출해야하고, 도메인과 상세 정보를 확인한 CA가 서명 값을 반환해줌

브라우저는 서명 값이 올바른지 CA에 확인한다고 했는데, 그렇다면 CA가 올바른 CA임을 어떻게 알까? 이는 서명 값에 있는데, 서명 값은 생성될 때 CA의 개인키로 만들어지고 브라우저에는 CA의 공개키가 있기 때문에 이를 이용할 수 있음

개인키 공개키의 특성을 이용하여 CA의 개인키로 서명 값을 암호화한 것을 요청하고, 공개적으로 노출된 CA의 공개키를 이용하여 복호화가 되는지 확인하면 서명 값이 올바른지 볼 수 있으므로 이 경우에 CA가 적법하다는 것을 알 수 있음

따라서 위조된 CA들을 걸러낼 수 있게 됨

비대칭키 - Private Key

openssl genrsa -out ${PRIVATE_KEY} 1024
Bash
복사

비대칭키 - Public Key

openssl rsa -in ${PRIVATE_KEY} -pubout > ${PUBLIC_KEY}
Bash
복사

인증서 생성 요청서 - CSR

openssl req -new -key ${PRIVATE_KEY} -out ${CERTIFICATE_SIGNING_REQUEST} -subj ${SUBJECT}
Bash
복사

요약

서버는 공개키와 개인키를 만들고, 개인키를 이용하여 CSR을 생성

생성된 CSR을 CA에 제출

CA에서는 CSR과 도메인 등의 정보를 확인 후, 서명하여 CSR을 반환

서명 값과 공개키를 인증서에 담아 사용자들에게 배포

서버에 접속하려는 사용자들은 (정확히는 브라우저는) CA의 공개키를 이용하여 인증서의 위조를 판별

위조되지 않은 인증서라면 서버의 공개키를 이용하여 통신에 사용할 대칭키를 암호화하여 서버로 전달

서버는 개인키를 이용하여 복호화하여, 사용자와 통신을 위해 사용할 대칭키를 얻음

사용자와 서버가 모두 통신에 사용할 대칭키가 있으므로 이를 통해 암호화된 데이터를 주고 받음

** 사용자는 오로지 통신에 사용할 대칭키만 만들게 되고, 이는 브라우저가 수행

** key라는 확장자나 이름에 key가 들어간다면 일반적으로 개인키이고, 그렇지 않으면 공개키 (key, -key.pem은 개인키 / crt, pem등은 공개키)

** 인증을 위한 기관, 관련 서버들과 모든 프로세스들은 일종의 인프라로 간주되고 PKI (Public Key Infrastructure)라고 불림

번외

클라이언트의 대칭키가 노출되어 해커가 이를 이용할 수도 있을텐데, 이를 TLS 통신을 하고 있는 서버 입장에서 어떻게 판별할 수 있을까?

주기적으로 서버는 클라이언트에게 인증서를 요구 (이는 서버에서 발급한 인증서를 말하는 것은 아님)

클라이언트는 대칭키를 이용하여 CSR을 만들고 이를 CA에 제출하여 인증서를 얻게 되고, 얻은 인증서를 서버에 보내게 됨

서버는 대칭키를 알고 있기 때문에 얻은 인증서를 확인해볼 수 있고, 이를 통해 적법한 클라이언트임을 확인

Kubernetes TLS

TLS 개념에는 공인된 서버임을 증명하는 서버 인증서와 적법한 사용자를 증명하려는 클라이언트 인증서로 나뉘었음

쿠버네티스에도 동일한 개념으로 내부 서버들간 통신에 여러 인증서들을 사용

서버 인증서

Kube API Server → apiserver.crt / apiserver.key

ETCD → etcdserver.crt / etcdserver.key

각 워커 노드의 Kubelet → kubelet.crt / kubelet.key

로 구성됨

클라이언트 인증서

Kube API Server에 접속하려는 클라이언트와 인증서는

Admin → admin.crt / admin.key

Kube Scheduler → scheduler.crt / scheduler.key

Kube Controller Manager → controller-manager.crt / controller-manager.key

Kube Proxy → kube-proxy.crt / kube-proxy.key

로 나뉨

** 이러한 인증서들은 Kube API Server로 요청을 보낼 때 —-key, —-cert, —-cacert 옵션을 채우면 사용자와 비밀번호를 대신하여 사용할 수 있음

ETCD에 접속하려는 클라이언트는 Kube API Server로 유일함

** 기존에 만들어둔 apiserver.crt / apiserver.key를 이용해도 되고, apiserver-etcd-client.crt / apiserver-etcd-client.key를 만들어도 됨

Kubelet에 접속하려는 클라이언트는 Kube API Server가 됨

** 기존에 만들어둔 apiserver.crt / apiserver.key를 이용해도 되고, apiserver-kubelet-client.crt / apiserver-kubelet-client.key를 만들어도 됨

Kubelet은 상호간 통신이 있을 수 있으므로 kubelet-client.crt / kubelet-client.key도 이용

인증서 생성

각각의 서버 및 클라이언트 인증서를 만들기 위해선 CA의 ca.crt / ca.key를 이용해야함

EASYRSA / OPENSSL / CFSSL 등의 커맨드 도구를 이용할 수 있음

CA 인증서 생성

TLS Certificates 개념에서 배운 것처럼 클라이언트가 서버의 적법성을 검증 / 서버가 클라이언트의 적법성을 검증 하기 위해 ca.crt 인증서가 각 클라이언트와 서버에 존재해야함

# ca.key
openssl genrsa -out ca.key 2048

# ca.csr
openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr

# ca.crt
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
Bash
복사

Admin 인증서 생성

그룹 지정이 필요하므로 subject에 /O로 system:masters 그룹 명시

# admin.key
openssl genrsa -out admin.key 2048

# admin.csr
openssl req -new -key admin.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr

# admin.crt
openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -out admin.crt
Bash
복사

Kube Scheduler 인증서 생성

Control Plane 구성 요소이므로 system 접두사를 함께 명시

# scheduler.key
openssl genrsa -out scheduler.key 2048

# scheduler.csr
openssl req -new -key scheduler.key -subj "/CN=system:kube-scheduler" -out scheduler.csr

# scheduler.crt
openssl x509 -req -in scheduler.csr -CA ca.crt -CAkey ca.key -out scheduler.crt
Bash
복사

Kube Controller Manager 인증서 생성

Control Plane 구성 요소이므로 system 접두사를 함께 명시

# controller-manager.key
openssl genrsa -out controller-manager.key 2048

# controller-manager.csr
openssl req -new -key controller-manager.key -subj "/CN=system:kube-controller-manager" -out controller-manager.csr

# controller-manager.crt
openssl x509 -req -in controller-manager.csr -CA ca.crt -CAkey ca.key -out controller-manager.crt
Bash
복사

Kube Proxy 인증서 생성

# kube-proxy.key
openssl genrsa -out kube-proxy.key 2048

# kube-proxy.csr
openssl req -new -key kube-proxy.key -subj "/CN=kube-proxy" -out kube-proxy.csr

# kube-proxy.crt
openssl x509 -req -in kube-proxy.csr -CA ca.crt -CAkey ca.key -out kube-proxy.crt
Bash
복사

ETCD 인증서 생성

ETCD는 쿠버네티스를 구성하기 위해 여러 서버에 걸쳐 클러스터 형태로 존재하기 때문에 피어 인증서도 필요 (피어는 일종의 클라이언트)

etcdserver.crt / etcdserver.key 뿐만 아니라 etcdpeer${X}.crt / etcdpeer${X}.key도 필요

이와 같은 서버 인증서와 피어 인증서는 ETCD 구동 시 사용하게 됨

—-key-file / —-cert-file → 서버 인증서 경로

—-peer-key-file / —-peer-cert-file → 피어 인증서 경로

—-peer-client-cert-auth → 피어 클라이언트의 인증 수행 여부 (true / false)

—-trusted-ca-file → 서버 인증서 적법성 확인을 위한 CA 인증서 경로

—-peer-trusted-ca-file → 피어 인증서 적법성 확인을 위한 CA 인증서 경로

# etcdserver.key
openssl genrsa -out etcdserver.key 2048

# etcdserver.csr
openssl req -new -key etcdserver.key -subj "/CN=etcd-server" -out etcdserver.csr

# etcdserver.crt
openssl x509 -req -in etcdserver.csr -CA ca.crt -CAkey ca.key -out etcdserver.crt
Bash
복사

# etcdpeer1.key
openssl genrsa -out etcdpeer1.key 2048

# etcdpeer1.csr
openssl req -new -key etcdpeer1.key -subj "/CN=etcd-peer" -out etcdpeer1.csr

# etcdpeer1.crt
openssl x509 -req -in etcdpeer1.csr -CA ca.crt -CAkey ca.key -out etcdpeer1.crt
Bash
복사

Kube API Server 인증서 생성

Kube API Server는 가장 소통이 활발한 대상이고, 쿠버네티스의 모든 요소들이 Kube API Server를 거쳐간다고 해도 과언이 아님

이름도 별칭도 가장 많고 (Kube API Server라고도 불리고, Kubernetes라고 불리기도 하기에 관련 별칭들이 다수 존재) 이러한 정보들이 모두 인증서에 있어야하기에, 별도의 설정 파일을 구성하여 CSR을 생성

** kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local 등이 별칭

--tls-cert-file / --tls-private-key-file → 서버 인증서 경로

--etcd-certfile / --etcd-keyfile → ETCD 클라이언트 인증서 경로

--kubelet-client-certificate / --kubelet-client-key → Kubelet 클라이언트 인증서 경로

--etcd-cafile → ETCD 인증서 적법성 확인을 위한 CA 인증서 경로

--kubelet-certificate-authority → Kubelet 인증서 적법성 확인을 위한 CA 인증서 경로

—-client-ca-file → 클라이언트 인증서 적법성 확인을 위한 CA 인증서 경로

# apiserver.key
openssl genrsa -out apiserver.key 2048

# apiserver.csr
openssl req -new -key apiserver.key -subj "/CN=kube-apiserver" -out apiserver.csr -config openssl.cnf

# apiserver.crt
openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -out apiserver.crt
Bash
복사

# openssl.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation,
subjectAltName = @alt_names
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.lcoal
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87
YAML
복사

Kubelet 인증서 생성

Kubelet 인증서는 각 노드마다 존재해야하며, 클러스터 형태로 구성되는 것이 아니다보니 중복되는 이름을 가지지 않도록 조정 필요

결국 Kubelet은 노드마다 단독으로 존재하기 때문에 노드 이름으로 구성하는 것과 크게 다르지 않으므로, 인증서에는 노드의 이름을 사용

Kubelet을 정의하는 YAML 내에서 각 노드 별로 아래 항목을 작성하여 생성해야함

authentication.x509.clientCAFile → 클라이언트 인증서 적법성 확인을 위한 CA 인증서 경로

tlsCertFile / tlsPrivateKeyFile → 서버 인증서 경로

Kubelet 인증서의 이름에는 노드임을 밝히는 system:node 접두사를 함께 명시해야하며, subject에 /O로 system:nodes 그룹 명시

# kubelet-client1.key
openssl genrsa -out kubelet-client1.key 2048

# kubelet-client1.csr
openssl req -new -key kubelet-client1.key -subj "/CN=system:node:node1/O=system:nodes" -out kubelet-client1.csr

# kubelet-client1.crt
openssl x509 -req -in kubelet-client1.csr -CA ca.crt -CAkey ca.key -out kubelet-client1.crt
Bash
복사

인증서 상태 확인

클러스터가 어떻게 셋업 되었는지 아는 것이 중요

직접 Control Plane의 요소를 Service 형태로 구성했는지

cat /etc/systemd/system/kube-apiserver.service
Bash
복사

kubeadm과 같은 자동 프로비저닝 툴을 이용했는지

cat /etc/kubernetes/manifests/kube-apiserver.yaml
Bash
복사

셋업된 각 경우의 경로를 열어서 인증서 경로를 확보

인증서 경로와 openssl x509를 이용하여 인증서 디코딩

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout
Bash
복사

만일 인증서 상태를 확인하는 도중 클러스터 셋업에 문제가 있는 것 같다면 로그를 확인해야함

→ 직접 셋업된 경우에는 운영체제에 있는 서비스 로그를 확인

journalctl -u etcd.service -l
Bash
복사

→ kubeadm을 이용한 경우에는 kubectl을 이용하여 자체 로그를 확인

kubectl logs etcd-master
Bash
복사

후자의 경우 Kube API Server 혹은 ETCD가 내려가면 API가 동작하지 않음에 따라 로그를 확인할 수 없을 수 있음

이러한 경우에는 Container 자체의 로그만 보면 되기 때문에 Docker를 활용해볼 수 있음

# container 확인
docker ps -a

# 로그 출력
docker logs ${CONTAINER_ID}
Bash
복사

Component	Type	Certificate Path	CN Name	ALT Names	Organization	Issuer	Expiration	File Type	Purpose	Description
Certificate Authority	Server	/etc/kubernetes/pki/ca.crt	kubernetes			kubernetes	May 9 11:21:40 2029 GMT	Certificate		CA server root certificates for Kubernetes API Server
		/etc/kubernetes/pki/ca.key						Key		CA server root certificate key for Kubernetes API Server
kube-apiserver	Server	/etc/kubernetes/pki/apiserver.crt	kube-apiserver	DNS:master DNS:kubernetes DNS:kubernetes.default DNS:kubernetes.default.svc DNS:kubernetes.default.svc.cluster.local IP Address:10.96.0.1 IP Address:172.17.0.27		kubernetes	Feb 11 05:39:20 2020 GMT	Certificate	Server Certificate	Certificate to serve Kube-api server
		/etc/kubernetes/pki/apiserver.key						Key	Server Key	Key to serve Kube-api server
		/etc/kubernetes/pki/ca.crt	kubernetes			kubernetes	Feb 8 05:39:19 2029 GMT	Certificate	Server CA Certificate	CA Certificate to validate clients connecting to Kube-API Server
	Client (Kubelet)	/etc/kubernetes/pki/apiserver-kubelet-client.crt	kube-apiserver-kubelet-client		system:masters		Feb 11 05:39:20 2020 GMT		Client Cert: Kube API Server to Kubelet	Client Certificate for Kube-API Server to connect to Kubelet
		/etc/kubernetes/pki/apiserver-kubelet-client.key						Key	Client Key: Kube API Server to Kubelet	Client Key for Kube-API Server to connect to Kubelet
	Client (Etcd)	/etc/kubernetes/pki/apiserver-etcd-client.crt	kube-apiserver-etcd-client		system:masters	kubernetes	Feb 11 05:39:22 2020 GMT	Certificate	Client Cert: Kube API Server to ETCD	Client Certificate for Kube-API Server to connect to ETCD Server
		/etc/kubernetes/pki/apiserver-etcd-client.key						Key	Client Key: Kube API Server to ETCD	Client Key for Kube-API Server to connect to ETCD Server
	Client (Etcd)	/etc/kubernetes/pki/etcd/ca.crt	kubernetes			kubernetes	Feb 8 05:39:21 2029 GMT	Certificate	Client CA File: Kube API Server to ETCD	CA File to validate Kube-API server to ETCD Server Connectivity. The ETCD setup can have a separate CA
kubelet	Server	/var/lib/kubelet/pki/kubelet.crt	node01@1557660157					Certificate
		/var/lib/kubelet/pki/kubelet.key						Key
	Client	/var/lib/kubelet/pki/kubelet-client-2019-05-12-11-22-38.pem	system:node:node01		system:nodes	kubernetes	May 11 11:18:00 2020 GMT	Certificate
								Key
Certificate Authority (ETCD)	Server	/etc/kubernetes/pki/etcd/ca.crt	kubernetes			kubernetes	May 9 11:21:42 2029 GMT	Certificate	Etcd Server CA Certificate	CA Server root certificates for ETCD Server. (This could be the same as kube-api server or a separate one of its own.)
		/etc/kubernetes/pki/etcd/ca.key						Key	Etcd Server CA Key	CA Server root certificate key for ETCD Server. (This could be the same as kube-api server or a separate one of its own.)
etcd-server	Server	/etc/kubernetes/pki/etcd/server.crt	controlplane				Nov 15 18:50:56 2021 GMT	Certificate	Etcd Server Certificate	Certificates for ETCD Server
		/etc/kubernetes/pki/etcd/server.key					Nov 15 18:50:56 2021 GMT	Key	Etcd Server Key	ETCD Server Certificate Key

Checks to perform

1. Make sure the correct CN and ALT names, Organization are present. Specifically for the kube-api server and the nodes(kubelets).

2. Ensure the certificates are not expired.

3. Ensure the certificates are issued by the right CA.

4. Ensure the correct certificate path is provided in the options on the service configuration files

Certificates API

CA 역할로 생성된 인증서와 키에 접근할 수 있는 사용자는 쿠버네티스에서 사용되는 인증서에 서명할 수 있음 → 새로운 사용자를 추가하는 등

따라서 이러한 인증서와 키는 안전한 환경에 위치해야함

인증서와 키가 위치한 안전한 환경을 곧 CA 서버라고 지칭

쿠버네티스에는 이러한 서명 요청들을 자동화하여 Certificates API를 이용할 수 있음

Certificates API를 이용하면 CertificateSigningRequest라는 객체를 만들 수 있음

해당 객체는 요청을 검토한 후에, 승인 절차를 거쳐 서명하게 됨

서명된 객체는 사용자들에게 공유되어 인증된 사용자임을 증명하는 수단으로 사용

조금 더 구체적으로는 아래와 같은데, 이와 관련된 책임을 수행하는 것은 Controller Manager가 담당

** Controller Manager에 --cluster-signing-cert-file / --cluster-signing-key-file 옵션에 기재하여 이용

사용자에 해당하는 키를 생성

openssl genrsa -out jane.key 2048
Bash
복사

사용자는 키를 이용하여 CSR을 생성

openssl req -new -key jane.key -subj "/CN=jane" -out jane.csr
Bash
복사

관리자는 사용자의 CSR을 이용하여 CertificateSigningRequest객체를 생성

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
	name: jane
spec:
	expirationSeconds : 600
	usage:
	- digital signature
	- key encipherment
	- server auth
	request: # CSR을 base64로 인코딩한 값을 이용
YAML
복사

cat jane.csr | base64
Bash
복사

관리자는 아래와 같이 CSR 객체를 확인 및 서명 가능

# 확인
kubectl get csr

# 서명
kubecetl certificate approve ${CSR_NAME}
Bash
복사

승인된 CSR의 결과로는 인증서로 나타나며, 이는 아래와 같은 명령어를 이용하여 status.certificate 항목에서 확인 가능 (base64 디코딩 필요)

kubectl get csr ${CSR_NAME} -o yaml
Bash
복사

echo ${CERTIFICATE} | base64 --decode
Bash
복사

디코딩된 인증서 값을 사용자에게 공유하여 이용할 수 있음