19.쿠버네티스 환경 변수 사용 및 Probe 설정

이번 장은 파드의 환경 변수를 사용하는 방법과 Secret File을 안전하게 저장하는 SealedSecret, 컨테이너를 안정적으로 운영하기 위한 Readiness, Liveness Probe를 알아보겠습니다.

주요 실습 내용

• ConfigMap, Secret 실습
• SealedSecret 실습

1. 쿠버네티스 ​​ConfigMap, Secret의 이해와 실습

쿠버네티스의 ConfigMap은 애플리케이션의 구성 정보를 컨테이너 이미지와 분리하여 관리하기 위해 사용되는 쿠버네티스의 기본 리소스입니다. 환경 변수, 설정 파일, 명령행 인자 등과 같은 설정 데이터를 저장하는 데에 주로 사용됩니다.

앞에서 설치한 ArgoCD를 예로 알아봅니다.

$ (⎈ |switch-singapore-test:argocd) k get cm -n argocd
NAME                        DATA   AGE
argocd-cm                   6      31d
argocd-cmd-params-cm        23     31d
argocd-gpg-keys-cm          0      31d
argocd-notifications-cm     1      31d
argocd-rbac-cm              3      31d
argocd-ssh-known-hosts-cm   1      31d
argocd-tls-certs-cm         0      31d
kube-root-ca.crt            1      31d

‘argocd-cmd-params-cm’를 확인하면 Argocd 서버에 실행에 필요한 다양한 구성 정보가 있습니다. 

$ (⎈ |switch-singapore-test:argocd) k get cm argocd-cmd-params-cm -oyaml
apiVersion: v1
data:
  controller.log.format: text
  controller.log.level: info
(생략)
  server.basehref: /
  server.dex.server: https://argocd-dex-server:5556
  server.dex.server.strict.tls: "false"
  server.disable.auth: "false"
  server.enable.gzip: "false"
  server.insecure: "false"
(생략)
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
(생략)

ConfigMap은 YAML 파일로 정의되며 다른 리소스와 마찬가지로 apiVersion, kind, metadata, 그리고 data 필드로 구성됩니다. data 필드에 Key-Value 형식으로 원하는 정보를 지정합니다. ConfigMap은 네임스페이스 단위로 지정하여 해당 네임스페이스의 ConfigMap 이름을 지정하여 사용합니다.

파드에서는 환경 변수에 해당 ConfigMap을 사용할 수 있습니다.

$ (⎈ |switch-singapore-test:redis) k get pod -n argocd argocd-server-b694d4bc6-bxnz6 -oyaml
(생략)
spec:
  containers:
  - command:
    - argocd-server
    - --insecure
    env:
    - name: ARGOCD_SERVER_INSECURE
      valueFrom:
        configMapKeyRef:
          key: server.insecure
          name: argocd-cmd-params-cm
          optional: true
    - name: ARGOCD_SERVER_BASEHREF
      valueFrom:
        configMapKeyRef:
          key: server.basehref
          name: argocd-cmd-params-cm
          optional: true
    - name: ARGOCD_SERVER_ROOTPATH

$ (⎈ |switch-singapore-test:argocd) k exec -it argocd-server-b694d4bc6-bxnz6 -- sh
$ echo $ARGOCD_SERVER_INSECURE
false

파드의 YAML 파일의 ‘env’에 ConfigMap의 키값을 지정하며 해당 구성 정보를 파드에서 환경 변수로 사용합니다. 이처럼 애플리케이션의 구성 정보를 컨테이너 이미지와 분리하여, 컨테이너를 빌드하는 동안 구성 정보를 수정하지 않고도 다양한 설정으로 애플리케이션을 실행할 수 있습니다. 이는 이미지를 변경하지 않고 다양한 환경에서 실행할 수 있도록 하는 중요한 특징입니다. 환경에 따라 애플리케이션의 구성을 변경하기 위해 사용되며, 여러 개의 ConfigMap을 조합하여 애플리케이션을 쉽게 커스터마이징할 수 있습니다.

또한 구성 정보를 ConfigMap에 저장하면 해당 정보를 여러 파드에서 공유할 수 있습니다. 여러 파드가 동일한 구성 정보를 사용할 수 있으며, 중앙에서 구성 정보를 업데이트하면 모든 파드가 변경사항을 반영합니다. 

