AWS EKS - Security - Sealed Secrets 을 사용하여 Secrets 보호

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 6주차
# EKS Workshop 참고

Sealed Secrets 프로젝트는 AWS 서비스가 아닌 Bitnami Labs의 타사 오픈 소스 도구입니다.

 

 

• Sealed Secrets는 Kubernetes 클러스터에서 비밀을 안전하게 저장하고 관리하기 위한 도구입니다.
• Sealed Secrets는 암호화된 형태로 Kubernetes Secrets를 저장하며, 이를 클러스터에 안전하게 배포할 수 있도록 해줍니다. 이를 통해 보안적인 측면을 강화하고, 비밀 데이터를 안전하게 전송하고 저장할 수 있습니다.
  1. Seal Key Pair 생성: Sealed Secrets는 클러스터에 설치된 컨트롤 플레인에 의해 사용되는 공개 및 개인 키 쌍을 생성합니다. 이 키 쌍은 암호화 및 복호화 작업에 사용됩니다.
  2. 비밀 생성 및 암호화: 클러스터 관리자는 kubectl을 사용하여 비밀을 생성하고, 이를 Sealed Secrets 컨트롤러에 전달합니다. Sealed Secrets 컨트롤러는 비밀을 받아서 이를 공개 키로 암호화한 후, 클러스터에 배포될 수 있도록 인코딩합니다.
  3. 암호화된 비밀 배포: 암호화된 비밀은 Kubernetes 클러스터에 배포됩니다. 이때, 클러스터에는 Sealed Secrets 컨트롤러가 설치되어 있어야 합니다. Sealed Secrets 컨트롤러는 암호화된 비밀을 받아서 복호화하기 위해 개인 키를 사용합니다.
  4. 복호화: 클러스터 내에서 Pod가 비밀을 사용할 때, 해당 비밀은 Sealed Secrets 컨트롤러에 의해 자동으로 복호화됩니다. 이는 원본 비밀을 사용하는 것과 같은 방식으로 Pod가 비밀을 이용할 수 있도록 합니다.
• Sealed Secrets의 장점
  • 안전한 저장 및 전송: 비밀 데이터는 암호화되어 저장되며, 전송 중에도 안전한 상태로 유지됩니다.
  • 원본 보존: 암호화된 비밀은 Kubernetes Secrets와 동일한 구조를 유지하므로, 기존의 Kubernetes 리소스 및 도구와 호환됩니다.
  • 클러스터 외부에서 생성 가능: 비밀을 생성하고 암호화하는 작업은 클러스터 외부에서 수행할 수 있으므로, 보안적인 측면에서 유리합니다.

---

✅ 실습준비

• Workshop 실습 환경 준비

• 봉인된 시크릿은 시크릿 오브젝트를 암호화하여 공용 리포지토리에도 안전하게 저장할 수 있도록 하는 메커니즘을 제공합니다. 봉인된 시크릿은 쿠버네티스 클러스터에서 실행 중인 컨트롤러만 해독할 수 있으며, 다른 누구도 봉인된 시크릿에서 원본 시크릿을 얻을 수 없습니다.
• 실습에서는 SealedSecrets를 사용하여 쿠버네티스 시크릿과 관련된 YAML 매니페스트를 암호화하고 이러한 암호화된 시크릿을 kubectl과 같은 도구를 사용한 일반적인 워크플로우를 사용하여 EKS 클러스터에 배포할 수 있습니다.

---

✅ Sealed Secrets for Kubernetes

• Sealed Secrets 은 두 부분으로 구성됩니다:
  
  • 클러스터 측 컨트롤러
  • kubeseal이라는 클라이언트 측 CLI
