Udemy CKA 강의 정리 107: Demo: Encrypting Secret Data at Rest

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 유휴 상태의 secret 데이터를 암호화하는 방법을 살펴보겠습니다. 따라서 Kubernetes 공식문서 페이지로 이동하고 task 아래에 administrative cluster가 있고 encrypting secret data at rest 문서가 있습니다. 공식 문서를 따라가면서 우리가 하려는 것을 시도하고 설명할 것입니다. 

먼저 Kubernetes 플레이그라운드를 시작하겠습니다. 이것은 단일 노드 클러스터입니다. 이것은 default로 Qadium 도구로 구축되었으며 컨테이너 D가 있습니다. 

 

가장 먼저 해야 할 일은 먼저 secret 오브젝트를 생성하는 것입니다. 
kubectl create secret으로 일반적인 secret을 생성할 수 있습니다. 이렇게 생성할 것이고 아마도 리터럴에서 secret을 만들 것입니다. 

key1과 super secret으로 제 my-secret 오브젝트를 생성했습니다. 이제 get secret 을 수행하면 내 secret 오브젝트를 볼 수 있습니다. 그리고 describe secret을 수행하면 secret 이름과 데이터를 볼 수 있습니다. 

좀 더 보고 싶으면 get secret -o yaml 커맨드를 실행합니다. 그러면 여기에서 데이터를 볼 수 있습니다. 

key1이 보이고 이것은 secret의 인코딩된 형식입니다. 아시다시피 누구나 이것을 가지고 해독할 수 있고 실제 secret을 쉽게 볼 수 있다는 것을 기억하세요. 

따라서 secret definition 파일을 만들지 말고 GitHub 또는 다른 것으로 push하세요. 누구나 이 파일을 선택하고 이 커맨드를 실행하면 secret을 볼 수 있기 때문입니다. 이것이 첫 번째 단계입니다. 하지만 이 강의의 범위는 여기 이 인코딩과 실제로 관련이 없다는 것을 분명히 하고 싶습니다. 우리는 etcd 서버에 저장된 데이터에 초점을 맞출 것입니다. 그래서 이것은 우리가 끝난 후에도 이 부분은 여전히 동일하게 유지될 것입니다. 따라서 여기서는 이 부분에 집중하지 않습니다. 우리가 집중하고 있는 것은 데이터가 at etcd 서버에 저장되는 방식입니다.
먼저 이 데이터가 etcd 서버에 어떻게 저장되는지 살펴보겠습니다. 그래서 이를 위해 문서 하단으로 이동하면 API 버전 3이라는 etcd를 사용하는 커맨드가 있습니다. 

먼저 etcdctl 커맨드라인이 있는지 확인하겠습니다.

etcdctl 커맨드라인이 없다고 나옵니다. 따라서 설치해야 합니다.  

apt-get install etcd-client로 설치했습니다. etcd 서버가 팟(Pod)에서 실행 중임을 기억하세요. 따라서 exec 또는 pod를 찾은 다음 그 안에서 etcdctl 커맨드를 실행할 수 있습니다. 또는 컨트롤 플레인 노드에서 로컬로 실행하려는 경우, etcdctl 클라이언트를 사용할 수 있습니다.  

이제 etcdctl 유틸리티가 있습니다. 서버는 여전히 파드로 실행 중인 클라이언트만 해당된다는 점을 기억하십시오. kubectl get pods -n kube-system을 수행하면 여기에 etcd-controlplane이 있습니다.

다음 단계는 아래 커맨드를 실행하는 것입니다.

ETCDCTL_API=3 etcdctl \
   --cacert=/etc/kubernetes/pki/etcd/ca.crt   \
   --cert=/etc/kubernetes/pki/etcd/server.crt \
   --key=/etc/kubernetes/pki/etcd/server.key  \
   get /registry/secrets/default/secret1 | hexdump -C

먼저 인증서 파일이 필요합니다. 우리가 그것을 가지고 있는지 봅시다.

etcd 아래에 etcd 서버에 연결하거나 인증하는 데 필요한 모든 인증서 파일이 있습니다. 

공식문서의 커맨드를 복사하여 secret의 이름을 my secret으로 바꿉니다. 이제 이 커맨드를 실행하면 뒤죽박죽 정보가 제공되지만, secret을 찾을 수 있습니다.

텍스트 형식으로도 secret을 볼 수 있습니다. 이 형식으로 보려면 hexdump -C를 추가하기만 하면 됩니다. 

이것이 etcd에 저장된 데이터입니다. 자세히 보면 내가 가진 secret, 암호 또는 내가 저장한 것이 무엇이든 실제로 이렇게 보입니다. 데이터는 암호화되지 않은 형식으로 etcd에 저장됩니다. 따라서 etcd에 액세스할 수 있는 사람은 누구나 모든 secret과 secret 오브젝트로 저장된 기타 기밀 정보를 얻을 수 있습니다. 
이것이 우리가 etcd에서 미사용 암호화를 활성화하여 해결하려는 문제입니다. 