관리자 입장에서도 ConfigMap만 확인하면 실제 서버에 접속하지 않고도 구성 정보를 파악할 수 있어 장애 처리 등이 훨씬 용이합니다.

ConfigMap은 볼륨 디렉토리로 마운트하여 사용할 수도 있습니다. 앞에서 설치한 Redis를 예시입니다.

$ (⎈ |switch-singapore-test:redis) k get pod -o yaml redis-master-0 
(생략)
    volumeMounts:
    - mountPath: /opt/bitnami/redis/mounted-etc
      name: config
(생략)
  volumes:
  - configMap:
      defaultMode: 420
      name: redis-configuration
    name: config

redis-configuration 이름의 ConfigMap을 ‘/opt/bitnami/redis/mounted-etc’ 마운트 포인트로 볼륨으로 사용하고 있습니다. redis-configuration ConfigMap을 확인하면 Redis 설정 시 자주 사용하는 redis.conf 등의 Redis 설정 관련 파일을 볼 수 있습니다.

apiVersion: v1
data:
  master.conf: |-
    dir /data
    # User-supplied master configuration:
    rename-command FLUSHDB ""
    rename-command FLUSHALL ""
    # End of master configuration
  redis.conf: |-
    # User-supplied common configuration:
    # Enable AOF https://redis.io/topics/persistence#append-only-file
    appendonly yes
    # Disable RDB persistence, AOF persistence already enabled.
    save ""
    # End of common configuration
  replica.conf: |-
    dir /data
    # User-supplied replica configuration:
    rename-command FLUSHDB ""
    rename-command FLUSHALL ""
    # End of replica configuration

해당 설정은 헬름 values.yaml에 지정된 값들이 사용됩니다.

Volume 으로 사용한 ConfigMap은 환경 변수로 설정한 것과 다르게 파드를 재시작하지 않아도 변경 사항이 적용되는 차이점이 있습니다.

이처럼 ConfigMap은 애플리케이션의 구성 정보를 쉽게 분리하여 관리하고, 애플리케이션의 유연성을 높이며, 구성 정보를 중앙화하여 여러 파드에서 공유할 수 있게 도와줍니다.

다음으로 쿠버네티스의 Secret은 구성 정보 중 민감한 데이터(예: 비밀번호, 토큰, 인증 정보 등)를 안전하게 저장하고 관리하기 위해 사용되는 쿠버네티스 기본 리소스입니다. Secret은 ConfigMap과 비슷하게 애플리케이션의 구성 정보를 분리하여 컨테이너 이미지와 분리하여 관리할 수 있습니다. 하지만 Secret은 base64 인코딩하여 저장하여 저장하므로 더 높은 보안 수준을 제공합니다. 

그러나 Secret 역시 base64로 인코딩하여 쉽게 노출될 수 있으므로 secret 정보를 깃허브 등에 절대 노출하면 안됩니다. Secret 이름과 다르게 안전하지는 않아 노출하지 않도록 주의해야 합니다.

. 민감한 데이터 보호
비밀번호, 토큰, 인증 정보와 같은 민감한 데이터를 평문으로 컨테이너 이미지에 포함하지 않고, 안전하게 저장하고 사용합니다.

. 보안 강화
Secret은 Base64로 인코딩되어 저장되며, 데이터를 암호화하므로 더 높은 보안 수준을 제공합니다.

. 환경 구성 분리
서로 다른 환경(예: 개발, 테스트, 프로덕션)에 따라 다른 비밀 정보를 사용하여 구성을 분리합니다.

Secret 역시 쿠버네티스 리소스로 YAML 파일을 이용하여 만듭니다. 생성에 앞서 먼저 원하는 정보를 base64로 인코딩합니다.

$ (⎈ |switch-singapore-test:redis) echo -n "admin"|base64
YWRtaW4=

$ (⎈ |switch-singapore-test:redis) echo -n "password"|base64
cGFzc3dvcmQ=

echo -n 옵션을 추가하여 newline(/n)을 포함하지 않게 인코딩합니다. 해당 인코딩 정보를 이용하여 Secret 파일을 생성합니다. 