• 컨트롤러가 시작되면 클러스터 전체의 개인/공개 키 쌍을 찾고, 찾을 수 없는 경우 새로운 4096비트 RSA 키 쌍을 생성합니다. 개인 키는 컨트롤러와 동일한 네임스페이스(기본값은 큐브 시스템)에 있는 시크릿 오브젝트에 유지됩니다. 이 공개 키 부분은 이 클러스터에서 SealedSecrets를 사용하려는 모든 사람이 공개적으로 사용할 수 있습니다.
• 암호화하는 동안 원본 시크릿의 각 값은 무작위로 생성된 세션 키와 함께 AES-256을 사용하여 대칭적으로 암호화됩니다. 그런 다음 세션 키는 SHA256을 사용하여 컨트롤러의 공개 키와 원본 시크릿의 네임스페이스/이름을 입력 매개변수로 사용하여 비대칭으로 암호화됩니다. 암호화 프로세스의 출력은 다음과 같이 구성된 문자열입니다: 암호화된 세션 키의 길이(2바이트) + 암호화된 세션 키 + 암호화된 시크릿.
• SealedSecret 사용자 정의 리소스가 쿠버네티스 클러스터에 배포되면 컨트롤러가 이를 선택하고 개인 키를 사용하여 봉인을 해제하고 시크릿 리소스를 생성합니다. 암호 해독 중에 SealedSecret의 네임스페이스/이름이 입력 파라미터로 다시 사용됩니다. 이렇게 하면 SealedSecret과 Secret이 동일한 네임스페이스와 이름에 엄격하게 연결됩니다.
• 컴패니언 CLI 도구인 kubeseal은 공개 키를 사용하여 시크릿 리소스 정의에서 SealedSecret 사용자 정의 리소스 정의(CRD)를 생성하는 데 사용된다. kubeseal은 쿠버네티스 API 서버를 통해 컨트롤러와 통신하고 런타임 시크릿을 암호화하는 데 필요한 공개 키를 검색할 수 있다. 공개 키는 컨트롤러에서 다운로드하여 로컬에 저장하여 오프라인에서 사용할 수도 있습니다.
• SealedSecrets는 다음 세 가지 범위를 가질 수 있습니다:
  • strict (default) : 비밀은 정확히 동일한 이름과 네임스페이스로 봉인해야 합니다. 이러한 속성은 암호화된 데이터의 일부가 되므로 이름 및/또는 네임스페이스를 변경하면 '복호화 오류'가 발생할 수 있습니다.
  • namespace-wide : 봉인된 비밀은 주어진 네임스페이스 내에서 자유롭게 이름을 변경할 수 있습니다.
  • cluster-wide : 모든 네임스페이스에서 비밀을 봉인 해제할 수 있으며 어떤 이름으로든 지정할 수 있습니다.

---

✅ Installing Sealed Secrets

• kubeseal CLI는 Sealed Secrets 컨트롤러와 상호 작용하는 데 사용되며 이미 Cloud9에 설치되어 있습니다.
• EKS 클러스터에 Sealed Secrets 컨트롤러를 설치하는 것입니다:

• 파드의 상태를 확인

• Sealed Secrets  컨트롤러의 로그는 컨트롤러가 시작하는 동안 기존 개인 키를 찾으려고 시도하는 것을 보여줍니다. 개인 키를 찾지 못하면 인증서 세부 정보로 새 비밀을 만듭니다.

• 봉인 키가 포함된 시크릿의 내용을 다음과 같이 공개/개인 키 쌍으로 YAML 형식으로 볼 수 있습니다:

---

✅ Sealing your Secrets

• 카탈로그 네임스페이스의 카탈로그 배포는 환경 변수를 통해 카탈로그-db 시크릿에서 다음 데이터베이스 값에 액세스합니다:
  • DB_USER
  • DB_PASSWORD

 

• 카탈로그-db 시크릿을 살펴보면 다음과 같이 쉽게 디코딩할 수 있는 base64로만 인코딩되어 있습니다.
• ~/environment/eks-workshop/base-application/catalog/secrets.yaml

• 새로운 비밀 카탈로그-sealed-db를 만들어 보겠습니다. 카탈로그-db 시크릿과 동일한 키와 값을 사용하여 new-catalog-db.yaml 파일을 새로 만들겠습니다.
• ~/environment/eks-workshop/modules/security/sealed-secrets/new-catalog-db.yaml

• kubeseal로 SealedSecret YAML 매니페스트를 생성해 보겠습니다.

• 컨트롤러에서 공개 키를 가져와 오프라인으로 사용하여 비밀을 봉인할 수 있습니다.

• 다음 내용이 포함된 봉인된 비밀을 생성합니다:
• /tmp/sealed-catalog-db.yaml

