Kubernetes ConfigMap および Secret 生成器

データ開発者安全

[iotools_kubernetes_configmap_secret_generator]

ガイド

Kubernetes ConfigMap および Secret 生成器

KubernetesのConfigMapおよびSecretのマニフェストをKEY=valueペアのシンプルなリストから構築します。生成器はリソース名をRFC 1123に従って検証し、Secretの値をbase64エンコードして、そのままYAMLに変換し、それを直ちにパイプで使用できます。ブラウザ外にデータが送出されません。 data フィールド kubectl apply -f -。データはブラウザに留まり、アップロードやログ記録、送信されることはありません。

使用方法

リソースタイプを選択してください： ConfigMap 非機密な設定用に、または秘密認証情報、トークン、および証明書用に。
小文字のリソース名（RFC 1123）と、オプションでネームスペースを入力してください。
Secretの場合、秘密タイプ（Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls、など）を選択し、値を自動base64エンコード（data:）するか、またはそのまま保持（stringData:).
）を選択してください。 KEY=value 1行ごとにキー/値ペアを貼り付けます。必要であればラベルやアノテーションも追加してください。
生成されたYAMLをコピーするか、または .yaml ファイルとしてダウンロードして、すぐに kubectl apply.

機能

ConfigMapおよびSecretを1つのツールで構築します。 – リソースタイプの切り替えを行っても、入力データは失われません。
自動base64エンコード – Secretの値はフルUTF-8サポートによりエンコードされ、パスワードや非ASCII文字を含むトークンが正確に送受信されます。
stringDataモード – 人間が編集可能なマニフェストを必要とする場合、エンコードをスキップします。Kubernetesは適用時に自動でbase64エンコードします。
すべての標準的なSecretタイプ – Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-authと、 kubernetes.io/service-account-token.
リアルタイムRFC 1123検証 – 名前、ネームスペース、データキーの無効なものを事前に検出し、 kubectl apply 拒否します。
ラベル、アノテーション、および不可変フラグ – メタデータを追加し、変更されないべきリソースに対して不可変フラグを有効にします。
スマートYAMLクォート – 数値、ブール値、または特別な文字を含む値は自動的にクォートされ、複数行の値はブロックスケーラーを使用します。
100%クライアントサイド – キーと値はブラウザに留まり、アップロード、ログ記録、送信されることはありません。

 よくある質問

KubernetesにおけるConfigMapとSecretの違いは何ですか？

ConfigMapは非機密な設定をプレーンなキー/値ペアとして保存し、Secretは認証情報、トークン、その他の機密データに適しています。Secretの値はbase64エンコードされ、Kubernetesはそれらをより厳しい権限でマウントし、暗号化済みデータプロバイダーとの統合や、特定のノードにのみ配布できるようにします。
KubernetesのSecret値がbase64エンコードされているのはなぜですか？

base64エンコードにより、バイナリデータがYAML/JSON内に安全に移動し、構造が破壊されたり無効な文字が生成されないようになります。これは暗号化ではありませんので、クラスタAPIにアクセスできる誰もが値を解読できます。本物の保護はRBAC、暗号化済みデータ、およびログ監視に依存します。
ConfigMapまたはSecretを不可変にするべきタイミングは？

変更を予見しない場合や、大きなクラスタでkubeletの負荷を減らしたい場合に、ConfigMapまたはSecretを不可変にマークします。不可変リソースはウォッチベースのリフレッシュをスキップし、kubeletは定期的なGETを停止します。代わりに、値を変更するにはリソースを削除して再作成する必要があります。
SecretマニフェストにおけるdataとstringDataの違いは？

dataフィールドにはbase64エンコードされた値が必須であり、APIサーバーはそれらをそのまま保存します。stringDataフィールドにはプレーンなUTF-8文字列が受け入れられ、APIサーバーは作成または更新時に自動でbase64エンコードします。どちらも存在する場合、keyが重複する場合はstringDataが優先されます。手動でSecretを構築する場合はstringDataを使用し、既存のツールがエンコード済みである場合はdataを使用します。