아래는 Secret 파일 예시입니다.

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  username: YWRtaW4=  # "admin"의 Base64 인코딩 결과
  password: cGFzc3dvcmQ=  # "password"의 Base64 인코딩 결과

해당 파일을 이용하여 리소스를 생성하면 아래와 같이 Secret 리소스를 확인할 수 있습니다.

$ (⎈ |switch-singapore-test:default) k apply -f secret.yaml 
secret/my-secret created

$ (⎈ |switch-singapore-test:default) k get secrets my-secret 
NAME        TYPE     DATA   AGE
my-secret   Opaque   2      10s

GitOps로 관리하면 깃에 Secret 파일을 공유하게 됩니다. 그러면 중요 정보가 손쉽게 노출됩니다.

$ (⎈ |switch-singapore-test:default) echo -n cGFzc3dvcmQ= |base64 -d
password%

Private 깃 레포를 사용해도 로컬에 깃 소스를 내려 받을 수 있으며 외부 업체와 협력하는 경우도 많기 때문에 위험합니다. 평문으로 깃에 중요 정보를 올리는 것과 유사합니다. 좀 더 안전하게 중요 정보를 보관하는 방법이 필요합니다.

2. Secret을 안전하게 보관하는 Sealed Secret 실습

Secret을 안전하게 보관하는 방법으로 ‘Vault’, ‘External Secrets Operator’, ‘Sealed Secrets’를 사용할 수 있습니다. 그 중 쿠버네티스와 잘 통합되고 사용이 간편한 Sealed Secrets을 실습과 알아봅니다.

간단하게 Sealed Secrets 구성을 확인합니다.

일반 Secret은 Base64로 인코딩되어 있을 뿐이지만, Sealed Secrets는 실제로 암호화된 데이터를 생성하여 저장합니다. 암호화된 데이터는 클러스터 내부의 컨트롤러만 복호화할 수 있는 단방향 데이터라 외부에 공개해도 안전합니다. 기존 Secret 리소스는 깃에 정보를 공유할 수 없으나 SealedSecret은 암호화되어 있으므로 깃에 공유하여도 무방합니다. 그리고 개발자는 기존 Secret 리소스를 사용하는 것과 동일하게 사용할 수 있어 다른 도구에 비하여 좀 더 편리합니다.

간단하게 사용하는 방법을 정리합니다.

1) 로컬 PC와 원격 쿠버네티스 클러스터에 각각 ‘kubeseal’과 ‘Sealed Secret Controller’를 설치합니다.
2) Secret 데이터를 암호화하기 위하여 Sealed Secret Controller의 공개키를 로컬에 복사합니다
3) 암호화된 데이터를 생성하고 해당 데이터로 Sealed Secret CRD 매니페스트를 생성합니다.
4) Sealed Secret 리소스는 자동으로 동일한 이름의 Secret 리소스를 생성하고 이제 사용자는 기존과 동일하게 해당 Secret 리소스를 사용합니다.
5) 원격 깃소스에 안전한 Sealed Secret CRD를 동기화하여 관리합니다.

그럼 실습으로 알아봅니다.

먼저, 로컬 PC와 클러스터에 각각 Sealed Secret을 설치합니다. 로컬 PC에 일반 Secret을 암호화하는 ‘kubeseal’ 도구를 설치합니다.

$ (⎈ |switch-singapore-test:redis) brew install kubeseal

다음으로 쿠버네티스 클러스터에 sealed-secrets cotroller를 헬름으로 설치합니다.

$ (⎈ |switch-singapore-test:redis) helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
$ (⎈ |switch-singapore-test:redis) helm pull sealed-secrets/sealed-secrets --version 2.10.0
$ (⎈ |switch-singapore-test:redis) tar xvfz sealed-secrets-2.10.0.tgz     
$ (⎈ |switch-singapore-test:redis) rm -rf sealed-secrets-2.10.0.tgz 
$ (⎈ |switch-singapore-test:redis) mv sealed-secrets sealed-secrets-2.10.0
$ (⎈ |switch-singapore-test:redis) cd sealed-secrets-2.10.0 
$ (⎈ |switch-singapore-test:redis) mkdir ci         
$ (⎈ |switch-singapore-test:redis) cp values.yaml ci/my-values.yaml

