投稿日：
更新日：

KES 非推奨に伴う ESO への移行

Authors

目次

はじめに

従来、Kubernetes では秘匿情報を管理するコンポーネントとして KES（Kubernetes External Secrets）が広く利用されており、Secret リソースを管理するツールとしてデファクトスタンダートとなっていました。 しかし、2021 年 11 月 KES の非推奨化が発表され、2022 年 7 月時点でアーカイブされました。

KES が非推奨になった背景としては、アクティブなメンテナがいなかったことや、プロジェクト内で抱えていた技術負債を解消しきれず、メンテナンスのモチベーションを維持できなかったことが言及されています。

KES の非推奨化に伴う後継ツールの一つとして ESO（External Secrets Operator）が注目を集めています。 ESO は KES を開発していたコミュニティによってホスティングされており、Go でリファクタリングされています。 ESO は KES との互換性を維持しつつ、メンテナンス性を重視した機能豊富なサービスとなっており、移行ツールも用意されています。

今回の記事では、KES の非推奨化に伴う ESO への移行について、ツールの特徴を交えながら紹介したいと思います。

Kubernetes における秘匿情報の管理

Kubernetes における Secret リソース とは、その名の通り秘匿（Secret）情報を管理するリソースです。 例えば、データベースの接続情報や各種クラウドプロバイダのリソースにアクセスするためのアカウントキーは Kubernetes の Secret マニフェストで定義できます。

---
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  DATABASE_USER: 'YWRtaW4='
  DATABASE_PASS: 'cGFzc3dvcmQ='
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
spec:
  spec:
    containers:
      - name: my-container
        image: my-image:latest
        envFrom:
          - secretRef:
              name: my-secret # Secret リソースを参照

しかし、Kubernetes における Secret リソースは暗号化方式として base64 を採用しているため、マニフェストを参照可能な開発者であれば誰でも簡単にデコードできてしまうという問題があります。

$ echo "YWRtaW4=" | base64 --decode # admin
$ echo "cGFzc3dvcmQ=" | base64 --decode # password

また、一般に Kubernetes の運用には ArgoCD や PipeCD といった CD ツールを用いますが、多くの場合 GitHub 等のバージョン管理システムを通じた GitOps が前提となっています。 秘匿情報を GitHub のようなパブリックな場にコミットすることは、セキュリティの観点でリスクとなります。 そのため、AWS や GCP、Azure といった外部プロバイダのシークレットストアと Kubernetes を連携する仕組みが必要になります。

KES：Kubernetes External Secrets

前述のようなケースにおいて、外部プロバイダで管理している秘匿情報をクラスタからセキュアに参照する仕組みとして Kubernetes のカスタムリソースとして定義されている ExternalSecret を使用します。

KES（Kubernetes External Secrets）は、ExternalSecret を管理する Kubernetes のオペレータ（コントローラ）であり、AWS Secrets Manager や GCP Secret Manager、Azure Key Vault といったパブリッククラウドに登録された秘匿情報を Secret リソースに渡すことができます。

KES は、もともとドメイン管理サービス等を提供している GoDaddy 社 によって開発がキックされましたが、後に Linux Foundation 商標 の下、external-secrets.io に移管されました。

KES を使用することで、Secret マニフェストを直接バージョン管理システムにコミットする必要がなくなり、秘匿情報をセキュアに扱うことが可能です。

アーキテクチャ

kes-architecture.png

  1. クラスタに ExternalSecret リソースが追加される
  2. コントローラは Kubernetes API を使用して ExternalSecret を作成する
  3. コントローラは ExternalSecret リソースを使用して外部プロバイダにアクセスし、秘匿情報を取得する
  4. コントローラは ExternalSecret の情報を元に Secret リソースをアップサートする
  5. Pod が Secret リソースを参照する

ユースケース

apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
  namespace: default
spec:
  backendType: secretsManager # 外部プロバイダ
  data:
    - key: database
      name: db-credentials
外部プロバイダbackendType
AWS Secrets ManagersecretsManager
AWS SSM Parameter StoresystemManager
GCP Secret ManagergcpSecretsManager
Azure Key VaultazureKeyVault
Hashicorp Vaultvault
Akeyless Vaultakeyless
Alibaba Cloud KMS Secret ManageralicloudSecretsManager
IBM Cloud Secrets ManageribmcloudSecretsManager

