Поделиться через

Управление сертификатами в кластерах Service Fabric

  • Статья

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

Необходимые компоненты

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

Заявление об отказе

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

Определение управления сертификатами

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

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

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

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

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

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

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

В частности, в ней рассматриваются указанные ниже темы.

  • Предположения о разделении установки атрибутов между владельцем и платформой
  • Длинный конвейер от выдачи сертификата до использования
  • Смена сертификатов. Почему, как и когда
  • какие проблемы могут возникнуть.

В этой статье не рассматриваются указанные ниже темы.

  • Защита доменных имен и управление ими
  • Регистрация в сертификатах
  • Настройка элементов управления авторизацией для принудительной выдачи сертификатов.

Для получения информации по этим темам обратитесь в центр регистрации (RA) вашей службы инфраструктуры открытых ключей (PKI). Если вы являетесь внутренним читателем Майкрософт, вы можете обратиться в службу безопасности Azure.

Роли и сущности, используемые в управлении сертификатами

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

В частности, владелец кластера должен убедиться в том, что:

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

Service Fabric, для своей части, допускает следующие обязанности:

  • поиск сертификатов, соответствующих объявлениям в определении кластера;
  • предоставление доступа к соответствующим закрытым ключам для сущностей, управляемых Service Fabric, на основе необходимости;
  • проверка сертификатов в строгом соответствии с установленными рекомендациями по безопасности и определением кластера;
  • создание оповещений о незавершенном истечении срока действия сертификатов или ошибках выполнения основных операций по проверке сертификатов;
  • проверка (в некоторой степени) того, что связанные с сертификатами аспекты определения кластера соответствуют базовой конфигурации узлов.

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

Путь сертификата

Рассмотрим вкратце процесс продвижения сертификата от выдачи до использования в рамках кластера Service Fabric.

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

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

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

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

  5. Служба Service Fabric (выполняющаяся с повышенными правами на каждом узле) предоставляет доступ к сертификату для разрешенных сущностей Service Fabric. Они назначаются локальными группами и разбиваются между объектами ServiceFabricAdministrators и ServiceFabricAllowedUsers.

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

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

  8. Агент подготовки или владелец кластера также отвечает за очистку и удаление неиспользуемых сертификатов.

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

Процесс выдачи и подготовки сертификатов показан на следующих схемах.

Для сертификатов, объявленных по отпечатку

Схема подготовки сертификатов, объявленных по отпечатку.

Для сертификатов, объявленных по общему имени субъекта

Схема подготовки сертификатов, объявленных по общему имени субъекта.

Регистрация сертификата

Тема регистрации сертификата подробно рассматривается в документации по Key Vault. Здесь приведена сводка для обеспечения непрерывности и более удобного использования.

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

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

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

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

    • В {vaultUri}/certificates/{name}: сертификат, включая общий ключ и метаданные
    • В {vaultUri}/keys/{name}: закрытый ключ сертификата, доступный для криптографических операций (переносить/не переносить, подпись/проверка)
    • В {vaultUri}/secrets/{name}: сертификат, включая его закрытый ключ, доступный для загрузки в виде незащищенного PFX-файла или PEM-файла.

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