Values 파일은 기본 설정 변경없이 설치합니다. helm install 명령어를 사용하여 로컬에서 설치할수도 있으나 GitOps 정책을 유지하기 위하여 ArgoCD로 설치합니다. ArgoCD Application 파일을 생성합니다.

sealed-secrets-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sealed-secrets
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: kube-system
    server: {{ .Values.spec.destination.server }}
  project: default
  source:
    path: sealed-secrets-2.10.0
    helm:
      valueFiles:
      - ci/singapore-test-values.yaml
    repoURL: {{ .Values.spec.source.repoURL }}
    targetRevision: {{ .Values.spec.source.targetRevision }}
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - RespectIgnoreDifferences=true

ArgoCD Application 파일을 생성합니다.

$ (⎈ |switch-singapore-test:redis) k apply -f sealed-secrets-application.yaml 

ArgoCD에서 배포가 잘되는지 확인합니다.

kube-system 네임스페이스에 sealed-secrets controller가 설치되었습니다.

$ (⎈ |switch-singapore-test:kube-system) k get pod -n kube-system sealed-secrets-5fcf64df9d-xnw9v 
NAME                              READY   STATUS    RESTARTS   AGE
sealed-secrets-5fcf64df9d-xnw9v   1/1     Running   0          63s

이제 클라이언트와 서버에 Sealed Secrets 사용할 준비가 되었습니다.

Sealed Secretes를 사용하기 위해서는 로컬 PC에서 ‘kubeseal’ 명령어를 사용하여 암호화된 Secret을 생성합니다. 먼저 데이터를 암호화하기 위해서 Sealed Secret Controller의 인증서를 로컬 PC에 저장합니다. 인증서는 Sealed Secret의  Secret 리소스로 저장되어 있습니다.

$ (⎈ |switch-singapore-test:default) k get secrets -n kube-system sealed-secrets-keywwwh4
NAME                      TYPE                DATA   AGE
sealed-secrets-keywwwh4   kubernetes.io/tls   2      4h37m

Secret 리소스의 인증서(tls.crt) 데이터를 사용하기 위해 디코딩(view-secret)하고 Export 하여 로컬 파일에 저장합니다. ‘k view-secret’를 사용하면 디코딩 명령어(base64 -d)없이 바로 가능합니다.

$ (⎈ |switch-singapore-test:default) k view-secret -n kube-system sealed-secrets-keywwwh4 tls.crt
-----BEGIN CERTIFICATE-----
MIIEzTCCArWgAwIBAgIRAPIshqc93BboOE3wcaUBdK0wDQYJKoZIhvcNAQELBQAw
(생략)


$ (⎈ |switch-singapore-test:default) k view-secret -n kube-system sealed-secrets-keywwwh4 tls.crt > ~/my-tls.crt 

$ (⎈ |switch-singapore-test:default) ls ~/my-tls.crt 
/Users/jerry/my-tls.crt

해당 인증서를 이용하여 암호화된 파일을 만듭니다. 암호화하려는 데이터와 Secret 이름, 네임스페이스를 지정하여 암호화된 Raw 데이터를 kubeseal –raw 옵션을 이용하여 생성합니다.

$ (⎈ |switch-singapore-test:default) echo -n password |kubeseal --raw --cert ~/my-tls.crt --namespace default --name sealed-secret
AgAMmdw96eh/Yu4cXY+aTfXRZDL2tgwVMlqR3cchMp6no3rDoxnp3C2UkQiUBwyhzU+50pAcjO9RldOBofmPyAtRblXwt/(생략)

생성한 암호화 데이터를 이용하여 SealedSecret CRD 리소스를 생성합니다. SealedSecret 리소스는 Sealed Secret Controller로 관리하여 암호화된 데이터로 쿠버네티스 Secret 리소스를 생성합니다. 아래의 YAML 파일을 이용하여 생성합니다.

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: sealed-secret
  namespace: default
spec:
  encryptedData:
    PostgreSQL_PASSWORD: AgAMmdw96eh/Yu4cXY+aTfXRZDL2tgwVMlqR3cchMp6no3rDoxnp3C2UkQiUBwyhzU+50pAcjO9RldOBofm(생략)