ExternalSecret では、外部プロバイダに登録されているシークレットのキーを key フィールドに登録し、name フィールドで参照します。

kes-usecase.png

このユースケースでは、KES が ExternalSecret の内容をもとに AWS Secrets Manager に登録されているデータを取得して Secret リソースを作成します。 Pod は、ExternalSecret が作成した Secret を参照するか、Volume としてマウントします。 このように外部プロバイダ（AWS）で管理している秘匿情報を Kubernetes から参照利用することによって、base64 ベースの Secret マニフェストを直接コミットせずに済むため、セキュアに扱うことが可能です。

KES の非推奨化

KES は 2021 年 11 月頃、external-secrets.io より非推奨化が発表されました。 KES が非推奨になった背景としては、アクティブなメンテナがいなかったことや、プロジェクト内で抱えていた技術負債を解消しきれず、メンテナンスのモチベーションを維持できなかったことが言及されています。

#864: KES is deprecated, migrate to ESO!

kes-deprecated.png

同時に、後継ツールとして KES の代わりに ESO（External Secrets Operator）を使用することが推奨されています。 ESO は、それまで JavaScript ベース（Node.js）で実装されていた KES を Kubernetes コミュニティに優しい Go でリファクタリングし、メンテナンス性やパフォーマンスを重視した機能豊富な OSS となっています。

また、kes-to-eso というマイグレーションを支援する CLI も用意されており、移行コストが考慮されています。

コミュニティの温度感からも、今後は KES の移行先として ESO が広く普及することが予想されます。

KES 互換の OSS

コミュニティは ESO を推奨していますが、KES 互換のツールとしては他にどのような OSS があるのでしょうか。

ネットの記事を漁っていると、よく見かけるのが Secrets Store CSI Driver と Sealed Secrets です。

Secrets Store CSI Driver

secrets-store-csi-driver-logo.png

Secrets Store CSI Driver は Kubernetes の SIG-related work を管理・運用する Kubernetes SIGs が開発元となっています。 Secrets Store CSI Driver は CSI（Container Storage Interface）を利用して、秘匿情報を Pod に Volume としてマウントします。 また、マウントしたものを Secret に同期したり、複数の Secret オブジェクトを 1 つの Volume としてマウントする等、多様な機能があります。

CSI（Container Storage Interface）

  • Kubernetes、OpenShift 等のコンテナ化されたワークロードに任意のブロックおよびファイルストレージシステムを公開するための標準仕様
  • CSI を通じて、HDD、SSD、クラウドプロバイダの任意のストレージを共通のインターフェース経由で使用できる
  • 例えば、GCP の場合、Google Secret Manager Provider for Secret Store CSI Driver を使用して Secret Manager にアクセスできる

アーキテクチャ

secrets-store-csi-driver.png

DaemonSet によって起動された Pod を介して外部のシークレットストアにアクセスし、取得した秘匿情報をターゲットとなる Pod にマウントします。 DaemonSet なので、全ての Data-Plane で最低一つの Pod が起動します。 どの秘匿情報を取得するかは、SecretProviderClass というカスタムリソースで制御でき、KSA（AWS IRSA や GCP Workload Identity）を通じて AWS や GCP にアクセスします。

懸念点

KES との親和性はあまり高くないと思われます。

直接 Pod に対して CSI Driver で秘匿情報をマウントする必要があることから、既存のマニフェストを変更する必要があるため、大規模なサービスでは移行コストが高くなる可能性があります。

とは言っても、Kubernetes SIGs がバックにいるため、今後のアップデートには眼が離せない OSS です。

Sealed Secrets

sealed-secrets-logo.png

Sealed Secrets は、WEB アプリケーション関連のソフトウェアパッケージを提供している Bitnami（Bitrock 社）が開発元となっています。 Sealed Secrets は全ての Kubernetes Config を GitHub で管理することを目的に誕生しました。 Secret を Sealed Secrets に暗号化させ、Kubernetes マニフェストを生成します。 Kubernetes で動作するコントローラのみが復号でき、シークレットの作成者でさえも（秘密鍵を持たない開発者は）Sealed Secret からオリジナルの Secret を取得できない公開鍵暗号方式を採用しています。 そのため、パブリックなリポジトリにコミットしたとしても、秘匿情報をセキュアに保管できます。

アーキテクチャ

sealed-secrets.png

