Кубернетес — секреты

Предварительное условие: - Kubernetes

Kubernetes — это система оркестрации контейнеров с открытым исходным кодом, которая в основном используется для автоматического развертывания, управления и масштабирования программного обеспечения. Kubernetes также известен как K8s. Kubernetes изначально был разработан Google, но теперь поддерживается Cloud Native Computing Foundation. Первоначально он был разработан для взаимодействия только со средой выполнения Docker, но теперь он также работает с контейнерами и CRI-O. Основная цель Kubernetes — автоматизировать операционные задачи управления контейнерами. Он включен со встроенными командами для развертывания приложений и внесения необходимых изменений в приложение. В настоящее время его используют такие компании, как Google, Spotify и Capital One.

Секреты:

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

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

1. Секреты можно использовать как переменную среды контейнера.
2. Как файл в томе, смонтированном хотя бы в одном из его контейнеров.
3. Kubelet может использовать его при извлечении изображений из модуля.
4. Секреты также используются плоскостью управления Kubernetes.

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

• Секреты могут быть представлены как переменные среды для использования контейнером в поде или могут быть смонтированы как тома данных. Он даже может использоваться напрямую другими частями системы, не подвергаясь непосредственному воздействию модулей. Если мы рассмотрим пример, секрет может хранить учетные данные, которые другие части системы должны использовать для взаимодействия с внешними системами в том же темпе, что и мы.
• Источники секретного тома проверяются, чтобы гарантировать, что ссылка на конкретный объект действительно указывает на объект определенного объекта секретного типа. Из-за этого секрет должен создаваться до любых подов, которые от него зависят. Если требуемый секрет не может быть извлечен из-за его отсутствия или из-за временного отсутствия соединения с сервером AOI, kubelet периодически прекращает работу с этим конкретным подом. Kubelet также сообщает о событии для этого пода, включая все детали проблем с получением секрета.
• Когда мы определяем переменную среды контейнера на основе секрета, мы можем сделать ее необязательной. По умолчанию требуется секрет. Ни один из контейнеров Pod не начнет работать, пока не будут доступны все необязательные секреты. Это означает, что если модуль ссылается на определенный ключ в Secrete и он существует, но в нем отсутствует ключ имени, тогда запуск модуля невозможен.

Альтернативы секретам:

Если есть необходимость защитить ваши данные, Secret — не единственный доступный вариант. Есть и другие доступные альтернативы.

• Мы можем использовать ServiceAccount и его токены для идентификации кластера, если облачному собственному компоненту требуется аутентификация для другого приложения, которое также работает в том же кластере Kubernetes.
• Мы можем использовать сторонние инструменты, которые мы можем запускать как снаружи, так и внутри кластера, обеспечивающего управление секретами.
• Если нам нужна аутентификация, мы можем реализовать пользовательскую подписывающую сторону для сертификатов X.509, а затем использовать CertificateSigningRequests, чтобы позволить этой пользовательской подписывающей стороне выдавать сертификаты модулям, которые в них нуждаются.
• Мы можем использовать плагин устройства, чтобы предоставить локальное оборудование для шифрования узла конкретному поду.

Нет необходимости использовать только услуги или один из этих вариантов. Мы даже можем комбинировать два или более вариантов в зависимости от наших требований.