‘SealedSecret’ 매니페스트를 적용하면 sealedsecret CRD가 생성됩니다.

$ (⎈ |switch-singapore-test:default) k apply -f SealedSecret.yaml 
sealedsecret.bitnami.com/sealed-secret created

$ (⎈ |switch-singapore-test:default) k get sealedsecrets.bitnami.com 
NAME            STATUS   SYNCED   AGE
sealed-secret            True     14s

그러면 자동으로 동일한 이름(sealed-secret)의 secret 리소스를 확인할 수 있습니다.

$ (⎈ |switch-singapore-test:default) k get secrets sealed-secret 
NAME            TYPE     DATA   AGE
sealed-secret   Opaque   1      44s

상세 정보를 확인하면 해당 Secret 리소스는 SealedSecret CRD가 관리한다는 설명을 확인할 수 있습니다. 즉 Secret 리소스를 직접 생성하지 않고 SealedSecret으로 생성하였습니다.

$ (⎈ |switch-singapore-test:default) k get secrets sealed-secret -oyaml
(생략)
metadata:
  name: sealed-secret
  namespace: default
  ownerReferences:
  - apiVersion: bitnami.com/v1alpha1
    controller: true
    kind: SealedSecret
    name: sealed-secret
    uid: 8c8a95c8-8152-44ed-a16c-c2e3fdfb4652

SealedSecret Controller 파드의 로그를 확인하면 아래와 같이 SealedSecret 리소스가 unsealed 작업을 수행한 것을 알 수 있습니다. 혹시 Secret 관련 에러가 발생하면 해당 파드의 로그를 확인하면 됩니다.

$ (⎈ |switch-singapore-test:default) k -n kube-system logs sealed-secrets-controller-68b68d6866-7m799
(생략)
Event(v1.ObjectReference{Kind:"SealedSecret", Namespace:"default", Name:"sealed-secret", UID:"8c8a95c8-8152-44ed-a16c-c2e3fdfb4652", APIVersion:"bitnami.com/v1alpha1", ResourceVersion:"23261565", FieldPath:""}): type: 'Normal' reason: 'Unsealed' SealedSecret unsealed successfully
WARNING: Empty API version & kind, filling it...
update suppressed, no changes in sealed secret spec of default/sealed-secret

이와 같이 SealedSecret 리소스를 사용하여 Secret 리소스를 생성할 수 있습니다. 이제 깃에 안전하지 않는 Secret 리소스를 삭제하고 앞에서 사용한 암호화된 SealedSecret 매니페스트를 안전하게 공유할 수 있습니다.

3. Readiness & Liveness Probe 설정

이번 절은 쿠버네티스에서 실행 중인 애플리케이션의 안정성을 향상시키기 위해서 사용하는 Probe를 알아보겠습니다.

Readiness와 Liveness Probe는 쿠버네티스에서 컨테이너의 상태를 확인하고 모니터링하기 위해 사용합니다. 이들 Probe는 각각 컨테이너의 준비 상태와 생존 상태를 검사하여 애플리케이션의 안정성과 가용성을 유지하는 데에 도움을 줍니다.

Readiness Probe는 컨테이너가 시작한 후, 요청을 처리할 준비가 되었는지 확인하는 데에 사용됩니다. 만약 Readiness Probe가 실패하면 EndPoint(서비스 장 참조)에서 해당 파드가 제외되어 해당 파드로 트래픽이 전달되지 않습니다. 주로 애플리케이션이 시작한 후 정상적으로 초기화되었는지를 확인하거나, 외부 서비스와 연결이 가능한지를 확인하는 데에 사용됩니다. DB와 연결이 정상이 되고 나서 서비스에 투입하는 용도로 많이 사용합니다.

만약 Readiness Probe가 실패하는 경우, 해당 파드는 트래픽을 받지 않으며, 로드밸런서 또는 서비스 디스커버리 메커니즘에서 해당 파드를 제외시킵니다. 이는 일시적인 오류나 초기화가 완료되기 전까지 트래픽을 막는 데에 유용합니다.

