Как установить секретные файлы в секреты кубернетов по yaml?

Ответ 1

При использовании формата CLI в основном вы используете генератор yaml перед отправкой его на сервер.

Так как Kubernetes является клиент-серверным приложением с REST API между ними, а действия должны быть атомарными, опубликованный YAML должен содержать содержимое файла, а лучший способ сделать это - вставить его в качестве формата base64 в очереди. Было бы неплохо, если бы файл мог быть встроен в другое место (возможно, для создания границ файла можно использовать отступы), но до сих пор я не видел таких примеров.

Считая, что размещение ссылки на файл yaml невозможно, нет никакой предпродажной рендеринга yaml для включения содержимого.

Ответ 2

Как указано в предыдущем сообщении, нам необходимо предоставить сертификат/ключ, закодированный как base64, в файл.

Вот общий пример для сертификата (в данном случае 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

Ответ 3

Вы можете использовать secode для замены секретных значений строками с кодировкой base64, просто выполнив следующие действия:

secode secrets.yaml > secrets_base64.yaml

Он кодирует все поля data и работает с несколькими секретами (kind:Secret) в yaml файле yaml, если он определен в списке (kind: List).

Отказ от ответственности: я автор

Ответ 4

Поэтому я только что узнал о супер полезном фундаментале k8s, который пропустил, а затем обнаружил, что с ним связана уязвимость безопасности, и пришел к решению.

TL;DR:
Вы можете иметь в своем секретном репозитории многострочные строки/текстовые файлы с открытым текстом в виде secret.yaml !!! :)
(Примечание. Я рекомендую сохранить это в Hashicorp Vault, вы можете хранить версионные конфигурационные файлы, которые имеют секреты, и легко просматривать/редактировать их через веб-страницу хранилища, и в отличие от git-репо, вы можете иметь точный контроль доступа к зерну, конвейеры могут использовать 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 получить секретные 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 создает секретные универсальные настройки приложений - -f rom -f ile appsettings.Dummy.json - -n amespace = api

Примечание 2: Еще одна причина отдать предпочтение декларативному appsettings-secret.yaml, заключается в том, что при редактировании kubectl apply -f настроит секрет, но если вы запустите эту команду create, она скажет, что ошибка уже существует, и вы получите чтобы удалить его, прежде чем он позволит вам снова запустить команду создания.

Примечание 3. Причина, по которой kubectl создает секретное универсальное имя - -f из -f файла ile - -n amespace/причина против secret.yaml, заключается в том, что kubectl show secret не будет показывать вам последний раз, когда секрет был отредактирован. Как и в случае с командой create, поскольку вы должны удалить ее до того, как сможете воссоздать ее, вы узнаете, когда она последний раз редактировалась, исходя из того, как долго она существовала, так что это хорошо для пробного аудита. (Но есть и лучшие способы аудита)

kubectl apply -f cleartext-appsettings-secret.yaml
kubectl аннотировать секретные наборы приложений -n = api kubectl.kubernetes.io/last-applied-configuration-
kubectl получить секретные 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

Ответ 5

Для пользователей Windows в комнате используйте это для каждого из.cer и.key (пример показывает, что.key закодирована для вставки в файл YAML):

$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 файл и вставьте (одну строку) вывод в свой файл YAML - имейте в виду, что при проверке файла YAML на репозиторий исходного кода с этой информацией в нем ключ будет эффективно скомпрометирован, поскольку base64 isn ' t.

Ответ 6

Вы можете использовать --dry-run flag для подготовки 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