開発者は Sealed Secrets によって生成された公開鍵を利用して kubeseal コマンドで Secret リソースをパースします。 これにより、SealedSecret マニフェストが生成され、秘匿情報が公開鍵で暗号化された状態で格納されます。

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: my-sealedsecret
spec:
  encryptedData:
    secret: AgBPNEC9qTnTzl5LomlaL7ncdxPONnWa1ooZB5tUXrhOESClY4k3...
  template:
    metadata:
      name: my-sealedsecret

SealedSecret リソースがクラスタにデプロイされると、Sealed Secrets のコントローラに事前に登録しておいた秘密鍵で復号され、Secret リソースが生成されます。 最終的に、Secret リソースを Pod が参照することで、秘匿情報を利用します。

懸念点

運用開始後の方針にも目を向ける必要があり、管理コストの懸念があると思われる。

秘密鍵で全てのシークレット情報を暗号化している場合、キーローテーションに伴い、全ての Sealed Secret リソースを再暗号化する必要があります。 また、GitOps では暗号化した秘匿情報はバージョン管理システムにコミットする必要があるため、万が一、秘密鍵が流出した場合は SealedSecret が復号されてしまう可能性があります。

ESO：External Secrets Operator

eso-logo.png

参考：https://external-secrets.io/latest/introduction/overview/

The External Secrets Operator extends Kubernetes with Custom Resources, which define where secrets live and how to synchronize them. The controller fetches secrets from an external API and creates Kubernetes secrets. If the secret from the external API changes, the controller will reconcile the state in the cluster and update the secrets accordingly.

External Secrets Operator は、シークレットの保存場所と同期方法を定義するカスタムリソースを使用して Kubernetes を拡張します。 コントローラは外部 API からシークレットを取得し、Kubernetes Secret リソースを作成します。 外部 API からシークレットが変更されると、コントローラはクラスタ内の状態を調整し、それに応じてシークレットを更新します。

eso-architecture.png

ESO（External Secrets Operator）は、KES と同様に、各種外部プロバイダで管理している秘匿情報をセキュアにクラスタから参照利用するためのツールです。 また、シークレットストア側で秘匿情報の変更があった場合は、ESO コントローラの Reconciliation によってその変更を検知し、クラスタ内の Secret リソースに自動的に反映します。

ESO は KES と同じ ExternalSecret というリソースを利用して秘匿情報を管理します。 KES との大きな違いは ExternalSecret が外部のシークレットストアに接続するための情報を直接管理しない 点です。

ESO には 3 つのリソースタイプがあります。

  • ExternalSecret

    保存する秘匿情報とその名前を指定します。

  • SecretStore eso-secret-store.png 外部のシークレットストアに接続するための情報を指定します。（名前空間スコープ）

  • ClusterSecretStore eso-cluster-secret-store.png 外部のシークレットストアに接続するための情報を指定します。（クラスタスコープ）

SecretStore と ClusterSecretStore の違いは、ExternalSecrets が外部のシークレットストアに対して使用するアクセス情報が、名前空間毎に管理されるか、クラスタ毎（複数の名前空間を跨ぐ）に管理されるか です。 後者は、アクセスに共有権限を使用するため、すべてのシークレットストアの認証情報が必要となります。 従って、名前空間レベルでセキュリティが異なる場合は SecretStore が最適です。

ESO を利用するための権限

今回は GKE を例に、ESO を GCP と連携する際の権限周りについて詳述します。

一般に、Kubernetes のワークロードを GCP のサービスに接続する際は、GSA（GCP Service Account）を利用します。 また、GSA の権限や IAM ロールを KSA（Kubernetes Service Account）が利用できるように、Workload Identity という OIDC に則った仕組みを利用します。

What is Workload Identity Federation?

workload-identity.png

ExternalSecret が GCP Secret Manager にアクセスする方法は 3 つあります。参考

  1. SecretStore への必要最小限の権限を持つ GSA を付与する
  2. 全ての Secret Manager にアクセスできる GSA を ClusterSecretStore に付与する
  3. 全ての Secret Manager にアクセスできる GSA を ExternalSecret Pod に直接付与する

前提として、これらの GSA には Workload Identity User と Secret Manager の Read 権限を付与します。 加えて、SecretStore に GSA を割り当てる場合、roles/iam.serviceAccountTokenCreator も追加で必要となります。

3 つアクセス方法がありますが、最小権限の原則（PoLP：Principle of Least Privilege）に従うと、必要な SecretManager のみにアクセスを制限する 1 の方法が最善策かと思います。 また、2 の場合でも、複数の ClusterSecretStore を設定することで認可の範囲を制限することができます。

