Как вы храните секретные переменные (например, пароли, API-ключи) в DevOps-практиках?

Слушай, а вот эта тема с секретами в DevOps — это вообще отдельный вид искусства, иногда с элементами цирка. Представь: пишешь ты код, всё красиво, а потом какой-нибудь распиздяй заливает в репозиторий файлик .env с паролями от продакшена. И всё, приехали. Теперь можно рассылать резюме, потому что проект накрылся медным тазом, а тебя выперли с позором. Удивление пиздец, да? Так вот, чтобы такого не было, есть целая куча способов не выносить себе мозг.

1. Специальные сервисы — типа сейфов, но для кода.

• HashiCorp Vault: Это, бля, царь-пушка. Там и секреты динамические, и шифрование, и можно настроить так, что доступ будет только по нужному времени и с нужного IP. Овердохуища возможностей, но и разобраться надо.
• Встроенные штуки в облаках: AWS Secrets Manager, Azure Key Vault. Удобно, если всё живёт в одном облаке. Прилепил — и работает. Но если уйдешь с этого облака, будет тебе хиросима и нигерсраки с миграцией.

2. Как это в Kubernetes прикрутить. Там есть свои встроенные Secrets, но это, простите, манда с ушами. Они просто в base64, это не шифрование! Любой, кто имеет доступ к кластеру, их вытащит. Доверия ебать ноль. Поэтому их всегда используют с чем-то поверх:

• SealedSecrets: Шифруешь секрет на своей машине, а в Git летит уже эта зашифрованная каша. Расшифровать может только твой K8s. Красота.
• External Secrets Operator: Эта мартышлюшка просто тащит секреты из того же Vault или AWS прямо в кластер. Не хранит ничего, только синхронизирует.
• Ну и etcd (это где K8s всё хранит) сам по себе должен быть зашифрован. Иначе — пидарас шерстяной получит все ключи.

3. В CI/CD пайплайнах. В том же GitLab или GitHub есть специальные protected/masked переменные. Засунул туда пароль, и он ни в логах не светится, никому не доступен. Главное — не забыть их туда засунуть, а не в код.

Вот, смотри, как это по-простому выглядит в Kubernetes:

# Делаем секрет из пары ключ-значение прямо в консоли
kubectl create secret generic app-db-cred 
  --from-literal=username=prod_user 
  --from-literal=password='S3cr3tP@ss!'

# Или из файла (например, сертификат)
kubectl create secret generic tls-cert --from-file=./tls.crt

А вот как этот секрет потом в поде использовать. Либо как переменные окружения, либо как файлы смонтировать.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    env:
      - name: DB_USERNAME
        valueFrom:
          secretKeyRef:
            name: app-db-cred
            key: username
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: app-db-cred
            key: password
    volumeMounts:
    - name: cert-volume
      mountPath: /etc/ssl/certs
  volumes:
  - name: cert-volume
    secret:
      secretName: tls-cert

И главные правила, которые надо выжечь себе на подкорке:

• В репу — ни-ни! Никаких .env файлов, даже если они в .gitignore. Один раз забудешь — и всё, пизда рулю. Только специализированные хранилища.
• Принцип «дай минимум»: Каждому сервису — только те секреты, без которых он сдохнет. Не больше.
• Ключи должны меняться. Пароль, который не менялся пять лет — это хуй с горы, а не секрет. Настраивай автоматическую ротацию.
• Всё должно логироваться. Кто, когда и к какому секрету прикоснулся. Чтобы если что — знать, какого хуя и кто виноват.

В общем, чувак, секреты — это серьёзно. Сделаешь на авось — потом будешь ебись оно конё и разгребать последствия. Лучше сразу настроить как надо.