Подготовка сертификата

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

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

  • Нерегламентированный механизм (ad-hoc): оператор получает сертификат из хранилища ключей (как PFX/PKCS #12 или PEM) и устанавливает его на каждом узле.

    Нерегламентированный механизм (ad-hoc) не рекомендуется использовать от области безопасности до доступности по нескольким причинам, которые здесь не обсуждаются. Дополнительные сведения см. в разделе Часто задаваемые вопросы о масштабируемых наборах виртуальных машин Azure.

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

    Примечание.

    Этот подход позволяет предоставлять только секреты с версиями.

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

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

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

Существуют и другие механизмы подготовки, но упомянутые здесь подходы являются в настоящее время принятыми вариантами для кластеров Azure Service Fabric.

Использование и мониторинг сертификатов

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

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

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

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

Ротация сертификатов

Примечание.

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

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

Service Fabric помогает в этом процессе, генерируя предупреждение о том, что дата окончания срока действия сертификата, используемого в настоящее время в кластере, наступает раньше, чем заранее определенный интервал. Агент автоматической подготовки, расширение виртуальной машины Key Vault, настроенное для наблюдения за сертификатом хранилища ключей, периодически опрашивает хранилище ключей, обнаруживает смену, а также извлекает и устанавливает новый сертификат. Для подготовки, выполняемой с помощью функции секретов VM/VMSS, авторизованный оператор должен обновить VM/VMSS с помощью версии URI Key Vault, соответствующего новому сертификату.

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

  • Для новых соединений, а также в кластере среда выполнения Service Fabric обнаруживает и выбирает самый последний выданный сертификат (самое большое значение свойства NotBefore). Это изменение, произошедшее в предыдущих версиях среды выполнения Service Fabric.

  • Существующие соединения хранятся в активном состоянии, или разрешены в течение естественного срока действия, или удаляются; внутренний обработчик будет уведомлен о существовании нового соответствия.

Примечание.

В настоящее время, начиная с версии 7.2 CU4+, Service Fabric выбирает сертификат с наибольшим (самым последним выпущенным) значением свойства NotBefore. До версии 7.2 CU4 Service Fabric выбирал действующий сертификат с наибольшим (последним истекающим) значением NotAfter.

Это выражается в следующих важных наблюдениях.

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

    • Наблюдателю может не сразу стать очевидно, что измененный сертификат полностью заменил своего предшественника. Единственным способом принудительной замены сертификата, используемым в настоящее время, является перезагрузка хост-компьютеров. Недостаточно просто перезапустить узлы Service Fabric, так как это не влияет на компоненты режима ядра, которые формируют подключения аренды в кластере. Кроме того, перезапуск VM/VMSS может привести к временной потере доступности. Для сертификатов приложений достаточно перезапустить только соответствующие экземпляры приложения.

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

Очистка сертификата

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

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

  • Более ранние версии сертификатов, подготовленных с помощью расширения виртуальной машины Key Vault, могут присутствовать или отсутствовать на узле VM или VMSS. Агент извлекает и устанавливает только текущую версию и не удаляет сертификаты. Повторное создание образа узла, которое обычно выполняется ежемесячно, сбрасывает хранилище сертификатов к содержимому образа ОС, поэтому предыдущие версии будут неявно удалены. Однако следует учесть, что при масштабируемом наборе виртуальных машин будет установлена только текущая версия наблюдаемых сертификатов. Не следует рассчитывать на однородность узлов в отношении установленных сертификатов.

Упрощение управления: пример с автоматической заменой

До сих пор в этой статье описывались механизмы и ограничения, обрисовывались в общих чертах сложные правила и определения и делались значительные прогнозы простоев. Теперь пришло время настроить автоматическое управление сертификатами, чтобы избежать всех этих проблем. Мы сделаем это в контексте кластера Azure Service Fabric, работающего в масштабируемом наборе виртуальных машин "платформа как услуга" (PaaS) версии 2, с использованием Key Vault для управления секретами и использования управляемых удостоверений, как показано ниже.

  • Проверка сертификатов изменяется с закрепления отпечатков на субъект + закрепление издателя. Любой сертификат с определенным субъектом от определенного издателя является одинаково доверенным.
  • Сертификаты регистрируются в хранилище доверия и принимаются из него (Key Vault), и обновляются агентом (в этом случае расширением виртуальной машины KeyVault).
  • Подготовка сертификатов изменяется: от версии на основе времени развертывания и на основе версий (как выполнено с помощью поставщика вычислительных ресурсов Azure) до версии на основе состояния после развертывания с использованием универсальных кодов ресурсов (URI) младших версий KeyVault.
  • Доступ к хранилищу ключей предоставляется посредством управляемых и назначаемых пользователем удостоверений, которые создаются и назначаются масштабируемому набору виртуальных машин в процессе развертывания.
  • После развертывания агент (расширение виртуальной машины Key Vault) опрашивает и обновляет наблюдаемые сертификаты на каждом узле масштабируемого набора виртуальных машин. Таким образом, смена сертификатов полностью автоматизирована, так как Service Fabric автоматически выбирает последний действительный сертификат.

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

Примечание.

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

Примечание.

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

Начальная точка

Для краткости допустим следующее начальное состояние.

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

Вот фрагмент JSON из шаблона, соответствующего такому состоянию. В этом фрагменте опущены многие обязательные параметры и показаны только аспекты, связанные с сертификатами.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

В приведенном выше коде по сути говорится, что сертификат с отпечатком json [parameters('primaryClusterCertificateTP')] , найденный в универсальном коде ресурса (URI) хранилища KeyVault json [parameters('clusterCertificateUrlValue')] , объявляется как единственный сертификат кластера по отпечатку.

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

Настройка требуемых ресурсов

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

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

Сначала определите назначенное пользователем удостоверение (значения по умолчанию приведены в качестве примеров). Дополнительные сведения см. в официальной документации.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

Затем предоставьте этому удостоверению доступ к секретам хранилища ключей. Актуальные сведения см. в официальной документации.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

На следующем этапе будут выполнены следующие действия:

  • присвоение удостоверения, назначаемого пользователем, для масштабируемого набора виртуальных машин;
  • объявление зависимости масштабируемого набора виртуальных машин для создания управляемого удостоверения и для результата предоставления ему доступа к хранилищу ключей;
  • объявление расширения виртуальной машины Key Vault, требующее получение наблюдаемых сертификатов при запуске (дополнительные сведения см. в официальной документации Расширение виртуальной машины Key Vault для Windows);
  • обновление определения расширения виртуальной машины Service Fabric, чтобы оно зависело от расширения виртуальной машины Key Vault, и преобразование объявления сертификата кластера из отпечатка в общее имя.

Примечание.

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

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

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

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

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

На этом этапе можно выполнить вышеупомянутые обновления в одном развертывании. Служба поставщика ресурсов Service Fabric разделяет обновление кластера на несколько этапов, как описано в разделе Преобразование сертификатов кластера с отпечатка на общее имя.

Анализ и наблюдения

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

Сведения о подготовке сертификата

Расширение виртуальной машины Key Vault в качестве агента подготовки выполняется непрерывно с предварительно заданной периодичностью. При сбое получения наблюдаемого сертификата выполняется переход к следующему в строке, а затем в режим гибернации до следующего цикла. Для расширения виртуальной машины Service Fabric в качестве агента начальной загрузки кластера требуются объявленные сертификаты, прежде чем кластер станет доступен. Это, в свою очередь, означает, что расширение виртуальной машины Service Fabric может выполняться только после успешного получения сертификатов кластера, обозначенных здесь предложением json "provisionAfterExtensions" : [ "KVVMExtension" ]" и параметром json "requireInitialSync": true расширения виртуальной машины Key Vault.

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

Связывание сертификатов, пояснение

Возможно, вы обратили внимание на флаг linkOnRenewal расширения виртуальной машины Key Vault и его значение false. Здесь рассматривается функция этого флага и его влияние на работу кластера. Это поведение характерно для операционной системы Windows.

В соответствии с определением:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

Сертификаты, используемые для установки подключения TLS, как правило, предоставляются в виде дескриптора от поставщика поддержки безопасности S-канала. Это означает, что клиент не обращается напрямую к закрытому ключу самого сертификата. S-канал поддерживает перенаправление или связывание учетных данных в форме расширения сертификата CERT_RENEWAL_PROP_ID.

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

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

Если связывание включено, расширение виртуальной машины KeyVault при извлечении наблюдаемого сертификата из хранилища ключей попытается найти совпадающие существующие сертификаты, чтобы связать их с помощью свойства расширения обновления. Совпадение (исключительно) основано на альтернативном имени субъекта (SAN) и работает следующим образом. Предположим, имеется два сертификата, как показано в следующих примерах: A: Имя сертификата (CN) = "Аксессуары Алисы", SAN = {"alice.universalexports.com"}, обновление = '' B: CN = "Биты Боба", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, обновление = ''

Предположим, сертификат C извлекается с помощью расширения виртуальной машины Key Vault: CN = "Вредоносная программа Мэллори", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Список SAN сертификата А полностью входит в C, поэтому A.renewal (обновление) = C.thumbprint (отпечаток). Список SAN сертификата B имеет общее пересечение с сертификатом C, но не полностью входит в него, поэтому B.renewal (обновление) остается пустым.

Любая попытка вызвать AcquireCredentialsHandle (S-канал) в этом состоянии в сертификате А фактически приводит к отправке сертификата C на удаленную сторону. Для среды Service Fabric в подсистеме транспорта кластера используется S-канал для взаимной проверки подлинности, поэтому описанное выше поведение напрямую влияет на фундаментальное взаимодействие кластера. Продолжая приведенный выше пример, предположив, что сертификат А является сертификатом кластера, возникают следующие зависимости:

  • если закрытый ключ сертификата C не дает доступ к учетной записи, от имени которой работает среда Service Fabric, можно увидеть ошибки при получении закрытого ключа (SEC_E_UNKNOWN_CREDENTIALS или аналогичного);
  • если закрытый ключ сертификата C доступен, будут отображаться ошибки авторизации, возвращенные другими узлами (сертификат не совпадает, без авторизации и т. д.).

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

Для предотвращения таких инцидентов рекомендуется следующее:

  • не смешивайте альтернативные имена субъекта разных сертификатов хранилища, каждый сертификат хранилища должен иметь свое назначение, а их субъект и имя SAN должны это отражать;

  • включить общее имя субъекта в список SAN (CN=<subject common name>);

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

    Примечание.

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

Зачем использовать управляемое удостоверение, назначенное пользователем? Каковы последствия использования этой функции?

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

Расширение виртуальной машины Service Fabric, которое загружает кластер, зависит от работы расширения виртуальной машины Key Vault, которое в свою очередь зависит от успешной загрузки наблюдаемых сертификатов.

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

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

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

Устранение неполадок и часто задаваемые вопросы

Вопрос. Как программно регистрироваться в сертификате, управляемом KeyVault?

Найдите имя издателя в документации по KeyVault, а затем замените его в следующем скрипте:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName

Вопрос. Что происходит при выдаче сертификата необъявленным или неопределенным издателем? Где можно получить полный список активных издателей для конкретной инфраструктуры PKI?

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

Как правило, инфраструктура PKI публикует и поддерживает заявление о сертификации в соответствии с IETF RFC 7382. Среди прочих сведений в заявление будут включены все активные издатели. Получение этого списка программным способом может отличаться от одной инфраструктуры PKI к другой.

Для инфраструктур PKI внутренних объектов-получателей Майкрософт обратитесь к внутренней документации по конечным точкам и пакетам SDK, используемым для получения полномочных издателей. Ответственность за периодическую проверку этого списка, а также за то, чтобы убедиться, что определение кластера включает в себя всех ожидаемых издателей, несет владелец кластера.

Вопрос. Поддерживаются ли несколько инфраструктур PKI?

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

Вопрос. Что делать, если текущий сертификат кластера не выдан ЦС или не имеет назначенного субъекта?

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