Liveness Probe는 컨테이너가 실행 중인지를 확인하고, 컨테이너가 정상적인 상태인지를 확인하는 데에 사용됩니다. 애플리케이션이 실행 중에 예기치 않은 오류로 인해 정상적인 상태가 아닐 경우, Liveness Probe가 실패하여 컨테이너가 다시 시작되도록 유도합니다. 파드가 실행은 되고 있으나 정상적인 트래픽 처리를 못하는 ‘Hang’ 상태일 때 파드를 자동으로 재시작하여 아주 유용합니다. 

MariaDB 등 거의 모든 Application 설정에는 아래와 같이 Liveness, Readiness Probe 설정을 포함합니다. Kafka, Redis, Prometheus, ArgoCD 등도 동일합니다. 필자도 운영 중인 자체 개발 애플리케이션에 Probe를 포함하도록 개발자에게 가이드합니다. 

실제 MariaDB에서 사용하는 Probe 사례입니다.

$ (⎈ |alooo:mariadb) k get pod mariadb-mariadb-galera-0 -oyaml
(생략)
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: metrics
        scheme: HTTP
      initialDelaySeconds: 30
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
(생략)
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: metrics
        scheme: HTTP
      initialDelaySeconds: 5
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1

각 애플리케이션 상황에 따라 Probe 옵션을 별도로 구성합니다.

. failureThreshold
Probe가 성공하지 못한 후 컨테이너가 실패로 간주되기 전에 최대로 허용되는 연속 실패 횟수를 지정합니다. 기본값은 3입니다. 즉, 3회 연속 실패한 경우 해당 Probe가 실패로 간주됩니다.

. httpGet
Probe를 검증하는 방법으로 httpGet 뿐만 아니라 tcp, command, grpc 등을 사용할 수 있습니다.

. initialDelaySeconds
컨테이너가 시작한 후 Probe를 시작하기까지의 대기 시간을 지정합니다. 즉, 컨테이너가 시작되고 지정된 시간(초) 이후에 처음으로 Probe가 실행됩니다. 처음 기동 시간이 필요한 애플리케이션은 해당 옵션을 180s(3분) 정도 길게 지정하기도 합니다.

. periodSeconds
Probe가 주기적으로 실행되는 주기를 지정합니다. 즉, 각 Probe 실행 사이의 시간 간격을 지정합니다.

. successThreshold
컨테이너가 성공으로 간주되기 전에 최소로 필요한 연속 성공 횟수를 지정합니다. 기본값은 1입니다. 즉, 1회 성공한 경우 해당 Probe가 성공으로 간주됩니다.

. timeoutSeconds
Probe가 응답을 기다리는 최대 시간을 지정합니다. 즉, 지정된 시간(초) 동안 Probe가 응답을 기다리는 동안 응답이 오지 않으면 해당 Probe가 실패로 간주됩니다.

이와 같이 Probe의 옵션을 적절하게 설정하여 애플리케이션의 상태를 정확하게 모니터링하고, 오류를 신속하게 감지하여 서비스의 가용성과 안정성을 유지하는 데에 유용하게 사용할 수 있습니다.

이 외 Startup Probe는 Kubernetes 1.16 버전부터 지원되는 새로운 종류의 Probe로, 애플리케이션의 초기화 단계를 모니터링하기 위해 사용됩니다. Startup Probe는 컨테이너가 시작되고 초기화를 완료하기 전까지만 동작합니다. 주로 데이터베이스와 같은 백엔드 서비스를 서비스를 초기화하는데 많은 시간이 소요되는 경우 사용합니다.

이상으로 이번 장에서는 쿠버네티스 환경에서 환경 변수 및 Probe 사용법을 알아보았습니다.

해당 기술 블로그에 질문이 있으시면 언제든지 문의해 주세요. 직접 답변해 드립니다.
k8sqna@jennifersoft.com

1. Hashcorp Vault:  https://www.vaultproject.io/
2. External Secrets Operator : https://external-secrets.io/v0.8.5/
3.Sealed Secrets : https://github.com/bitnami-labs/sealed-secrets
4. 암호화된 Sealed Secret 생성 방법 참조 : https://github.com/bitnami-labs/sealed-secrets#raw-mode-experimental