이미 저장소에서 암호화된 기밀 데이터 복호화하기

이미 저장소에서 암호화된 기밀 데이터 복호화하기 (Decrypt Confidential Data that is Already Encrypted at Rest)

저장소(at rest) 암호화를 지원하는 쿠버네티스 API는 모두 영구 API 리소스 데이터 쓰기를 지원해요. 예를 들어 Secrets에 대한 저장소 암호화를 활성화할 수 있어요. 이 저장소 암호화는 etcd 클러스터 또는 kube-apiserver를 실행하는 호스트의 파일시스템에 대한 시스템 레벨 암호화에 추가로 적용되는 것이에요.

이 페이지는 API 데이터가 암호화되지 않은 채 저장되도록 저장소의 API 데이터 암호화에서 전환하는 방법을 보여드려요. 성능을 개선하기 위해 이렇게 하고 싶을 수도 있어요. 하지만 일반적으로 어떤 데이터를 암호화하는 것이 좋은 생각이었다면 암호화된 채로 두는 것도 좋은 생각이에요.

참고: 이 작업은 쿠버네티스 API를 사용해 저장된 리소스 데이터에 대한 암호화를 다뤄요. 예를 들어 포함된 키-값 데이터를 포함해 Secret 객체를 암호화할 수 있어요. 컨테이너에 마운트된 파일시스템의 데이터에 대한 암호화를 관리하려면 다음 중 하나를 해야 해요.

암호화된 볼륨을 제공하는 스토리지 통합을 사용하거나

자신의 애플리케이션 내에서 데이터를 암호화하기.

출처: 문서

본문

시작하기 전에 (Before you begin)

쿠버네티스 클러스터가 필요하고, kubectl 명령줄 도구가 클러스터와 통신하도록 구성돼 있어야 해요. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 두 개 이상 있는 클러스터에서 실행하는 것을 권장해요. 아직 클러스터가 없다면 minikube로 만들거나 다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있어요.

iximiuz Labs
Killercoda
KodeKloud
이 작업은 각 컨트롤 플레인 노드에서 쿠버네티스 API 서버를 static pod로 실행하고 있다고 가정해요.
클러스터의 컨트롤 플레인은 etcd v3.x(메이저 버전 3, 어떤 마이너 버전이든)를 사용해야 해요.
커스텀 리소스를 암호화하려면 클러스터가 쿠버네티스 v1.26 이상을 실행해야 해요.
이미 암호화된 API 데이터가 있어야 해요.
버전을 확인하려면 kubectl version을 입력하세요.

저장소 암호화가 이미 활성화되어 있는지 확인하기 (Determine whether encryption at rest is already enabled)

기본적으로 API 서버는 리소스의 일반 텍스트 표현을 저장하는 identity 제공자를 사용해요. 기본 identity 제공자는 어떤 기밀성 보호도 제공하지 않아요.

kube-apiserver 프로세스는 구성 파일의 경로를 지정하는 --encryption-provider-config 인자를 받아들여요. 지정한다면 그 파일의 내용이 쿠버네티스 API 데이터가 etcd에서 어떻게 암호화되는지 제어해요. 지정하지 않으면 저장소 암호화가 활성화되지 않은 거예요.

그 구성 파일의 형식은 YAML이며, EncryptionConfiguration이라는 구성 API 종류를 나타내요. 암호화 구성의 예시는 "Encryption at rest configuration"에서 볼 수 있어요.

--encryption-provider-config가 설정되었다면, 어떤 리소스(예: secrets)가 암호화용으로 구성됐는지, 어떤 제공자가 사용되는지 확인하세요. 해당 리소스 유형에 대한 선호 제공자가 identity가 아닌지 확인하세요. 저장소 암호화를 비활성화하려는 경우에만 identity(암호화 없음)를 기본값으로 설정하세요. 리소스에 대한 첫 번째 나열 제공자가 identity가 아닌지 확인하세요. 이는 해당 유형의 리소스에 기록된 새 정보가 구성된 대로 암호화됨을 의미해요. 어떤 리소스에 대해 첫 번째 나열 제공자로 identity를 본다면, 해당 리소스가 암호화 없이 etcd에 기록되고 있음을 의미해요.

모든 데이터 복호화하기 (Decrypt all data)

이 예시는 Secret API의 저장소 암호화를 중지하는 방법을 보여드려요. 다른 API 종류를 암호화하고 있다면 단계를 그에 맞게 조정하세요.

암호화 구성 파일 찾기 (Locate the encryption configuration file)

먼저 API 서버 구성 파일을 찾아요. 각 컨트롤 플레인 노드에서 kube-apiserver의 static Pod 매니페스트는 --encryption-provider-config라는 명령줄 인자를 지정해요. 이 파일이 hostPath 볼륨 마운트를 사용해 static Pod에 마운트된 것을 발견할 가능성이 높아요. 볼륨을 찾으면 노드 파일시스템에서 파일을 찾아 검사할 수 있어요.

객체를 복호화하도록 API 서버 구성하기 (Configure the API server to decrypt objects)

저장소 암호화를 비활성화하려면 암호화 구성 파일의 첫 번째 항목으로 identity 제공자를 배치하세요.

예를 들어 기존 EncryptionConfiguration 파일이 다음과 같다면,

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            # Do not use this (invalid) example key for encryption
            - name: example
              secret: 2KfZgdiq2K0g2YrYpyDYs9mF2LPZhQ==

이렇게 변경하세요.

---
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - identity: {} # add this line
      - aescbc:
          keys:
            - name: example
              secret: 2KfZgdiq2K0g2YrYpyDYs9mF2LPZhQ==

그리고 이 노드의 kube-apiserver Pod를 재시작해요.

다른 컨트롤 플레인 호스트 재구성하기 (Reconfigure other control plane hosts)

클러스터에 API 서버가 여러 개라면 각 API 서버에 변경 사항을 차례로 배포해야 해요. 각 컨트롤 플레인 호스트에서 같은 암호화 구성을 사용하는지 확인하세요.

복호화 강제하기 (Force decryption)

그런 다음 다음 명령을 실행해 모든 Secrets의 복호화를 강제해요.

# If you are decrypting a different kind of object, change "secrets" to match.
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

기존 암호화된 리소스를 모두 암호화를 사용하지 않는 백킹 데이터로 교체했다면 kube-apiserver에서 암호화 설정을 제거할 수 있어요.

제거할 명령줄 옵션은 다음과 같아요.

--encryption-provider-config
--encryption-provider-config-automatic-reload

새 구성을 적용하려면 kube-apiserver Pod를 다시 재시작해요.

다른 컨트롤 플레인 호스트 재구성하기 (Reconfigure other control plane hosts)

클러스터에 API 서버가 여러 개라면 다시 각 API 서버에 변경 사항을 차례로 배포해야 해요. 각 컨트롤 플레인 호스트에서 같은 암호화 구성을 사용하는지 확인하세요.

다음 단계 (What's next)

EncryptionConfiguration 구성 API (v1)에 대해 더 알아보기.

더 알아보기 (Learn more)

저장소에서 데이터 암호화