Задача падала ещё до обращения к S3, на разборе конфигурации:
pydantic ValidationError for S3AccountModel
Value error, Expecting value: line 1 column 1 (char 0)
ValueError: SERVICE_S3 is not valid
"Expecting value ... char 0" — это разбор пустоты: файла по пути не было.
Секрет secrets/minio/apps/processing из Vault при этом настроен верно, и
движок его видит (S3_SERVICE_ACCOUNT=/vault/secrets/processing-s3). Но в
поды задач движок его НЕ передаёт — для них у него отдельный механизм,
зашитый в код:
services[S3Storage] = Service{
CredentialsName: "yc-s3",
CredentialsPath: "/etc/sarex/yc-s3",
Envs: {"SERVICE_S3": `{"service_account":
"/etc/sarex/yc-s3/yc-s3-service-account.json"}`},
}
(pkg/kube_services/services.go)
То есть он монтирует в Job обычный Secret с именем yc-s3 из namespace
задач (JOBS_NAMESPACE=processing). Ни имя секрета, ни путь, ни имя файла
не настраиваются.
vault-agent сюда не дотягивается по построению: поды задач движок создаёт
сам во время работы, аннотаций инжекции у них нет. Поэтому секрет заводит
ansible — tasks/app-secrets.yml, шаблон app-secrets.yaml.j2 и описание в
k8s_file_secrets. Формат содержимого повторяет
engine/yc-s3-service-account.json из compose-стека и совпадает с тем, что
vault-agent рендерит самому движку.
Манифест рендерится, применяется и сразу удаляется — в нём креды открытым
текстом, ровно как у секретов реестра. Namespace объявлен в том же
манифесте: на холодном старте Flux до слоя apps ещё не дошёл, а apply в
несуществующий namespace упал бы. Повторное создание безвредно, так же
заведён namespace vault.
65 lines
2.9 KiB
YAML
65 lines
2.9 KiB
YAML
---
|
||
# Секреты-файлы для подов, которые создаёт не Flux, а сам движок workflows.
|
||
#
|
||
# ЗАЧЕМ ОТДЕЛЬНО ОТ VAULT. Приложения контура получают креды аннотациями
|
||
# vault-agent — но это работает только для подов, чей шаблон мы описываем.
|
||
# Поды задач создаёт workflows-engine во время работы, аннотаций у них нет, и
|
||
# единственное, что он умеет подключить, — обычный Secret из namespace задач:
|
||
#
|
||
# services[S3Storage] = Service{
|
||
# CredentialsName: "yc-s3",
|
||
# CredentialsPath: "/etc/sarex/yc-s3",
|
||
# Envs: {"SERVICE_S3": `{"service_account":
|
||
# "/etc/sarex/yc-s3/yc-s3-service-account.json"}`},
|
||
# }
|
||
# (pkg/kube_services/services.go)
|
||
#
|
||
# Имя секрета, путь монтирования и имя файла зашиты в код движка — поменять их
|
||
# нельзя, можно только положить секрет ровно с такими именами.
|
||
#
|
||
# Без него задача падает не на доступе к S3, а на разборе конфигурации:
|
||
# pydantic_core.ValidationError: 1 validation error for S3AccountModel
|
||
# Value error, Expecting value: line 1 column 1 (char 0)
|
||
# ValueError: SERVICE_S3 is not valid
|
||
# то есть файл по пути просто отсутствует и читается как пустая строка.
|
||
#
|
||
# Как и у секретов реестра: манифест рендерится, применяется и сразу
|
||
# удаляется — в нём креды в открытом виде.
|
||
|
||
- name: Отрендерить манифест секретов-файлов
|
||
ansible.builtin.template:
|
||
src: app-secrets.yaml.j2
|
||
dest: "{{ deploy_dir }}/k3s/app-secrets.yaml"
|
||
owner: root
|
||
group: root
|
||
mode: "0600"
|
||
no_log: true
|
||
tags: [appsecrets]
|
||
|
||
# ./k3s смонтирован в k3s-server как /output — отсюда и путь.
|
||
- name: Применить секреты-файлы в кластере
|
||
ansible.builtin.command:
|
||
argv:
|
||
- "{{ compose_cmd.split()[0] }}"
|
||
- compose
|
||
- exec
|
||
- "-T"
|
||
- k3s-server
|
||
- kubectl
|
||
- apply
|
||
- "-f"
|
||
- /output/app-secrets.yaml
|
||
chdir: "{{ deploy_dir }}"
|
||
register: app_secret_apply
|
||
changed_when: >-
|
||
'created' in app_secret_apply.stdout or
|
||
'configured' in app_secret_apply.stdout
|
||
tags: [appsecrets]
|
||
|
||
# Удаляем всегда, в том числе если apply упал: файл содержит креды.
|
||
- name: Удалить манифест секретов-файлов с хоста
|
||
ansible.builtin.file:
|
||
path: "{{ deploy_dir }}/k3s/app-secrets.yaml"
|
||
state: absent
|
||
tags: [appsecrets]
|