Назад | Перейти на главную страницу

Как обеспечить одинаковый ключ подов в Kubernetes?

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

На данный момент все модули должны иметь один и тот же закрытый ключ. Например:

Мы хотели бы найти способ в Kubernetes, чтобы обеспечить работоспособность модуля для этого модуля, имеющего тот же закрытый ключ, что и для других модулей. Я понимаю, что это может создать ситуацию смертельной спирали, если это не удастся, но это нормально. Мы выполняем сине-зеленое развертывание, поэтому живой трафик никогда не будет переключаться на дегенеративное развертывание, пока он не будет запущен и запущен.

Моя текущая мысль состоит в том, чтобы написать сценарий, который запускается как зонд живучести, который сравнивает контрольную сумму файла закрытого ключа с контрольными суммами всех других модулей, извлекая список родственных модулей из внутренних API Kubernetes.

Это мотивировано случаем, когда политика извлечения изображений была установлена ​​на IfNotPresent а затем изображение с тем же тегом обновлялось между развертываниями модулей, поэтому мы прекратили работу службы, потому что разные закрытые ключи находились в разных местах. Очевидно, мы могли бы добавить проверку этого в наш контрольный список развертывания, но если есть способ автоматизировать применение политики с помощью фактического инструмента развертывания, я чувствую, что это было бы сильнее.

Я также готов поверить в то, что такой подход, когда несколько модулей должны иметь один и тот же ключ, по какой-то причине является неправильным. Если есть лучший способ достичь этой цели, это тоже будет полезным ответом на этот вопрос.

Для этого сделаны секреты:

Kubernetes secret объекты позволяют хранить и управлять конфиденциальной информацией, такой как пароли, токены OAuth и ключи ssh. Помещая эту информацию в secret безопаснее и гибче, чем дословно в Стручок определение или в изображение контейнера. Видеть Секреты оформления документа Чтобы получить больше информации.

Как Создайте секреты:

Создание секрета с помощью kubectl create secret

Скажем, некоторым модулям требуется доступ к базе данных. Имя пользователя и пароль, которые должны использовать модули, находятся в файлах. ./username.txt и ./password.txt на вашем локальном компьютере.

# Create files needed for rest of example.
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt

В kubectl create secret команда упаковывает эти файлы в секрет и создает объект на Apiserver.

kubectl create secret generic db-user-pass --from-file=./username.txt --from file=./password.txt

secret "db-user-pass" created

Как использовать секреты:

Использование секретов

Секреты могут быть смонтированы как тома данных или представлены как переменные среды для использования контейнером в контейнере. Они также могут использоваться другими частями системы, не подвергаясь непосредственному воздействию модуля. Например, они могут содержать учетные данные, которые другие части системы должны использовать для взаимодействия с внешними системами от вашего имени.

Использование секретов как файлов из модуля

Чтобы использовать секрет в томе в модуле:

  1. Создайте секрет или используйте существующий. Несколько модулей могут ссылаться на один и тот же секрет.
  2. Измените определение Pod, чтобы добавить том под .spec.volumes[]. Назовите том как угодно и поставьте .spec.volumes[].secret.secretName поле, равное имени секретного объекта.
  3. Добавить .spec.containers[].volumeMounts[] каждому контейнеру, которому нужен секрет. Уточнить .spec.containers[].volumeMounts[].readOnly = true и .spec.containers[].volumeMounts[].mountPath к неиспользуемому имени каталога, в котором вы хотели бы разместить секреты.
  4. Измените изображение и / или командную строку, чтобы программа искала файлы в этом каталоге. Каждый ключ в секрете data карта становится именем файла под mountPath.

Это пример модуля, который монтирует секрет в том:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

Обратите внимание, что секреты находятся в пространстве имен. На них могут ссылаться только модули в том же пространстве имен. Полный список ограничений находится Вот.