web-dev-qa-db-ja.com

yamlで秘密ファイルをkubernetes秘密に設定する方法は？

Kubernetes Secretsにファイルを保存したいのですが、yamlファイルを使用してファイルを保存する方法が見つかりません。

kubectlでcliを使用して作成できました：

kubectl create secret generic some-secret --from-file=secret1.txt=secrets/secret1.txt

しかし、yamlで似たようなことをしようとすると：

apiVersion: v1
kind: Secret
metadata:
  name: some-secret
type: Opaque
data:
  secret1.txt: secrets/secret1.txt

私はこのエラーを持っています：

[pos 73]: json: error decoding base64 binary 'assets/elasticsearch.yml': illegal base64 data at input byte 20

このガイドに従っています http://kubernetes.io/docs/user-guide/secrets/ 。 yamlを使用してシークレットを作成する方法を説明しますが、yamlを使用してfileからシークレットを作成する方法は説明しません。 。

出来ますか？もしそうなら、どうすればいいですか？

kubernetesyamlkubernetes-secrets
25
dgil

CLI形式を使用する場合、基本的にはサーバー側に投稿する前にyamlのジェネレーターを使用しています。

Kubernetesは、REST APIを中間に持つクライアントサーバーアプリケーションであり、アクションはアトミックである必要があるため、投稿されたYAMLにはファイルのコンテンツを含める必要があります。 base64形式としてインラインで埋め込みます。ファイルを別の方法で埋め込むことができればいいのですが（インデントを使用してファイルの境界を作成できます）、これまでそのような例を見たことはありません。

ただし、yamlにファイル参照を配置することはできません。コンテンツを含めるためのyamlのプリフライトレンダリングはありません。

9
Dimitris

前の投稿で回答したように、based64としてエンコードされた証明書/キーをファイルに提供する必要があります。

証明書（この場合はSSL）の一般的な例を次に示します。

secret.yml.tmpl：

    apiVersion: v1    

    kind: Secret
    metadata:
         name: test-secret
         namespace: default
    type: Opaque
    data:
        server.crt: SERVER_CRT
        server.key: SERVER_KEY

ファイルを前処理して、証明書/キーを含めます。

sed "s/SERVER_CRT/`cat server.crt|base64 -w0`/g" secret.yml.tmpl | \
sed "s/SERVER_KEY/`cat server.key|base64 -w0`/g" | \
kubectl apply -f -

証明書/キーは、空白なしのbase64（-w0）を使用してエンコードされることに注意してください。

TLSの場合は単純に次のようになります。

kubectl create secret tls test-secret-tls --cert=server.crt --key=server.key
26
aitorhh

--dry-runフラグを使用して、ファイルのデータを含むYAMLを準備できます。

kubectl create secret generic jwt-certificates --from-file=jwt-public.cer --from-file=jwt-private.pfx --dry-run=true  --output=yaml > jwt-secrets.yaml
5
szogun1987

secode を使用して、秘密の値をbase64エンコードされた文字列に置き換えることができます。

secode secrets.yaml > secrets_base64.yaml

すべてのdataフィールドをエンコードし、リスト（kind:Secret）で定義されている場合、yamlファイルごとに複数のシークレット（kind: List）を処理します。

免責事項：私は著者です

2
mayr

ルームのWindowsユーザーの場合、.cerおよび.keyのそれぞれにこれを使用します（例は、YAMLファイルへの挿入用にエンコードされた.keyを示しています）。

$Content = Get-Content -Raw -Path C:\ssl-cert-decrypted.key

[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Content)) | Out-File -FilePath C:\ssl-cert-decrypted.key.b64

新しい.b64ファイルを開き、（1行）出力をYAMLファイルに貼り付けます-この情報を含むソースコードリポジトリにYAMLファイルをチェックインすると、キーが効果的に侵害されることに注意してくださいbase64は暗号化ではありません。

0
Lewis

それで、私は見逃した非常に便利なk8sの基本を学びました。そして、それに関連するセキュリティ脆弱性があることを発見し、解決策を考え出しました。

