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

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

У VMware имеются две независимые друг от друга версии программного обеспечения программно-конфигурируемых сетей (Software-Defined Networking, SDN). Более популярная и широко используемая версия NSX интегрирована с программным обеспечением управления виртуализацией VMware vSphere и гипервизором ESXi.

В 2016 году VMware анонсировала выпуск очередной версии, NSX-T, которая поддерживает помимо ESXi и другие гипервизоры, включая Kernel Virtual Machine (KVM). Это значит, что теперь она работает в публичных и частных облачных средах, а в последние месяцы VMware расширила возможности NSX-T и в части поддержки контейнеров приложений.

На конференции Pivotal SpringOne Platform компания VMware анонсировала версию NSX-T 2.1, которая поддерживает Pivotal Cloud Foundry – платформу разработки приложений на основе контейнеров – в качестве сервиса.

«Облачные среды, особенно те из них, которые используют контейнеры приложений, порождают уникальные вызовы с точки зрения сетевых перспектив, – указал директор IDC по исследованиям сетевых технологий центров обработки данных Брэд Кейсмор. – Контейнеры приложений по сравнению с виртуальными машинами обладают очень короткой продолжительностью существования. Иногда это время исчисляется всего несколькими секундами, тогда как виртуальные машины могут существовать бесконечно долго. Есть довольно большое число контейнеров, которые образуют приложение на основе микросервисов; на одной виртуальной машине, например, могут быть запущены десятки контейнеров. И речь здесь идет не только о сетевой архитектуре и топологии, поддерживающей контейнерную исполняемую среду. Возникает еще больший стимул для углубления автоматизации. Если ваша среда является живой и изменчивой, а процессы в распределенной среде микросервисов постоянно стартуют и завершаются, управлять этим вручную у вас вряд ли получится».

Cisco и Juniper: фокус на управлении контейнерными сетями

Рынок для платформ управления контейнерами достаточно широк. Компания Cisco, к примеру, в своем пакете SDN Application Centric Infrastructure (ACI) 3.0 недавно представила средства поддержки контейнеров и контейнерных диспетчеров, в том числе Kubernetes, Docker Data Center и Mesos. Juniper поддерживает контейнеры в SDN Contrail, Nuage поддерживает их в VSP, да и целый ряд стартапов, таких как Tigera и Weaveworks, также нацелены на решение контейнерных сетевых вопросов.

По словам менеджера по маркетингу продуктов VMware Мэтта де Винсентиса, многие платформы контейнерных исполняемых сред (Docker, Pivotal CF, Red Hat OpenShift и даже программное обеспечение с открытым кодом Kubernetes) включают базовый межконтейнерный сетевой функционал. Использование платформы NSX-T упрощает масштабное управление контейнерами и их интеграцию с другими сетевыми службами, например, с межсетевыми экранами и средствами сбалансирования нагрузки.

Технологии контейнеров еще только формируются, но при этом развиваются уже очень быстрыми темпами. Согласно опросу 2016 Voice of the Enterprise, проведенному компанией 451 Research, только 25% респондентов использовали ранее контейнеры, а из их числа только 34% подтвердили широкое применение этой технологии. По мере дальнейшего освоения контейнерных приложений и начала запуска их в производственной среде организации, по словам Кейсмора, активнее начнут прибегать к такого рода решениям, стремясь ликвидировать свои болевые точки в части управления сетевыми ресурсами.

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

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

Не так, как раньше

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

Столь радикальные изменения приводят к тому, что ответственность, которая ранее лежала непосредственных на исполнителях операций, теперь входит в сферу компетенции разработчиков. Вопросы безопасности внутри и между микросервисами относятся как раз к этой категории. Разумно было бы определить, кто лучше разбирается в этой теме – разработчики или специалисты, осуществляющие ИТ-обслуживание. Но следует помнить, что у разработчиков имеются API, которые управляют взаимодействием сервисов друг с другом и с внешним миром. Поэтому большая часть нагрузки, связанной с безопасностью, ложится именно на них.

Обслуживающий же персонал при обеспечении безопасности микросервисов имеет в своем распоряжении весьма ограниченный выбор используемых инструментов. «Большая часть технологий, разработанных для управления традиционными веб-приложениями, неприменима к приложениям на базе микросервисов, – пояснил Оуэн Гарретт, директор компании Nginx по продвижению продуктов. – Сюда относятся и средства безопасности, причем не только межсетевые экраны веб-приложений, но и внутренние процедуры систем обнаружения вторжения».

Фронт внутренний и внешний

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

«Протяженность фронта, на который обрушиваются атаки, у приложений на базе микросервисов значительно больше, чем у традиционных монолитных приложений, – пояснил Гарретт. – Атаки на старые приложения развиваются линейно – сначала трафик обрушивается на средства балансирования нагрузки, затем на уровень представления, а затем на уровни приложений и данных».

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

«Разбивая приложение на небольшие сервисы, приходится искать для каждого из них более надежное решение для аутентификации и авторизации, – указал менеджер по продуктам CoreOS Кесли Хайтауэр. – Многим организациям это доставляет дополнительные трудности, поскольку у них реализован лишь один уровень безопасности между пользователями и их продуктами».

Далее следует подумать об обеспечении безопасности доступа к данным. Вице-президент компании AppDynamics Джон Кауэлл изучил подход к хранению данных, которому следует влиятельный пользователь микросервисов Netflix. «Для каждого сервиса в Netflix данные рекомендуют хранить отдельно, – указал он. – Это снижает зависимость сервисов друг от друга, но увеличивает объем хранимых данных».

Вместо использования единого центрального репозитория (как у систем управления реляционными базами данных, к которым обращаются традиционные монолитные приложения) архитектура микросервисов предполагает распределение данных. В общем случае для этого прибегают к нескольким принципиально разным типам хранения (к примеру, в случае с Netflix это Cassandra и Riak).

«Обеспечение безопасности усложняется, потому что у вас нет даже централизованного средства диагностики, которое позволило бы определить, что что-то идет не так, – подчеркнул Кауэлл. – Нет единого источника, осуществляющего проверку соответствия нормативным требованиям и позволяющего оценить надежность проверок и правил, с помощью которых вы пытаетесь организовать управление безопасностью».

Дополнительные внутренние факторы

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

«Задача осложняется тем, что каждый микросервис разрабатывается независимо от других и имеет свой собственный набор языков и сред разработки, – отметил Гарретт. – Поэтому универсальных стандартов безопасности просто не существует».

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

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