Безопасная сеть контейнеров с Project Calico

Сетевая безопасность была простой во времена монолитных устаревших приложений. Монолитные приложения, как правило, самодостаточны, не требуют особого взаимодействия с внешними приложениями или службами. Даже если они взаимодействуют извне, настройка довольно проста. Разработчики определяют различные части приложения, а ИТ-отдел размещает брандмауэры вокруг каждого основного компонента — базы данных, сервера и т. д. У этой модели много недостатков. Во-первых, это создает конфликт между Dev и IT. Разработчикам нужно потратить время на создание тикета, определяющего создаваемое ими приложение. ИТ-отдел тратит пару дней на настройку требований. Всякий раз, когда требуется изменение, разработчикам необходимо создать еще один тикет, на что ИТ-специалистам требуется больше времени. Разработчики хотят быстрее выпускать новые функции и иметь меньше узких мест со стороны ИТ-отдела, а ИТ-отдел хочет быть уверенным, что все, что выпускается, безопасно в производственной среде. Это приводит к игре с обвинениями, в которой ни разработчики, ни ИТ не остаются довольными.

Новый подход к безопасности

Перенесемся в 2017 год, и эта проблема только усугубится с появлением новых технологий, таких как контейнеры, микросервисы и методология DevOps. Сегодня жизненные циклы приложений очень динамичны. Базовая инфраструктура, которая питает их, очень недолговечна. Приложения требуют масштабирования за считанные секунды, чтобы справиться с пиками трафика. В результате срок службы контейнеров намного меньше, чем срок службы виртуальных машин. В одном обзоре говорится, что средний срок службы контейнера составляет 9,25 часа. Это значительно короче, чем виртуальные машины, которые обычно работают месяцами или годами без изменений. На самом деле, нередко можно увидеть, как контейнеры взбалтываются за считанные минуты.

Например, если приложение поддерживает телевизионную рекламу, оно может получить всплеск миллионов посещений в течение первых пяти-десяти минут показа рекламы. За это время его загруженность трафиком может быть в 1000 раз больше, чем обычно. Чтобы поддерживать такой объем трафика, приложение может предоставить новую инфраструктуру на день или несколько часов и отключить эту инфраструктуру, как только трафик вернется в нормальное состояние. Однако это дорого и может привести к тому, что у вас останутся тысячи облачных экземпляров, которые не будут использоваться в течение 95 % времени. Сравните это с тем, как контейнерное приложение справится с этой нагрузкой — оно будет автоматически предоставлять тысячи экземпляров контейнеров в режиме реального времени в зависимости от спроса, и как только спрос упадет, оно уничтожит эти экземпляры контейнера, что не приведет к пустой трате ресурсов.. В идеале именно так следует обращаться с инфраструктурой.

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

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

Kubernetes — первая часть головоломки

Поскольку контейнеры масштабируются динамически, для этого используется оркестратор контейнеров, такой как Kubernetes. Оркестратор автоматизирует подготовку, настройку и управление контейнерами в любом масштабе. Из этого следует, что решение по безопасности для контейнеров должно учитывать оркестрацию.

В Kubernetes есть набор отличных настроек по умолчанию для управления контейнерами. Когда дело доходит до безопасности, одним из критических значений по умолчанию является то, что IP-адрес назначается каждому модулю в кластере. Так получилось, что IP-адреса играли центральную роль в обеспечении безопасности с первых дней существования Интернета. Каждый компьютер, подключенный к Интернету, имеет IP-адрес, каждый корпоративный сервер имеет IP-адрес, и когда дело доходит до сетевой безопасности, IP-адреса являются основой. Контейнерам нужно сетевое решение, которое может интегрироваться с Kubernetes, обеспечивать безопасность на основе IP и делать это в масштабе. Вот что предлагает Project Calico.

Project Calico: безопасность на основе политик

Project Calico может масштабировать сетевую безопасность вместе с созданием контейнеров в масштабе. Даже если приложение масштабируется до тысяч контейнеров за считанные секунды, Project Calico по-прежнему может легко настроить безопасность. Calico делает это, применяя набор политик, которые управляют каждым компонентом системы. С помощью этих политик Calico можно настроить таким образом, чтобы службы и экземпляры могли взаимодействовать с другими службами и экземплярами только при необходимости. Это снижает сложность сети и создает меньше возможностей для взлома.

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

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

Преимущества бязи

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

Calico также интегрируется с Flannel, чтобы предоставить более целостное сетевое решение для Kubernetes. Этот проект называется Канал. Он объединяет детализированные элементы управления безопасностью на основе политик Project Calico с возможностями подключения к сети Flannel. Calico, созданный Tigera, пользуется большой поддержкой сообщества Kubernetes. Недавно он также был интегрирован с платформой Google Container Engine.

Контейнерные приложения — это будущее, но для полной реализации их потенциала они должны быть надлежащим образом защищены в рабочей среде. Однако традиционная модель безопасности не применима к контейнерным приложениям, поскольку они слишком динамичны, работают в большем масштабе и содержат новые компоненты, такие как оркестратор. Для обеспечения безопасности контейнерных приложений вам понадобится инструмент сетевой безопасности на основе политик, такой как Calico. Это делает безопасность масштабируемой, простой и надежной, чем когда-либо прежде. Когда вы создаете и отправляете свои приложения в контейнерах, не пропустите Project Calico для их защиты.