При создании или изменении облачных шаблонов vRealize Automation используйте ресурсы безопасности, которые лучше всего подходят для ваших целей.
Независимый от облачной среды ресурс группы безопасности
Cloud.SecurityGroup
. Ресурс по умолчанию отображается следующим образом:
Cloud_SecurityGroup_1: type: Cloud.SecurityGroup properties: constraints: [] securityGroupType: existing
Ресурс группы безопасности указывается в проекте облачного шаблона как «существующий» (securityGroupType: existing
) или «по требованию» (securityGroupType: new
).
Существующую группу безопасности можно добавить в облачный шаблон, или можно использовать существующую группу безопасности, добавленную в профиль сети.
В NSX-V и NSX-T, а также в NSX-T с включенным диспетчером политик в сочетании с VMware Cloud on AWS при проектировании или изменении облачного шаблона можно добавить существующую группу безопасности или определить новую. Группы безопасности по требованию поддерживаются для NSX-T и NSX-V, а также для VMware Cloud on AWS при использовании с диспетчером политик NSX-T.
Для всех типов учетных записей облачной службы, кроме Microsoft Azure, можно связать одну или несколько групп безопасности с сетевым адаптером компьютера. Сетевой адаптер виртуальной машины Microsoft Azure (machineName) можно связать только с одной группой безопасности.
По умолчанию для свойства группы безопасности securityGroupType
задано значение existing
. Чтобы создать группу безопасности по требованию, введите значение new
для свойства securityGroupType
. Чтобы указать правила брандмауэра для группы безопасности по требованию, используйте свойство rules
в разделе Cloud.SecurityGroup
ресурса группы безопасности.
Существующие группы безопасности
Существующие группы безопасности создаются в исходном ресурсе облачной учетной записи, например NSX-T или Amazon Web Services. Они представляют собой данные, которые vRealize Automation собирает из источника. Существующую группу безопасности можно выбрать в списке доступных ресурсов в рамках профиля сети vRealize Automation. В проекте облачного шаблона можно указать существующую группу безопасности либо по фактическому наличию в указанном профиле сети, либо по имени, используя параметр securityGroupType: existing
ресурса группы безопасности. При добавлении группы безопасности в профиль сети добавьте в профиль сети хотя бы один тег возможности. При использовании ресурсов группы безопасности по требованию в проекте облачного шаблона требуется тег ограничения.
В проекте облачного шаблона ресурс группы безопасности можно связать с одним ресурсом компьютера или несколькими.
Группы безопасности по требованию
Группы безопасности по требованию можно настроить при определении или изменении проекта облачного шаблона с помощью параметра securityGroupType: new
в коде ресурса группы безопасности.
С помощью группы безопасности по требованию для NSX-V и NSX-T, а также для Amazon Web Services (при условии использования с типом NSX-T Policy) можно применить определенный набор правил брандмауэра к ресурсу компьютера, подключенного к сети, или к набору объединенных ресурсов. Каждая группа безопасности может содержать несколько именованных правил брандмауэра. Группу безопасности по требованию можно использовать, чтобы указать службы или протоколы и порты. Следует отметить, что можно указать либо службу, либо протокол, но не то и другое одновременно. Кроме протокола, можно указать порт. Если указана служба, то порт указать нельзя. Если правило не содержит ни службу, ни протокол, значение службы по умолчанию Any.
Кроме того, в правилах брандмауэра можно указать IP-адреса и диапазоны IP-адресов. Некоторые примеры правил брандмауэра приведены в разделе Сети, ресурсы безопасности и подсистемы балансировки нагрузки в vRealize Automation.
- Разрешить (по умолчанию): разрешает сетевой трафик, указанный в данном правиле брандмауэра.
- Запретить: блокирует сетевой трафик, указанный в данном правиле брандмауэра. Активно сообщает клиенту, что подключение отклонено.
- Отклонить: отклоняет сетевой трафик, указанный в правиле брандмауэра. Автоматически отбрасывает пакет, как если бы прослушиватель не был подключен к Интернету.
access: Allow
и правило брандмауэра
access: Deny
, см. в разделе
Сети, ресурсы безопасности и подсистемы балансировки нагрузки в vRealize Automation.
Правила брандмауэра поддерживают значения CIDR в формате IPv4 или IPv6 для исходного и конечного IP-адресов. Пример проекта, в котором используются значения IPv6 CIDR в правиле брандмауэра, см. в разделе Сети, ресурсы безопасности и подсистемы балансировки нагрузки в vRealize Automation.
Существующие группы безопасности и группы безопасности по требованию для VMware Cloud on AWS
Группы безопасности по требованию можно определить для компьютера VMware Cloud on AWS в облачном шаблоне с помощью параметра securityGroupType: new
в коде ресурса группы безопасности.
resources: Cloud_SecurityGroup_1: type: Cloud.SecurityGroup properties: name: vmc-odsg securityGroupType: new rules: - name: datapath direction: inbound protocol: TCP ports: 5011 access: Allow source: any
Также можно определить существующую группу безопасности для компьютера VMware Cloud on AWS, подключенного к сети, и при необходимости добавить теги ограничений, как показано в следующих примерах:
Cloud_SecurityGroup_2: type: Cloud.SecurityGroup properties: constraints: [xyz] securityGroupType: existing
Cloud_SecurityGroup_3: type: Cloud.SecurityGroup properties: securityGroupType: existing constraints: - tag: xyz
- Если группа безопасности связана с одним или несколькими компьютерами в развертывании, при выполнении действия удаления отображается сообщение о том, что группу безопасности нельзя удалить.
- Если группа безопасности не связана с компьютерами в развертывании, то при выполнении действия удаления отображается сообщение о том, что группа безопасности будет удалена из этого развертывания и это действие будет нельзя отменить. Существующая группа безопасности удаляется из облачного шаблона, а группа безопасности по требованию уничтожается.
Использование тегов безопасности NSX-V и тегов виртуальных машин NSX-T
Теги безопасности NSX-V, а также теги ВМ NSX-T и NSX-T с API-интерфейсом Policy можно просматривать и использовать в управляемых ресурсах облачных шаблонов vRealize Automation.
Теги безопасности NSX-V и NSX-T могут использоваться с vSphere. Также поддерживается использование тегов безопасности NSX-T с VMware Cloud on AWS.
Как и для виртуальных машин, развертываемых в vSphere, теги компьютера можно настроить для виртуальной машины, развертываемой в VMware Cloud on AWS. Тег компьютера также можно обновить после первоначального развертывания. Эти теги компьютера позволяют vRealize Automation динамически назначать виртуальную машину соответствующей группе безопасности NSX-T во время развертывания.
key: nsxSecurityTag
и значение тега в вычислительном ресурсе облачного шаблона, как показано в следующем примере, при условии, что компьютер подключен к сети
NSX-V.
tags: - key: nsxSecurityTag - value: security_tag_1 - key: nsxSecurityTag - value: security_tag_2
Указанное значение должно соответствовать тегу безопасности NSX-V. Если в NSX-V нет тегов безопасности, соответствующих указанному значению ключа nsxSecurityTag
, произойдет сбой развертывания.
Установка тегов безопасности NSX-V требует подключения компьютера к сети NSX-V. Если компьютер подключен к сети vSphere, установка тегов безопасности NSX-V игнорируется. В любом случае для компьютера vSphere также устанавливаются теги.
В NSX-T нет отдельного тега безопасности. При указании любого тега в вычислительном ресурсе облачного шаблона развернутая ВМ будет связана со всеми тегами, указанными в NSX-T. Для NSX-T, включая NSX-T с API-интерфейсом Policy, теги ВМ также указываются в облачном шаблоне в виде пары «ключ — значение». Параметр key
идентичен параметру scope
в NSX-T, а параметр value
идентичен параметру Tag Name
, заданному в NSX-T.
Следует отметить, что если для переноса облачных учетных записей из NSX-V в NSX-T, включая NSX-T с API-интерфейсом Policy, используется помощник по переносу vRealize Automation NSX-V в NSX-T, то данный помощник создает пару «ключ — значение» nsxSecurityTag
. В этом сценарии, или если облачный шаблон по какой-либо причине явно предлагает использовать nsxSecurityTag
с NSX-T, включая NSX-T с API-интерфейсом Policy, развертывание создает тег ВМ с пустым параметром «Область» с именем тега, который совпадает с указанным значением value
. При просмотре таких тегов в NSX-T столбец «Область» будет пустым.
Чтобы избежать путаницы, не используйте пары ключей nsxSecurityTag
для NSX-T. Если вы указываете пару «ключ — значение» nsxSecurityTag
для использования с NSX-T, включая NSX-T с API-интерфейсом Policy, развертывание создает тег ВМ с пустым параметром scope с именем тега, совпадающим с указанным значением value
. При просмотре таких тегов в NSX-T столбец «Область» будет пустым.
Использование политик изоляции приложений в правилах брандмауэра для группы безопасности по требованию
Чтобы разрешить только внутренний трафик между ресурсами, подготовленными в облачном шаблоне, можно использовать политику изоляции приложений. Благодаря изоляции приложений компьютеры, подготовленные с помощью облачного шаблона, могут обмениваться данными между собой, но не могут устанавливать соединения за пределами брандмауэра. Политику изоляции приложений можно создать в профиле сети. Кроме того, изоляцию приложений можно указать в проекте облачного шаблона, используя группу безопасности по требованию с правилом брандмауэра «Запретить», либо частную или исходящую сеть.
Политика изоляции приложений создается с низким приоритетом. При применении нескольких политик приоритет будет иметь политика с более высоким значением.
При создании политики изоляции приложений ее имя создается автоматически. Кроме того, политика доступна для повторного использования в других проектах облачных шаблонов и итерациях проектов, относящихся к конечной точке и проекту связанного ресурса. Имя политики изоляции приложений не отображается в облачном шаблоне, но отображается в виде настраиваемого свойства на странице проекта (
) после развертывания проекта облачного шаблона.Для той же связанной конечной точки в проекте любое развертывание, в котором для изоляции приложений требуется группа безопасности по требованию, может использовать ту же политику изоляции приложений. После создания политика не удаляется. При указании политики изоляции приложений система vRealize Automation выполняет поиск политики в проекте применительно к связанной конечной точке. Если политика будет найдена, она используется повторно. В противном случае создается новая политика. Имя политики изоляции приложений отображается только после первоначального развертывания в списке настраиваемых свойств проекта.
Использование групп безопасности в итеративной разработке облачных шаблонов
- В конструкторе шаблонов Cloud Assembly отключите группу безопасности от всех компьютеров, связанных с ней в облачном шаблоне.
- Повторно разверните шаблон, выбрав вариант Обновить существующее развертывание.
- Удалите существующие теги ограничений группы безопасности и (или) свойства securityGroupType в шаблоне.
- Добавьте новые теги ограничений группы безопасности и (или) свойства securityGroupType в шаблон.
- Привяжите новые теги ограничений группы безопасности и (или) экземпляры свойств securityGroupType к компьютерам в шаблоне.
- Повторно разверните шаблон, выбрав вариант Обновить существующее развертывание.
Доступные операции регулярного обслуживания
Список типовых операций по регулярному обслуживанию, доступных для облачного шаблона и ресурсов развертывания, см. в разделе Какие действия можно выполнять в развертываниях Cloud Assembly.
Подробнее
Сведения об использовании группы безопасности для изоляции сети см. в разделе Ресурсы безопасности в vRealize Automation.
Сведения об использовании групп безопасности в профилях сети см. в разделах Дополнительные сведения о профилях сетей в vRealize Automation и Использование параметров группы безопасности в профилях сетей и проектах облачных шаблонов в vRealize Automation.
Примеры использования групп безопасности в облачных шаблонах см. в разделе Сети, ресурсы безопасности и подсистемы балансировки нагрузки в vRealize Automation.