이제 이 문서를 살펴보면 먼저 암호화 주소가 이미 활성화되어 있는지 여부를 결정해야 합니다. 따라서 이것은 encryption provider config라는 속성으로 수행됩니다. kube API 서버로 이동하여 여기에서 kube API 서버가 프로세스로 실행 중이라고 가정하고, kube API 서버를 가져오면 모든 옵션을 사용하여 실행 중인 kube API 서버 프로세스를 볼 수 있습니다. 

먼저 --encryption-provider-config 옵션이 있는지 살펴보겠습니다. 미사용 암호화가 이미 활성화되어 있는지 확인하기 위한 것입니다. 

커맨드 결과를 반환하지 않습니다. 따라서 --encryption-provider-config 옵션이 구성되지 않았음을 의미합니다. 
/etc/kubernetes/manifest/ 아래 파일을 확인합니다.

여기에 kube-apiserver.yaml이 있습니다. 이 파일을 cat으로 살펴보면 제공된 모든 옵션을 볼 수 있습니다. 

여기에 --encryption-provider-config 옵션이 보이지 않습니다. 따라서 이는 미사용 암호화가 활성화되지 않았음을 의미합니다. 이것이 첫 번째 단계이고 secret 오브젝트를 생성하여 이미 확인했습니다. 
따라서 다음 단계는 config 파일을 만든 다음  --encryption-provider-config 옵션으로 전달하는 것입니다. config 파일을 만들고 옵션으로 전달하는 것이 기본적으로 암호화를 활성화하는 데 필요한 단계입니다. 

그럼 config 파일을 살펴보겠습니다. API 버전이 있고 이 암호화 config이 있고 리소스가 있습니다. 암호화할 리소스를 선택하고 선택할 수 있습니다. 파드와 deployment, secret 및 서비스가 있습니다. 모든 정보가 기밀이 아닐 수 있습니다.  따라서 Pod 및 Deployment에 대한 모든 데이터를 반드시 암호화하고 저장할 필요는 없습니다. 여기서 우리의 관심사는 단지 secret일 뿐입니다. 따라서 리소스에서 대상을 지정합니다. 그래서 이것은 secret 오브젝트만 암호화된다는 것을 의미하는 secret입니다. 이제 일련의 provider를 사용하여 무언가를 암호화할 수 있습니다. 

문서를 더 아래로 내리면  provider 리스트를 볼 수 있으며, identity provider 가 Encryption이 없다고 나옵니다. 이 경우엔 리소스가 암호화 없이 있는 그대로 작성됩니다.

위와 같은 여러 provider 가 있습니다. secret box가 있고,  AES, DCM, AES CBC, CBC가 있습니다. 이것들은 모두 다른 암호화 알고리즘입니다. 위에서 암호화 방법에 대한 세부 정보를 볼 수 있습니다. 따라서 원하는 것을 선택하고 키를 제공할 수 있습니다. key는 secret을 가지고 있습니다. 여러 키와 암호를 제공할 수 있습니다. 그리고 이 secret은 암호화 알고리즘에 의한 암호화에 사용될 것입니다. 

이제 여기서 주목해야 할 것은 순서입니다. 보시다시피 이것은 리스트를 제공합니다. 이 순서가 중요한 이유는 암호화가 발생할 때 처음에 이것을 사용하여 암호화한 다음 이들 중 하나를 사용하여 해독할 수 있기 때문입니다. 따라서 항상 암호화는 이것으로 발생합니다. 
따라서 암호화가 없는 identity provider가 첫 번째 공급자이면 암호화가 전혀 활성화되지 않습니다. 
따라서 etcd의 데이터를 정말로 암호화하려면 이 중 하나가 맨 위에 있어야 합니다. 따라서 첫 번째는 무엇이든 암호화에 사용될 것입니다.

우리는 이 파일의 아주 간단한 버전을 만들 것입니다.  보시다시피 모든 secret이 암호화되도록 지정했습니다. 그리고 우리는 AES CBC 암호화 공급자를 사용할 것입니다. 첫 번째는 AES CBC입니다. 이것이 암호화에 사용될 것입니다. 이제 여기에는 secret 오브젝트가 필요합니다. 

head -c 32 /dev/urandom | base64

이것을 사용하여 임의의 32(?) key를 생성할 수 있습니다.

key를 복사하고 encryption config file로 이동하여 secret 오브젝트를 교체합니다.

kube-apiserver에서 방금 만든 암호화 파일을 가리키도록 이 줄을 추가하겠습니다. 그러면 당연히 파일이 필요합니다.

(보충 필요)