TLDR：
シークレットリポジトリにsecret.yamlとしてクリアテキストの複数行文字列/テキストファイルを含めることができます!!!：）
（注：これをHashicorp Vaultに保存することをお勧めします。秘密のバージョン管理された構成ファイルを保存し、ボールトWebページから簡単に表示/編集できます。また、gitリポジトリとは異なり、きめ細かいアクセス制御が可能です。パイプラインはREST APIを使用して、更新されたシークレットをプルすることができます。これにより、パスワードローテーションも簡単になります。

cleartext-appsettings-secret.yaml
appsettings.Dummy.jsonはデフォルトのファイル名（秘密の鍵）です
（yamlマウントで上書きできるように、Wordのデフォルトのファイル名を使用します）
そしてクリアテキストjsonコードはファイルの内容（シークレットの値）です

apiVersion: v1
kind: Secret
metadata:
  name: appsettings
  namespace: api
type: Opaque
stringData:
  appsettings.Dummy.json: |-
    {
      "Dummy": {
        "Placeholder": {
          "Password": "blank"
        }
      }
    }

私が
kubectl apply -f cleartext-appsettings-secret.yaml
kubectl get secret appsettings -n = api -o yaml
秘密は注釈に平文を表示します...

apiVersion: v1
data:
  appsettings.Dummy.json: ewogICJEdW1teSI6IHsKICAgICJQbGFjZWhvbGRlciI6IHsKICAgICAgIlBhc3N3b3JkIjogImJsYW5rIgogICAgfQogIH0KfQ==
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{},"name":"appsettings","namespace":"api"},"stringData":{"appsettings.Dummy.json":"{\n  \"Dummy\": {\n    \"Placeholder\": {\n      \"Password\": \"blank\"\n    }\n  }\n}"},"type":"Opaque"}
  creationTimestamp: 2019-01-31T02:50:16Z
  name: appsettings
  namespace: api
  resourceVersion: "4909"
  selfLink: /api/v1/namespaces/api/secrets/appsettings
  uid: f0629027-2502-11e9-9375-6eb4e0983acc


明らかに、注釈に表示される秘密を作成するために使用されるyamlは、2016 /バグレポートとして投稿されて以来、kubectl apply -f secret.yamlの予想される動作ですが、問題は解決せずに解決しました/無視しますそれ対修正。

オリジナルのsecret.yamlがbase64の場合、アノテーションは少なくともbase64になりますが、このシナリオでは、base64に対応していない人間が読めるクリアテキストです。

注1：秘密の秘密の作成では発生しません
kubectl create secret generic appsettings --from-file appsettings.Dummy.json --namespace = api

注2：宣言的なappsettings-secret.yamlを使用するもう1つの理由は、kubectl apply -fが編集するときにシークレットを構成するが、そのcreateコマンドを実行するとエラーが既に存在すると言うため、 createコマンドを再度実行する前に削除してください。

注3：kubectl create secret generic name --from-file file --namespace/secret.yamlに対する理由は、kubectl show secretが最後にシークレットが編集された時間を表示しないことです。 createコマンドの場合と同じように、再作成する前に削除する必要があるため、存在する期間に基づいて最後に編集された日時がわかるので、監査トライアルに適しています。 （しかし、監査のより良い方法があります）

kubectl apply -f cleartext-appsettings-secret.yaml
kubectlアノテーションシークレットアプリ設定-n = api kubectl.kubernetes.io/last-applied-configuration-
kubectl get secret appsettings -n = api -o yaml
リークに対抗する

apiVersion: v1
data:
  appsettings.Dummy.json: ewogICJEdW1teSI6IHsKICAgICJQbGFjZWhvbGRlciI6IHsKICAgICAgIlBhc3N3b3JkIjogImJsYW5rIgogICAgfQogIH0KfQ==
kind: Secret
metadata:
  creationTimestamp: 2019-01-31T03:06:55Z
  name: appsettings
  namespace: api
  resourceVersion: "6040"
  selfLink: /api/v1/namespaces/api/secrets/appsettings
  uid: 43f1b81c-2505-11e9-9375-6eb4e0983acc
type: Opaque
0
neokyle