公式では、ClusterSecretStore へのアクセスを制限する際に、Kyverno や OPA（Open Policy Agent）等のポリシ管理ツールおよび Admission Webhook を利用することが推奨されています。

マルチテナントを考慮した設計

ESO のマルチテナントを考慮した設計パターンについて紹介します。参考

Shared ClusterSecretStore

shared-clustersecretstore.png

小規模な環境や全てのシークレットが集約されているケースにおいて、よりシンプルな設計で構築することを目的としています。

クラスタ管理者は、クラスタ全体で共通の ClusterSecretStore をデプロイし、外部 API へのアクセスも一元管理します。 単一の ClusterSecretStore を全てのテナントが共有し、アプリケーション開発者は ExternalSecret を通じてこれを参照しますが、自ら ClusterSecretStore や SecretStore を作成することはできません。

この設計パターンは、クラスタ全体でシークレットを一元管理できるため管理コストが下がるという利点があります。 一方で、アプリケーションの開発者は全てのシークレットにアクセス可能であり、テナント数が増加するとセキュリティリスクも伴うため、スケーラビリティの面で課題が生じます。

また、ESO 自体には名前空間毎に特定のキーへのアクセスを制限する機能が無いため、必要に応じて Admission Webhook のような外部ツールを使用して詳細なアクセス制御を実装することが求められます。

シークレットの管理が複雑化する状況や、名前空間毎にアクセス制限をかける場合は、後述する Managed SecretStore per Namespace を使用することが推奨されます。

Managed SecretStore per Namespace

managed-secretstore-per-namespace.png

各テナントに対して独立したシークレット管理を提供することを目的としています。

クラスタ管理者は External Secrets Operator をプロビジョニング・管理し、さらに名前空間毎に 1 つまたは複数の SecretStore を管理します。 名前空間毎に設定された各 SecretStore は、特定のキーセットへのアクセスを外部 API が提供するロール（IAM Role や IAM Policy）に基づいて制御します。

この設計パターンは、大規模な環境で複数チームが独立してシークレットを管理するケースや、セキュリティポリシに基づいて特定のアプリケーションのみが特定のシークレットにアクセスできるようにしたい場合に有効です。 各名前空間毎に異なるアクセス制御を設定することでセキュリティが強化され、管理の簡略化が図れます。

主観だと、この設計パターンが最もしっくりきました。

ESO as a Service

eso-as-a-service.png

チーム毎の柔軟性と効率性を向上つつ、全体のセキュリティと運用効率を維持することを目的としています。

クラスタの管理者は External Secrets Operator のみをプロビジョニング・管理します。 各名前空間は自己完結型で、アプリケーションの開発者はサービスに応じて名前空間を作成し、SecretStore、ExternalSecret、外部のシークレットストアを独自に管理します。

この設計パターンは、例えばインフラ運用チームが標準化されたクラスタを提供しつつ、各開発チームが自身のニーズに合わせて作業したい場合に使用することで、運用の柔軟性が増します。

ESO への移行

基本方針として、KES に加えて ESO を追加でデプロイしてから移行作業を開始します。

KES から ESO に移行する方法としては大きく 2 つ挙げられます。

  1. 公式のマイグレーションツールを使用する
  2. 手動で移行する

1 に関しては、コミュニティより kes-to-eso という KES から ESO に移行するためのマイグレーションツールが提供されているため、そちらを利用します。 2 は大規模プロダクトにおいて特に移行スクリプトの利用に不安がある場合や、特定の ExternalSecret のみを移行したい場合に手動での作業を実施します。

1 と 2 のそれぞれについて大まかな移行方法をドキュメントを参考に紹介します。

⚠️ 注意

kes-to-eso は単なる移行ツールであるため、ESO のデプロイについてはサポートされていません。 作業前に、必ず ESO がデプロイされていることを確認してから実施してください。

公式のマイグレーションツールを使用する

基本的に、こちら にある通りマイグレーションスクリプトを実行するだけですが、いくつか注意点があります。

リポジトリにある bin ディレクトリのバイナリは全てのアーキテクチャで動作するわけではありません。 実際に、bin/kestoeso は Mac M1 Pro（おそらく ARM 系）では動作しないことが確認されています。

そのため、go build にアーキテクチャを指定する GOARCH オプションを付与してリビルドする必要があります。

  • migration.sh
