Преобразование сертификатов кластера для использования общих имен вместо объявления на основе отпечатков

Подпись сертификата (более известная как отпечаток) является уникальной. Сертификат кластера, объявленный по отпечатку, является конкретным экземпляром сертификата. Эта усложняет смену сертификатов и общее управление ими, а также требует явного объявления. Для каждого изменения требуется координированное обновление кластера и соответствующих вычислительных узлов.

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

Примечание.

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Сведения о начале работы см. в статье "Установка Azure PowerShell". Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Переход к использованию сертификатов, подписанных центром сертификации

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

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

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

Сертификат, объявленный с помощью общего имени, обычно считается действительным, если:

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

Service Fabric поддерживает объявление сертификатов с помощью общего имени двумя способами:

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

Дополнительные сведения см. в разделе "Объявления о проверке сертификатов на основе общих имен" этой статьи.

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

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

Отправка сертификата и его установка в масштабируемом наборе

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

Перед внесением изменений в объявления сертификатов кластера важно установить как текущие, так и целевые сертификаты кластера на виртуальных машинах каждого типа узла кластера. Путь от выпуска сертификата до подготовки на узле Service Fabric подробно рассматривается в разделе "Путь сертификата" этой статьи.

Перевод кластера в оптимальное начальное состояние

Преобразование объявления сертификата из основанного на отпечатке в основанное на общем имени влияет на следующее:

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

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

Для преобразования есть несколько допустимых начальных состояний. Неизменным остается то, что кластер уже использует целевой сертификат (объявленный с помощью отпечатка) до обновления до общего имени. В этой статье мы рассмотрим состояния GoalCert, OldCert1 и OldCert2.

Допустимые начальные состояния

• Thumbprint: GoalCert, ThumbprintSecondary: None
• Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, где у GoalCert дата NotBefore позднее, чем у OldCert1.
• Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, где у GoalCert дата NotBefore позднее, чем у OldCert1.

Примечание.

До версии 7.2.445 (7.2 CU4) решение Service Fabric выбирало сертификат, срок действия которого истекает раньше остальных (сертификат с самой ранней датой NotAfter), поэтому для указанных выше состояний в версиях до 7.2 CU4 требуется, чтобы у GoalCert дата NotAfter была позднее, чем у OldCert1

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

Выбор нужной схемы проверки сертификатов на основе общего имени

Как описано ранее, Service Fabric поддерживает объявление сертификатов с помощью общего имени с применением неявного якоря доверия или явного связывания отпечатков издателя. Дополнительные сведения см. в разделе "Объявления о проверке сертификатов на основе общих имен" этой статьи.

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

Примечание.

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

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

В инфраструктуре открытых ключей могут использоваться разные центры сертификации (называемые также издателями) для подписи сертификатов указанного субъекта. Поэтому важно указать все ожидаемые отпечатки издателя для этого субъекта. Иными словами, обновление сертификата не обязательно будет подписано тем же издателем, что подписал обновляемый сертификат.

Мы рекомендуем указывать издателя. Для сертификатов, цепочка которых приводит к доверенному корню, можно не указывать издателя, но у этого варианта есть ограничения и в будущем его могут перестать использовать. Кластеры, развернутые в Azure, защищены с помощью сертификатов X509, выданных в закрытой инфраструктуре открытых ключей, и объявления субъектом не всегда могут быть проверены решением Service Fabric (для обмена данными между кластером и службой). Для проверки требуется, чтобы политика сертификатов инфраструктуры открытых ключей была доступна для изучения.

Обновление шаблона Azure Resource Manager кластера и развертывание

Управляйте кластерами Service Fabric с помощью шаблонов Azure Resource Manager (ARM). Альтернативой, которая также использует артефакты JSON, является обозреватель ресурсов Azure. На портале Azure в настоящее время нет доступных аналогичных возможностей.

Если исходный шаблон, соответствующий существующему кластеру, недоступен, соответствующий шаблон можно получить на портале Azure. Перейдите в группу ресурсов, содержащей кластер, и выберите пункт Экспорт шаблона в меню Автоматизация слева. Затем выберите нужные ресурсы. Как минимум, следует экспортировать масштабируемый набор виртуальных машин и кластерные ресурсы. Созданный шаблон также можно скачать. Возможно, в шаблон потребуется внести изменения, чтобы он был полностью готов к развертыванию. Шаблон также может не совпадать с исходным. Это отражение текущего состояния кластерного ресурса.

Необходимо внести следующие изменения:

• Обновление определения расширения узла Service Fabric (в ресурсе виртуальной машины). Если кластер определяет несколько типов узлов, необходимо обновить определение каждого соответствующего масштабируемого набора виртуальных машин.
• Обновление определения кластерного ресурса.

Здесь представлены подробные примеры.

Обновление ресурсов масштабируемых наборов виртуальных машин

С:

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "thumbprint": "[parameters('certificateThumbprint')]",
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Кому:

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "commonNames": [
                                    "[parameters('certificateCommonName')]"
                                ],
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Обновление кластерного ресурса

В ресурсе Microsoft.ServiceFabric/clusters добавьте свойство certificateCommonNames с параметром commonNames и полностью удалите свойство certificate (со всеми его параметрами).

С:

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificate": {
              "thumbprint": "[parameters('certificateThumbprint')]",
              "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

Кому:

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificateCommonNames": {
                "commonNames": [
                    {
                        "certificateCommonName": "[parameters('certificateCommonName')]",
                        "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprintList')]"
                    }
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

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

Развертывание обновленного шаблона

Повторно разверните обновленный шаблон после внесения изменений.

$groupname = "sfclustertutorialgroup"

New-AzResourceGroupDeployment -ResourceGroupName $groupname -Verbose `
    -TemplateParameterFile "C:\temp\cluster\parameters.json" -TemplateFile "C:\temp\cluster\template.json" 

Достижение допустимого начального состояния для преобразования кластера с целью использования в объявлениях сертификатов на основе общего имени

Начальное состояние	Обновление 1	Обновление 2
У Thumbprint: OldCert1, ThumbprintSecondary: None и GoalCert дата NotBefore позднее, чем у OldCert1	Thumbprint: OldCert1, ThumbprintSecondary: GoalCert	-
У Thumbprint: OldCert1, ThumbprintSecondary: None и OldCert1 дата NotBefore позднее, чем у GoalCert	Thumbprint: GoalCert, ThumbprintSecondary: OldCert1	Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, где у OldCert1 дата NotBefore позднее, чем у GoalCert	Обновление до Thumbprint: GoalCert, ThumbprintSecondary: None	-
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, где у OldCert1 дата NotBefore позднее, чем у GoalCert	Обновление до Thumbprint: GoalCert, ThumbprintSecondary: None	-
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2	Удалите сертификат OldCert1 или OldCert2, чтобы получить состояние Thumbprint: OldCertx, ThumbprintSecondary: None	Продолжайте выполнять действия в новом состоянии

Примечание.

Для кластера с версией ниже 7.2.445 (7.2 CU4) в указанных выше состояниях замените NotBefore на NotAfter.

Инструкции по выполнению любого из этих обновлений см. в статье Управление сертификатами в кластере Azure Service Fabric.

Следующие шаги

• Дополнительные сведения о безопасности кластеров см. в статье Сценарии защиты кластера Service Fabric.
• Дополнительные сведения о смене сертификата с помощью общего имени.
• Дополнительные сведения о настройке автоматической замены в кластере.