#docker #kubernetes #kubernetes-secrets
#docker #kubernetes #kubernetes-секреты
Вопрос:
В настоящее время я переношу свое развертывание docker на манифесты k8s, и мне было интересно узнать об обработке секретов. В настоящее время мой контейнер docker извлекает /run/secrets/app_secret_key, чтобы получить конфиденциальную информацию внутри контейнера как env var. но имеет ли это какое-либо преимущество по сравнению с обработкой секретов k8s, поскольку, с другой стороны, я также могу сделать что-то подобное в моем manifest.yaml:
env:
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-password
key: password
который затем напрямую переносит секрет в виде переменной env внутри контейнера…
Единственное отличие, которое я смог заметить, это то, что если я извлекаю / запускаю / secrets / app_secret_key внутри контейнера следующим образом (docker-entrypoint.sh ):
export APP_SECRET_KEY="$(cat /run/secrets/app_secret_key)"
переменная env не отображается, когда я получаю доступ к контейнеру после развертывания, кажется, что переменная env доступна только на «сеансе», где docker-entrypoint.sh запускается изначально (при запуске контейнера / модуля).
Итак, теперь мой вопрос заключается в том, что здесь имеет больше смысла: просто используйте инструкцию env:, показанную выше, или оставайтесь с ручной выборкой / run / secrets / app_secret_key внутри контейнера…
Заранее спасибо
Комментарии:
1. Сложно для себя: в конце концов, не должно иметь значения, загружаю ли я секреты тем или иным способом, даже если злоумышленник каким-то образом использует контейнер, или они смогут получить доступ к run / secrets / app_secret_key. Похоже, нет никакой разницы, за исключением того, что секрет не раскрывается напрямую при вызове printenv, если он загружен из /run/secrets/app_secret_key, как показано выше…
Ответ №1:
Честно говоря, оба варианта — это разные реализации одного и того же, вы можете выбрать любой из них, но я предпочту, чтобы kubernetes approch был секретным для монтирования, чем чтение контейнера во время выполнения просто из-за видимости.
Не имеет значения, если вы ищете один контейнер, но когда у нас более 30-40 микросервисов, работающих в среде 4-5 , и у нас есть около 100 или даже 200 секретов. В этом случае одно развертывание идет не так, мы можем посмотреть манифест развертывания и определить все приложение. Нам не нужно искать файл docker, чтобы понять, что происходит.
Комментарии:
1. true stroy, наткнулся на ту же проблему и удалил все мои реализации извлечения секретов… лень все еще выше кустарной работы : D
Ответ №2:
Раскрытие secret как env var или file — это просто вариант использования secret способом k8s.
Некоторые секреты, такие как пароль, представляют собой строку длиной всего в одну строку, поэтому ее удобно использовать как env var. Другой секрет, такой как закрытый ключ ssh или сертификат TLS, может быть многострочным, поэтому вместо этого вы можете смонтировать секрет как том.
Тем не менее, рекомендуется объявлять ваш секрет как секретные ресурсы k8s. Таким образом, вы можете получить необходимое значение через kubectl, не заходя внутрь контейнера. Вы также можете создать шаблон, подобный helm chart, который генерирует секретные манифесты при развертывании. С помощью RBAC вы также можете контролировать, кто может читать секретные манифесты.
Согласно вашим комментариям, да, любой пользователь, который может зайти внутрь контейнера, будет иметь доступ к ресурсу, доступному пользователю оболочки.