#! /bin/bash -e

KES_NAMESPACE="kes"
ESO_NAMESPACE="es"
# Have KES and ESO both installed
#Step 0  manual step to get .yaml files for KES External Secrets
## can be done with:
mkdir -p kes_files
mkdir -p eso_files
bash -c "$(kubectl get externalsecrets.kubernetes-client.io -A -o=jsonpath='{range .items[*]}{"kubectl get externalsecrets.kubernetes-client.io -o yaml -n "}{.metadata.namespace}{" "}{.metadata.name}{" >> kes_files/"}{.metadata.namespace}{"-"}{.metadata.name}{".yaml; "}{end}')"

#Step 1 Scale ESO to 0 (safeguard, really)
kubectl scale deployment -n $ESO_NAMESPACE external-secrets --replicas=0

#Step 2 Generate ESO files and apply them
bin/kestoeso generate -i kes_files -o eso_files -n $KES_NAMESPACE

kubectl apply -f eso_files

# Step 3 - Scale KES to 0
kubectl scale deployment -n $KES_NAMESPACE kubernetes-external-secrets --replicas=0

# Step 4 - Update Ownership references
bin/kestoeso apply --all-secrets --all-namespaces #
# kestoeso apply -n changeme-my-target-ns -s my-secret-1,my-secret-2 # Alternative for people that want to do a step-by-step migration

# Step 5 - Scale ESO to 1
kubectl scale deployment -n $ESO_NAMESPACE external-secrets --replicas=1

migration.sh は KES および ESO の名前空間名を環境変数として取得するようになっているため、必要に応じて編集します。

このスクリプトは、大まかに次の手順を実行します。

  1. クラスタから KES ExternalSecret マニフェストをダウンロードして kes_files フォルダに保存する
  2. ESO のレプリカセットを 0 にする
  3. kestoeso generate を実行して eso_files フォルダに ESO ExternalSecret と SecretStores を生成する
  4. ESO ExternalSecret と SecretStores をクラスタに適用する
  5. KES レプリカセットを 0 にする
  6. 対象となっている名前空間で kestoeso apply を実行し、全ての KES 管理のシークレットから所有権を削除する
  7. ESO のレプリカセットを 1 に設定して運用を開始する

また、ロールバックする場合は、KES レプリカセットを 1 に、ESO レプリカセットを 0 に設定することで実行できます。

$ ./rollback.sh

公式のマイグレーションツールを利用することで ESO から容易に切り替えることが可能ですが、大抵の場合は IaC で管理しているため、マニフェストリポジトリを更新する必要がありそうです。

正直、直接本番環境で実行することはあまりお勧めできません。 事前に検証環境で実行できることを確認し、生成されるマニフェストや Pod の挙動を確認した後、Production マニフェストの必要箇所を手動で書き換えて適用するのが良いかと思います。

手動で移行する

続いて手動で移行作業を実施する場合の手順について こちら を参考に紹介します。

  1. KES で管理されている ExternalSecret リソースを取得

以下のコマンドを実行し、KES マニフェストを取得・保存します。

$ bash -c "$(kubectl get externalsecrets.kubernetes-client.io -n <MY_NAMESPACE> -o=jsonpath='{range .items[*]}{"kubectl get externalsecrets.kubernetes-client.io -o yaml -n "}{.metadata.namespace}{" "}{.metadata.name}{" >> path/to/input/"}{.metadata.namespace}{"-"}{.metadata.name}{".yaml; "}{end}')"

このコマンドは指定した名前空間内の全ての KES ExternalSecret を取得します。

  1. ESO マニフェストの生成

以下のコマンドを実行し、取得したマニフェストから ESO 用のマニフェストを生成します。

$ kestoeso generate -i path/to/input -o path/to/output -n <namespace where kes is deployed>

kestoeso は、変換が正しく行われなかった場合に警告を出力し、そのファイルをテンプレート化します。 もし、警告が出た場合は、生成されたファイルを必要に応じて修正します。

  1. テンプレートファイルへの対応

kestoeso はテンプレートの使用やパスの使用を含む KES ExternalSecret を見つけた場合、そのファイルをスキップします。 このようなケースは手動で対応する必要がありそうです。

  1. ServiceAccount および Secret の参照の更新

必要に応じて、ServiceAccount や Secret の参照を更新します。 また、ClusterSecretStores を必要に応じて SecretStores に更新することも検討してください。

