Дрейф инфраструктуры — это не просто техническая неприятность; это серьезная проблема, которая, если ее не контролировать, может поставить под угрозу всю вашу организацию, пишет на портале The New Stack Эран Биби, соучредитель и директор по продуктам компании Firefly.

Дрейф инфраструктуры — серьезная проблема для организаций, управляющих облачными ресурсами в масштабе. Хотя инфраструктура как код (IaC) предлагает структурированный подход к развертыванию и поддержке инфраструктуры, дрейф все равно происходит, когда изменения происходят вне рабочих процессов IaC. И это не обязательно аномальное поведение — такое может произойти в любой момент по вине внешнего подрядчика, в ситуации высокого давления (например, инцидента), требующей быстрого решения, или из-за ошибки в суждениях или слишком привилегированного инструмента.

Конечно, оптимально поддерживать идеальную гигиену IaC с помощью безупречных процессов GitOps, но, к сожалению, это всего лишь желаемое и невыполнимое. На практике мы видим чрезмерное увлечение ClickOps (или ручное выполнение задач путем нажатия на различные опции в программных инструментах, что может быть более доступным для пользователей, не знакомых с кодированием или написанием сценариев). И этот ручной процесс часто может быть причиной дрейфа инфраструктуры.

Дрейф инфраструктуры — это расхождение между фактическим состоянием инфраструктуры в облаке и желаемым состоянием, определенным в таких инструментах IaC, как Terraform. Это несоответствие может привести к уязвимостям в системе безопасности, проблемам с надежностью и неэффективности работы.

Мы ежедневно сканируем и обрабатываем более 55 тыс. облачных учетных записей в системе Firefly. Таким образом, мы обрабатываем почти 320 тыс. случаев дрейфа в месяц, поэтому мы действительно понимаем масштабы и последствия проблемы дрейфа инфраструктуры. Мы также убедились, что 90% крупных развертываний с использованием IaC сталкиваются с проблемой дрейфа, и около половины таких случаев остаются незамеченными. Для таких организаций вероятность негативных последствий, будь то надежность, безопасность или трудозатраты, составляет 100%.

Общие причины дрейфа инфраструктуры

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

К числу распространенных причин дрейфа инфраструктуры относятся:

  • Ручные аварийные исправления. Во время инцидентов или чрезвычайных ситуаций инженеры часто вносят прямые изменения в инфраструктуру через облачные консоли или API. Эти изменения могут решать непосредственные проблемы, но при этом обходить конвейеры IaC, что приводит к дрейфу.
  • Унаследованные ресурсы. Организации, находящиеся в середине пути внедрения IaC, могут иметь существующие ресурсы, созданные вручную или с помощью различных инструментов. Эти ресурсы подвержены дрейфу, поскольку они не подпадают под управление IaC.
  • Автоматизированные инструменты с разрешениями. Такие инструменты, как управление средствами безопасности в облаке (CSPM), могут иметь права на изменение конфигураций, например групп безопасности. Когда эти инструменты вносят изменения вне рабочих процессов IaC, возникает дрейф.
  • Частичное внедрение IaC. Некоторые организации внедряют IaC выборочно, управляя с помощью IaC только новыми или конкретными проектами, в то время как старые или другие ресурсы управляются вручную. Такая несогласованность в разных средах может привести к дрейфу.
  • Рассогласование сред. Если производственные среды часто жестко контролируются, то среды подготовки и разработки могут предоставлять разработчикам бóльшую свободу действий. Ручные изменения в этих средах могут привести к расхождениям, особенно если конфигурации в разных средах не совпадают.
  • Рассогласование API IaC и облака. Облачные провайдеры часто обновляют свои API и сервисы, что может приводить к дрейфу, если инструменты IaC не обновляются в соответствии с ними. Такое рассогласование может привести к тому, что развертывания IaC будут расходиться с текущим состоянием облака.

Резюмируем. Ручные аварийные исправления неизбежны даже для самых развитых инженерных организаций. Однако, хотя эти изменения могут решить сиюминутные проблемы, они обходят конвейеры IaC, что приводит к расхождениям. Кроме того, организации, которые внедряют IaC на начальном этапе своего облачного пути, могут иметь унаследованные ресурсы, созданные вне системы управления IaC, что делает их подверженными дрейфу. Автоматизированные инструменты, такие как системы CSPM, могут иметь права на изменение конфигураций, например групп безопасности; изменения, внесенные этими инструментами вне рабочих процессов IaC, могут привести к дополнительным расхождениям.

Как выглядит дрейф инфраструктуры

Дрейф инфраструктуры может принимать различные формы, часто начинаясь с незначительных изменений, которые перерастают в значительные расхождения.

