Firefly спонсировал этот пост.
Управление секретами в средах Kubernetes (K8S) является критической, но часто упускаемой из виду вызов. Многие команды начинают с использования встроенных секретов K8S, только для того, чтобы понять, что они поставляются с ограничениями безопасности и управления. Такие секреты, как учетные данные базы данных, токены API и частные ключи, имеют основополагающее значение для обеспечения операций приложений, но при этом неверно обработка их может подвергнуть целые системы рискам.
В этом посте рассматриваются проблемы управления секретами в K8S и почему полагаться исключительно на встроенные секреты K8S может представлять риски безопасности и неэффективность работы. Он углубляется в преимущества использования централизованного решения по управлению секретами, такими как Hashicorp Vault, выделяет преимущества интеграции кластеров K8S с хранилищем, и объясняет, как драйвер интерфейса хранилища контейнеров в секретах (CSI) упрощает секретный поиск без прямых вызовов API. Я также поделюсь практическим обзором архитектуры и лучшими практиками для масштабирования хранилища по нескольким кластерам.
Задача с секретами K8s
По умолчанию секреты K8S хранятся не зашифрованы в ETCD. Распределенное хранилище ключевых значений, которое служит первичной системой хранения данных K8S и ETCD, содержит все состояния и конфигурации кластера, включая развертывание, услуги и секреты. Это означает, что любой, у кого есть доступ к ETCD или API -сервер K8S, который действует как плоскость управления для управления ресурсами и обработки запросов от пользователей и приложений, может получить эти секреты.
Кроме того, секреты часто жестко кодируются в переменные среды или файлы конфигурации, создавая кошмар обслуживания, когда их необходимо обновлять по нескольким приложениям и кластерам и увеличивая риск воздействия и неправильного управления.
Общим шаблоном является хранение секретов в ConfigMaps или внедрение их в файлы YAML, но этот подход вводит несколько проблем:
- Отсутствие шифрования: Секреты K8S только базовые 64, кодируемые, не по-настоящему зашифрованы.
- Ограниченный контроль доступа: Политика контроля доступа на основе ролей (RBAC) в K8S не обеспечивает мелкозернистый контроль над тем, кто может получить доступ к секретам.
- Нет встроенной аудиторской тропы: Трудно отследить, кто доступ или изменил секрет.
- Секретный разрастание: Секреты часто дублируются в нескольких пространствах имен и приложениях.
- Проблемы ротации: Без автоматизированной системы вращающиеся секреты требуют вручную обновлять несколько развертываний.
Учитывая эти ограничения, ясно, что только секреты K8S недостаточно для безопасного управления секретами в масштабе.
Управление секретами на основе хранилища
Вместо того, чтобы полагаться на секреты K8S, более масштабируемым и безопасным подходом является интеграция кластеров K8S с внешними секретами, такими как хранилище Hashicorp. Это обеспечивает одно, централизованное место для управления секретами в нескольких кластерах, гарантируя, что секреты никогда не хранятся в простом тексте в K8s.
Секреты в магазине позволяют:
- Приложения для динамического получения секретов из Vault с помощью вызовов API.
- В K8S не хранится никаких секретов для устранения рисков воздействия.
- Применение политик контроля доступа, поэтому только авторизованные службы могут получить доступ к конкретным секретам.
- Единственное место (хранилище), чтобы сделать все обновления, которые автоматически распространяются на все кластеры, потребляющие секрет.
- Автоматическое секретное ротация, снижение рисков безопасности и бремя соответствия.
Централизируя секреты, команды снижают риск того, что секреты протекают через неправильные конфигурации или несанкционированный доступ.
Соединение кластеров K8S с хранилищем
Чтобы интегрировать хранилище с K8s, общим подходом является использование метода аутентификации K8S в Vault. Это позволяет рабочей нагрузки, работающих внутри K8S, аутентифицировать с хранилищем без необходимости статических учетных данных.
Процесс включает в себя:
Синхронизация секретов в кластерах
В средах с несколькими кластерами K8S управление секретами центрально в хранилище дает значительное преимущество. Вместо вручную обновлять секреты в разных кластерах, команды могут хранить секреты один раз в хранилище и позволять всем кластерам получать динамически их.
Например, рассмотрим организацию, управляющую пятью кластерами K8S, каждый из которых занимается различными приложениями, но делится переменными общей среды. Используя Vault, любое обновление в секрете, такое как пароль базы данных, может быть сделано в Vault, и все кластеры автоматически получат обновленную версию без необходимости ручного перераспределения приложений.
Избегание вызовов API прямого хранилища
Ключевое соображение при использовании хранилища — это избегание прямых вызовов API из приложений. В то время как приложения могут получить секреты непосредственно из Vault, используя свой комплект разработки программного обеспечения (SDK), этот подход вводит несколько проблем:
- Модификации кода: Приложения должны включать логику хранилища, что приводит к зависимостям и блокировке поставщиков.
- Производительность накладных расходов: Каждый запрос API на Vault добавляет задержку и может ввести проблемы с ограниченными показателями.
- Обработка ущерба для хранилища: Приложениям нужны учетные данные для аутентификации с хранилищем, создавая еще одну задачу управления секретами.
Лучшим подходом является использование The Secrets Store Driver CSI, который позволяет K8S монтировать секреты от хранилища в капсулы в качестве файлов. Этот метод отделяет приложения из хранилища и обеспечивает безопасную впрыскивание секретов в файловую систему контейнера без изменения кода приложения.
Демонстрация хранилища Vault + Secrets в действии
Практическая реализация хранилища с K8S использует драйвер CSI Secrets Store наряду с интеграцией Vault. Архитектура состоит из:
Live Secret Updates с Vault + K8s
Одним из ключевых преимуществ этой настройки является динамическое обновление секретов. Если секрет изменяется в хранилище, он может быть автоматически распространяться на работу рабочих нагрузок. Тем не менее, для бесшовных обновлений могут потребоваться некоторые дополнительные конфигурации:
- Обновления: Поскольку стручки не автоматически перезагружают секреты, перезагрузка рабочих нагрузок гарантирует, что обновленные секреты будут получены.
- Подход коляска: Некоторые команды используют коляску хранилища, чтобы динамически обновлять секреты, не требуя перезапуска POD.
При развертывании хранилища в крупномасштабных средах K8S команды должны тщательно сбалансировать безопасность, производительность и эффективность работы. Высокая доступность (HA) имеет важное значение, требуя, чтобы хранилище было развернуто в режиме HA с надежными механизмами резервного копирования и аварийного переключения для предотвращения сбоев обслуживания. Оптимизация производительности в равной степени имеет решающее значение, особенно для секретов, хранящих CSI Daemonset, который должен быть настроен с соответствующими ограничениями ресурсов для эффективной обработки высоких нагрузок.
В соответствии с принципом наименьшей привилегии гарантирует, что приложения и пользователи могут получить доступ только к тому, что им требуется секреты, минимизируя риски воздействия. Кроме того, включение регистрации аудита в хранилище обеспечивает видимость в секретах доступа и модификаций, помогая организациям поддерживать соответствие и быстро обнаружить несанкционированную деятельность. Управляя этими соображениями, команды могут реализовать масштабируемую, устойчивую и безопасную стратегию управления секретами для своих рабочих нагрузок K8S.
Управление секретами K8S: больше, чем просто лучшая практика
Защита секретов в K8s — это больше, чем просто лучшая практика — это необходимость защиты конфиденциальных данных и поддержания оперативной устойчивости. В то время как встроенное управление секретами K8S предлагает удобство, ему не хватает шифрования, мелкозернистого контроля доступа и автоматизации жизненного цикла, необходимой для безопасности корпоративного уровня. Централизируя секреты в хранилище, организации получают надежное, масштабируемое решение, которое упрощает распределение секретов, обеспечивает соблюдение политики безопасности и обеспечивает автоматическое вращение.
В сочетании с The Secrets Store CSI Driver, команды могут плавно интегрировать безопасные секреты в свои рабочие нагрузки K8S, не вводя сложность или прямую зависимости от хранилища. Поскольку организации масштабируются по нескольким кластерам, хорошо архизированный подход к управлению секретами сводит к минимуму человеческую ошибку и обеспечивает более устойчивую инфраструктуру путем снижения рисков безопасности и повышения оперативной эффективности.
Firefly-это плоскость управления облаком, которая позволяет DevOps и командам инженеров платформы сканировать и обнаруживать весь свой облачный след, обнаружение облачных конфигураций, классифицировать активы с использованием политики как код и управлять одним инвентаризацией облачных ресурсов в разных кластерах и Kubernetes Clusters. Узнайте больше последних из Firefly Trending Stories YouTube.com/ThenewStack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Utku Darilmaz является страстным инженером DevOps в Firefly, в настоящее время базирующемся в Дубае, ОАЭ. Имея более пятилетнего опыта работы в этой области, он развил сильное мастерство в широком спектре DevOps и Sysops. Его … Подробнее от Утку Дарилмаза