参考：KES 非推奨に伴う ESO への移行 - #マルチテナントを考慮した設計

  1. ESO マニフェストの適用

生成された ESO マニフェストをクラスタに適用します。

  1. シークレット所有権の更新

KES の ExternalSecret を削除するとシークレットも削除されてしまうため、シークレットの所有権を ESO に変更することが推奨されます。

まず KES の Deployment を停止するため、レプリカ数を 0 にします。 その後、手動で各シークレットの所有権を変更するか、以下のコマンドを使用します。

$ kestoeso apply

このコマンドの実態は、こちら のコードとなっており、各シークレットリソースの ownerReferences フィールドを KES から ESO の情報に変更していることが分かります。

これにより、KES から ESO に所有権が移行されます。 シークレットの所有権が変更されたかどうかは、以下のコマンドで確認できます。

$ kubectl get secrets <secretname> -o yaml | grep -i ownerReferences -A10

  ownerReferences:
  - apiVersion: external-secrets.io/v1beta1 # この Secret リソースを作成した親リソースが external-secrets.io/v1beta1 であれば所有権が移管されている
    blockOwnerDeletion: true
    controller: true
    kind: ExternalSecret
    name: my-external-secret
    uid: a2289145-1234-4a1a-920a-612af153fff9
  resourceVersion: "761234092"
  uid: 8fa79cda-1234-4c37-b0cc-10061b39b3e9
type: Opaque

特に捻りも無く migration.sh がやっている手順をそのまま手動で実行するだけのようですね。

移行の際の注意点

KES to ESO - Warnings

  • 適切な認証

Kubeconfig が正しく設定されている必要があります。

  • エラーハンドリング

所有権更新中にエラーが発生した場合、適切に処理しシステムの整合性を保つことが重要です。

  • KES のスケールダウン

所有権を移行する前に必ず KES のデプロイメントを停止（スケールダウン）することで、KES が所有権を再度取得するのを防ぎます。

  • KES の削除タイミング

ESO への移行後、動作検証（シークレット所有権が ESO に移管されている）の確認が取れてから KES（CRD, Deployment, ServiceAccount, ...etc.）の削除作業を実施してください。 大まかな手順は次の通りです。

  1. ESO（CRD, Deployment, ServiceAccount, ...etc.）をデプロイ
  2. ESO ExternalSecret と SecretStore をデプロイ
  3. シークレット所有権が ESO に移管されていることを確認
  4. KES ExternalSecret を削除
  5. KES（CRD, Deployment, ServiceAccount, ...etc.）を削除

制約事項

KES to ESO - Limitations

  • テンプレート化された ExternalSecret 定義を移行することはできない

テンプレートは、動的にシークレットを生成するための柔軟な機能を提供しますが、このテンプレートを自動で別の形式に変換することは複雑です。 テンプレートに基づく変換はコンテキストや環境、特定の使用例に依存するため、機械的な変換が困難です。 従って、テンプレートを使用している場合は、手動で確認・変換する必要があります。

  • data または dataFrom 定義の両方でパスを使用する ExternalSecret を移行することはできない

ExternalSecret の data および dataFrom フィールドは、外部シークレットストアから取得するデータを指定します。 これにパスが含まれている場合、そのパスは特定のプロバイダや環境設定に依存します。 従って、一律の変換が困難であり、手動での移行と確認が必要となります。

  • 適切な SecretStores を自動的に生成することはできない

SecretStore は、外部シークレットストアへの接続設定を含む Kubernetes リソースです。 プロバイダ毎の認証情報や各種権限の設定は個別に対応する必要があるため、SecretStore を自動的に生成することは困難です。

例えば、AWS Secrets Manager や GCP Secret Manager 等、各プロバイダには異なる設定が求められます。 自動生成された SecretStore には値の確認や権限設定等、詳細な確認と手動作業が必要です。 kestoeso スクリプトはこれを補助しますが、最終的なセットアップは手動で行う必要があります。

まとめ

今回のブログでは、KES の非推奨化が発表されたため、後継ツールとして特に注目を集めている ESO とその移行手順について紹介しました。

ESO は、KES との互換性を維持しつつ、新たに Go でリファクタリング実装された OSS となっています。 他のツールと比較すると、移行コストの面や既存構成との親和性の観点から非常に優れており、今後は ESO がデファクトスタンダード化していくと考えられます。

参考・引用