Например, рассмотрим политику AWS по управлению идентификацией и доступом (IAM), управляемую с помощью Terraform, где дрейф происходит, когда кто-то добавляет в политику такую простую вещь, как звездочка (*), которая расширяет разрешения с доступа только для чтения до полного доступа. Аналогично, в среде Kubernetes роль с правами только на чтение в IaC может быть изменена на права на запись и удаление в реальном кластере, что потенциально может нанести большой ущерб в продакшн. Такие, казалось бы, незначительные изменения могут поставить под угрозу безопасность и привести к непредусмотренному доступу.

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

Данные нашего отчета «2024 State of Infrastructure as Code Report» показывают, что зачастую этот процесс остается без внимания. Дрейф инфраструктуры не только часто остается незамеченным, но даже когда он обнаруживается, его не сразу удается устранить. Что еще более тревожно, в 13% случаев дрейф инфраструктуры вообще не исправляется.

Источник: отчет Firefly «2024 State of Infrastructure as Code Report»

Помимо серьезного риска простоя, не устраненный дрейф может повлиять на стабильность и безопасность вашей инфраструктуры. Например, когда разрешения или конфигурации меняются вне IaC, это может открыть уязвимости, которыми могут воспользоваться злоумышленники. Дрейф также может повлиять на надежность сервисов, если фактическое состояние инфраструктуры не соответствует желаемым конфигурациям, протестированным в режиме подготовки. В общем, дрейф — это не просто техническая неприятность, он может поставить под угрозу вашу организацию в целом.

Практические подходы к проактивному обнаружению дрейфа

Эффективное управление дрейфом требует надежного мониторинга и обнаружения, а также проверенных методов для его скорейшего устранения.

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

  • Мониторинг дрейфа. Для обнаружения дрейфа можно использовать план Terraform или команду предварительного просмотра Pulumi, а также команду обнаружения дрейфа AWS CloudFormation через интерфейс командной строки (CLI). Проводя плановые регулярные проверки, команды могут сравнивать текущее состояние инфраструктуры с желаемой конфигурацией. При обнаружении дрейфа код на выходе укажет на несоответствие, что позволит командам отреагировать соответствующим образом.
  • GitOps для Kubernetes. Для сред Kubernetes инструменты GitOps, такие как Argo CD и Flux, постоянно сверяют состояние кластера с конфигурацией, хранящейся в Git. Эти инструменты позволяют быстро отменить любые несанкционированные изменения, поддерживая соответствие с источником истины в Git.
  • Инструменты для обнаружения дрейфа. Такие Open Source-инструменты, как Driftctl и KubeDiff, обеспечивают целенаправленное обнаружение дрейфов. Driftctl хорошо работает с такими инструментами IaC, как Terraform, а KubeDiff оптимизирован для конфигураций Kubernetes.
  • Оповещения и маршрутизация в реальном времени. Создание механизмов оповещения имеет решающее значение для эффективного управления дрейфом. Интегрируя инструменты IaC со Slack или PagerDuty, команды могут получать уведомления о дрейфе в режиме реального времени, что позволяет оперативно решать проблемы.

Это хорошие способы обнаружения дрейфа, но целью должно быть устранение дрейфа.

Стратегии устранения дрейфа

Устранение дрейфа может принимать две основные формы: приведение облачной среды в соответствие с IaC или обновление IaC для отражения фактического состояния. В случаях, когда ручные изменения являются временными исправлениями, повторное применение конфигураций IaC может восстановить желаемое состояние. Однако если ручные изменения представляют собой необходимые корректировки, лучше всего обновить шаблоны IaC, чтобы привести их в соответствие с фактическим состоянием и предотвратить повторный дрейф.

Если вы только начинаете работать с обнаружением дрейфов, простой сценарий мониторинга с помощью Terraform может дать ценные сведения о несоответствиях. Хотя этот базовый подход может не подойти для крупных развертываний, он может быть эффективен для небольших установок или в качестве доказательства концепции. Для больших сред такие инструменты, как Firefly, driftctl или фреймворки GitOps, представляют собой более надежное решение для работы со сложными инфраструктурами корпоративного масштаба.

Взятие дрейфа инфраструктуры под контроль

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

Благодаря использованию IaC, проактивному мониторингу дрейфа и внедрению таких стратегий, как GitOps, команды могут минимизировать влияние дрейфа, обеспечивая постоянство инфраструктуры и ее соответствие потребностям организации. Регулярное обнаружение дрейфов и своевременное устранение их последствий в конечном итоге повышают безопасность, надежность и эффективность облачных операций, позволяя командам уверенно работать с той скоростью, которая необходима современным компаниям.