Helm でのシークレットの自動生成

Helm でのシークレットの自動生成

チーム Mail.ru の Kubernetes aaS 短いメモを翻訳しました 更新時に Helm シークレットを自動的に生成する方法について。 以下は、SaaS ソリューションを開発する会社である Intoware のテクニカル ディレクターである記事の著者からのテキストです。

コンテナってかっこいいですね。 最初は私もコンテナに反対していましたが (恥ずかしいことに)、今ではこのテクノロジーの使用を全面的に支持しています。 これを読んでいるあなたは、Docker の海を無事に乗り越え、Kubernetes の利点を認識し、Helm を使用して作業をはるかに楽にしたことを願っています。

ただし、明らかに必要以上に難しいものもあります。

更新時にシークレットを自動的に生成するにはどうすればよいですか?

Kubernetes シークレットは、コードで使用するキーと値のペアを含むリソースです。 これらは、データベース接続文字列、電子メール パスワードなどです。 シークレットを使用すると、コードと設定が明確に分離され、コードベースを変更せずにさまざまなデプロイメントを簡単にカスタマイズできるようになります。

一般的な状況は、XNUMX つのモジュールが共通のキーを使用して通信する必要がある場合です。 このキーはクラスター内での XNUMX 対 XNUMX 通信を目的としているため、クラスター外の誰もこのキーを知る必要はありません。

秘密を作る

通常、Helm でシークレットを作成するには、次のことを行う必要があります。

  • 値ファイルに秘密を記述します。
  • 導入時に再定義します。
  • デプロイメント/ポッド内でそれを参照します。
  • ... 利益!

通常は次のようになります。

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ .Values.MyApiKeySecret | quote }}

value.yml の値を使用した単純な Kubernetes シークレット

ただし、値ファイルにシークレットを指定したくないとします。

導入に共有キーが必要な場合は、多くのオプションがあります。共有キーはインストール中に生成する必要があります。

上記のモジュール間通信の例では、展開の外部で秘密を共有することは望ましくありません。 したがって、Helm には、シークレットを直接指定せずに自動的にシークレットを生成するメカニズムがあることが非常に望ましいです。

フック

フックを使用すると、インストール プロセス中に特定の場所でコードを実行できます。 最初のインストール後に実行する必要がある構成ジョブがある場合や、更新を実行する前にクリーンアップを実行する必要がある場合があります。

インストール中に生成されるキーを追加するという問題を解決するには、プレインストール フックが理想的です。 ただし、落とし穴があります。更新時に一度だけシークレットを自動的に生成することはできません。 フックはすべての更新で機能します。

シークレットを生成し、最初のインストールがまだ行われていない場合は、読むのをやめてください。プレインストール フックは非常に役に立ちます。

しかし、シークレットがアップデートの一部である場合 (おそらく、インストール時には存在しなかった新機能)、一度だけ機能するプレインストール フックを作成できないのは残念です。

機能

Helm 関数を使用すると、さまざまなスクリプト要素をデプロイメント スクリプトに追加できます。

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generate a new UUID and quote it

この例は、apiKey シークレットの値が、インストール中に生成された新しい UUID になることを示しています。

Helm には、驚くべき GO テンプレート機能と Sprig の機能ライブラリを活用してカスタム デプロイメントを作成する、真に広範な機能ライブラリが含まれています。

ルックアップ関数

Helm 3.1 で追加 ルックアップ関数これにより、既存のデプロイメントをリクエストできるようになり、次のことが可能になります。

  • リソースの存在を確認します。
  • 後で使用できるように既存のリソースの値を返します。

これらの機能の両方を使用すると、動的に生成される XNUMX 回限りのシークレットを作成できます。

# 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}}
apiVersion: v1
kind: Secret
metadata:
  name: some-awesome-secret
type: Opaque

# 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data")
{{ if $secret -}}
data:
  apiKey: {{ $secret.data.apiKey }}

# 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)!
{{ else -}}
stringData:
  apiKey: {{ uuidv4 | quote }}
{{ end }}

新しい更新がサーバーに適用されるたびに、Helm は新しいシークレット値を生成するか (まだシークレットがない場合)、既存の値を再利用します。

グッドラック!

このトピックに関して他に何を読むべきか:

  1. Kubernetes の XNUMX つのレベルの自動スケーリングとそれらを効果的に使用する方法.
  2. 著作権侵害の精神を備えた Kubernetes と実装用のテンプレート.
  3. Telegram の Kubernetes に関する私たちのチャンネル.

出所: habr.com

コメントを追加します