如何通过yaml将秘密文件设置为kubernetes的秘密？

Question

我想在Kubernetes Secrets中存储文件,但我还没有找到如何使用yaml文件来完成它.

我已经能够使用cli来实现kubectl:

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/.它解释了如何使用a yaml而不是如何使用文件创建秘密来创建秘密yaml.

可能吗？如果是这样,我该怎么办？

Answer 1

正如前一篇文章所述,我们需要提供编码为based64的证书/密钥到文件中.

以下是certiticate的通用示例(在本例中为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

Answer 2

在使用CLI格式时,基本上你使用yaml的生成器,然后将其发布到服务器端.

由于Kubernetes是客户端 - 服务器应用程序,其中包含REST API,并且操作需要是原子的,因此发布的YAML需要包含文件的内容,最好的方法是将其作为base64格式嵌入到内联中.如果文件可以以其他方式嵌入会很好(缩进可能用于创建文件的边界),但直到现在我还没有看到任何这样的例子.

话虽如此,在yaml上放置文件引用是不可能的,没有yaml的pre-flight呈现以包含内容.

Answer 3

您可以使用--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

Answer 4

所以我刚刚学习了一个我错过的超级有用的 k8s 基础，然后发现它有一个与之相关的安全漏洞，并想出了一个解决方案。

TLDR：
您可以将明文多行字符串/文本文件作为 secret.yaml 在您的秘密仓库中！！！:)
（注意我建议将其存储在 Hashicorp Vault 中，您可以存储具有机密的版本化配置文件，并通过 Vault 网页轻松查看/编辑它们，并且与 git repo 不同，您可以进行细粒度访问控制，管道可以使用REST API 来提取更新的秘密，这也使密码轮换变得很容易。）

cleartext-appsettings-secret.yaml
appsettings.Dummy.json 是默认文件名（密钥的密钥）
（我使用单词默认文件名，因为您可以在 yaml 挂载中覆盖它）
并且明文 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 是 kubectl apply -f secret.yaml 自 2016 年以来的预期行为/已作为错误报告发布，但问题未解决而关闭/他们忽略它而不是修复它。

如果您是原始的 secret.yaml 是 base64 的，则注释至少是 base64 的，但在这种情况下，它直接是非 base64 的人类可读明文。

注意1：命令式秘密创建不会发生
kubectl create secret generic appsettings --from-file appsettings.Dummy.json --namespace=api

注意 2：支持声明性 appsettings-secret.yaml 的另一个原因是，当需要编辑时 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 annotate secret appsettings -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