• SealedSecret을 EKS 클러스터에 배포합니다.

 

• 컨트롤러 로그에 따르면 방금 배포된 SealedSecret 커스텀 리소스를 가져와 봉인을 해제하고 일반 시크릿을 생성하는 것으로 나타났습니다.

 

• SealedSecret에서 봉인 해제된 카탈로그-sealed-db 시크릿이 컨트롤러에 의해 보안-시크릿 네임스페이스에 배포되었는지 확인합니다.

• ~/environment/eks-workshop/modules/security/sealed-secrets/deployment.yaml

• SealedSecret 리소스인 카탈로그-sealed-db는 클러스터에 배포된 데몬셋, 디플로이먼트, 컨피그맵 등과 같은 다른 쿠버네티스 리소스와 관련된 YAML 매니페스트와 함께 Git 리포지토리에 안전하게 저장할 수 있습니다.
• 그런 다음 GitOps 워크플로우를 사용하여 이러한 리소스를 클러스터에 배포하는 것을 관리할 수 있습니다.

---

✅ Managing the Sealing Key

• SealedSecret 내에서 암호화된 데이터를 해독하는 유일한 방법은 컨트롤러가 관리하는 씰링 키를 사용하는 것입니다.
• 재해가 발생한 후 클러스터의 원래 상태를 복원하려는 경우 또는 GitOps 워크플로우를 활용하여 Git 리포지토리에서 SealedSecrets를 포함한 Kubernetes 리소스를 배포하고 새 EKS 클러스터를 생성하려는 경우가 있을 수 있습니다.
• 새 EKS 클러스터에 배포된 컨트롤러는 동일한 봉인 키를 사용해야 SealedSecrets의 봉인을 해제할 수 있습니다.

 

• 다음 명령을 실행하여 클러스터에서 씰링 키를 검색합니다. 프로덕션 환경에서는 이 작업을 수행하는 데 필요한 권한을 제한된 클라이언트 집합에 부여하기 위해 Kubernetes RBAC를 사용하는 것이 모범 사례로 간주됩니다.

 

• 작동을 테스트하기 위해 봉인 키가 포함된 시크릿을 삭제하고 봉인된 시크릿 컨트롤러를 재활용해 보겠습니다:

• 이제 컨트롤러의 로그를 확인해 보겠습니다. SealedSecret 해독에 실패한 것을 확인할 수 있습니다:

• 이는 봉인 키를 삭제하여 컨트롤러가 시작될 때 새 키를 생성했기 때문입니다.
• 이렇게 하면 이 컨트롤러에서 모든 SealedSecret 리소스에 액세스할 수 없게 됩니다. 다행히도 이전에 /tmp/master-sealing-key.yaml에 저장해 두었으므로 EKS 클러스터에서 다시 만들 수 있습니다:

• 로그를 다시 확인해보니 이번에는 컨트롤러가 복원된 봉인 키를 가져와 카탈로그 봉인된 데이터베이스의 비밀을 해제했습니다:

• tmp/master-sealing-key.yaml 파일에는 컨트롤러에서 생성한 공개/개인 키 쌍이 포함되어 있습니다. 이 파일이 손상되면 모든 SealedSecret 매니페스트의 봉인이 해제되고 저장된 암호화된 민감한 정보가 공개될 수 있습니다. 따라서 이 파일은 최소 권한 액세스 권한을 부여하여 보호해야 합니다
• 봉인 키를 보호하는 한 가지 옵션은 AWS 시스템 관리자 매개변수 스토어에 /tmp/master-sealing-key.yaml 파일 내용을 SecureString 매개변수로 저장하는 것입니다. 이 매개변수는 KMS CMK(고객 관리 키)를 사용하여 보호할 수 있으며, 키 정책을 사용하여 이 키를 검색하기 위해 이 키를 사용할 수 있는 IAM 주체의 집합을 제한할 수 있습니다. 또한 KMS에서 이 CMK의 자동 로테이션을 사용 설정할 수도 있습니다. 표준 계층 매개변수는 최대 4096자의 매개변수 값을 지원한다는 점에 유의하세요. 따라서 마스터.yaml 파일의 크기를 고려할 때 고급 티어에 파라미터로 저장해야 합니다.