Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приведены рекомендации по управлению требованиями к конфигурации сетевых функций с помощью Диспетчера служб Оператора Azure. Это включает в себя проектирование оптимальных схем групп конфигурации (CGS), значений групп конфигурации (CGVs) и шаблонов ресурсов сети (NFS). Имейте в виду эти методики при подключении и развертывании NFS.
Подход к конфигурации
При разработке ресурсов конфигурации следует учитывать следующие рекомендации по мета-схеме:
- Сначала выберите параметры для предоставления оператору.
- Эмпирическое правило заключается в том, чтобы выделять параметры, которые поддерживаются прямой операцией, такие как
helm value. - Подавление параметров, поддерживаемых другим агентом, например
cloudinit userdata.
- Эмпирическое правило заключается в том, чтобы выделять параметры, которые поддерживаются прямой операцией, такие как
- Отсортируйте параметры по категориям: относящиеся к сайту, экземпляру и безопасности.
- Убедитесь, что параметры не перекрываются между наборами.
- Определение обязательных и необязательных параметров.
- Для необязательных параметров определите разумное значение по умолчанию.
- Чтобы предотвратить предоставление секретов, убедитесь в правильной настройке параметров безопасности.
методология One-CGS
Исходная рекомендация заключалась в использовании только одного набора CGS/CGV для всего NF. Этот подход объединяет параметры, относящиеся к сайту, экземплярам и безопасности. Только в редких случаях, когда служба имела несколько NFS, использовались несколько наборов. Многие партнеры успешно внедрили этот подход, и его поддержка продолжается. Однако этот подход не скрывает секреты. Все значения конфигурации хранятся в виде обычного текста и отображаются с помощью большинства методов Azure.
подход Three-CGS
Теперь рекомендуется использовать по крайней мере три набора CGS/CGV, упорядочивая параметры следующим образом:
Параметры, относящиеся к сайту
- Примерами являются IP-адреса и уникальные имена.
- Использует CGS/CGV без секретов.
- Сохраняет значения в виде обычного текста во время развертывания.
Параметры для конкретного экземпляра
- Примеры включают время ожидания и уровни отладки.
- Использует CGS/CGV без секретов.
- Сохраняет значения в виде обычного текста во время развертывания.
Параметры, относящиеся к безопасности
- Примеры включают пароли и сертификаты.
- Использует CGS/CGV с шифровальными ключами.
- Сохраняйте значения в Azure Key Vault (AKV), чтобы скрыть их во время развертывания.
Предупреждение
- При использовании секретов рекомендуется ограничить доступ к области
Microsoft.Resources/deployments/exportTemplate/actionуправления доступом на основе ролей (RBAC).
CGS без секретов
В этом примере показано, как CGS раскрывает параметры abc, xyz и qwe. Два из параметров имеют значения по умолчанию, а один — обязательный.
{
"type": "object",
"properties": {
"abc": {
"type": "integer",
"default": 30
},
"xyz": {
"type": "integer",
"default": 40
},
"qwe": {
"type": "integer"
}
}
"required": "qwe"
}
CGV без секретов
В этом примере показаны входные данные CGV, предоставляемые оператором во время развертывания CGV для удовлетворения предыдущих CGS.
{
"qwe": 20
}
В этом примере показан визуализированный ресурс CGV, созданный после завершения развертывания CGV.
{
"abc": 30,
"xyz": 40,
"qwe": 20
}
CGV с секретами без AKV
Если AKV не используется, рассмотрите следующие требования к шаблону Azure Resource Manager (ARM), чтобы обеспечить скрытие значений секретов на протяжении всего жизненного цикла ресурсов CGV.
- Чтобы содержать все секреты, определите параметр объекта с помощью
"type": "secureObject".- Эта конфигурация скрывает отображение секретов в качестве параметров шаблона.
В этом примере показано, как определить параметр secretCgvContentобъекта.
"parameters": {
"secretCgvContent": {
"type": "SecureObject"
}
}
Замечание
- Не гидратуйте
secretCgvContentс помощью функции bicep loadJsonContent(). - Не включайте
SecureObjectпараметр в определение переменной.
- В свойствах ресурсов CGV используйте
configurationType: 'Secret'и"secretConfigurationValue": "[string(parameters('secretCgvContent'))]".- Эта конфигурация предотвращает отображение секретных данных с помощью большинства пользовательских интерфейсов Azure.
В этом примере показано, как передать все секреты в объект secretCgvContent в ресурс CGV.
{
"type": "Microsoft.HybridNetwork/configurationGroupValues",
"properties": {
"configurationType": "Secret"
"secretConfigurationValue": "[string(parameters('secretCgvContent'))]"
}
}
CGV с секретами с AKV
Где используется AKV, рассмотрите следующие требования к шаблону ARM, чтобы правильно скрыть секретные значения на протяжении всего жизненного цикла ресурса CGV.
- Определите строку
parameterдля каждого секрета и одного объектаvariableдля сбора всех секретных значений.- Переменная объекта содержит только ссылку на строку параметра.
В этом примере показано, как определить параметр secretPassword1 , содержащийся в переменной secretVal.configurationValueобъекта.
"parameters": {
"secretPassword1": {
"type": "string"
}
}
"variables": {
"configurationValue": {
"secretVal": {
"elastic_passwd": "secretPassword1"
}
}
}
- Для ввода параметров используйте ссылку на шаблон AKV вместо секрета обычного текста.
- Эта конфигурация скрывает отображение секретов в виде переменных шаблона.
В этом примере показано, как определить секрет с помощью секрета secretPassword1 и ключа AKV.
"secretPassword1": {
"reference": {
"keyVault": {
"id": "/subscriptions/xxx/resourceGroups/yyy/providers/Microsoft.KeyVault/vaults/zz"
},
"secretPassword1": "<akv-secret-key>"
}
}
- В свойствах ресурсов CGV используйте
configurationType: 'Secret'и"secretConfigurationValue": "string(secretVal.configurationValue)".- Эта конфигурация предотвращает отображение секретных данных с помощью большинства пользовательских интерфейсов Azure.
В этом примере показано, как передать все секреты из объекта secretVal.configurationValue в новый CGV.
{
"resources": [ {
"type": "Microsoft.HybridNetwork/configurationGroupValues",
"properties": {
"configurationType": "Secret"
"secretConfigurationValue": "string(secretVal.configurationValue)"
}
}
]
сетевые функции с секретами
Рассмотрим следующие требования к шаблону ARM, чтобы правильно скрыть значения секретов во всем жизненном цикле ресурсов networkFunctions.
- Используйте
"type": "secureObject"в шаблоне для параметровsecretValuesиconfig- Эта конфигурация скрывает отображение секретов в качестве параметров шаблона.
"parameters": {
"nfValues": {
"type": "object"
},
"siteSpecificValues": {
"type": "object"
},
"secretValues": {
"type": "secureObject"
},
"config": {
"type": "secureObject",
"defaultValue": "[union(parameters('nfValues'), parameters('siteSpecificValues'), parameters('secretValues'))]"
}
}
Замечание
- Не гидратуйте
secretValuesс помощью функции bicep loadJsonContent(). - Не включайте
SecureObjectпараметр в определение переменной.
- В разделе свойств ресурсов networkFunctions используйте
configurationType: 'Secret'и"secretDeploymentValues": "[string(parameters('config'))]".- После развертывания сетевой функции эта конфигурация предотвращает отображение секретных данных с помощью большинства пользовательских интерфейсов Azure.
"resources": [
{
"type": "Microsoft.HybridNetwork/networkFunctions",
"configurationType": "Secret",
"secretDeploymentValues": "[string(parameters('config'))]",
}
]
Общие сведения о схеме JSON
Схема JSON — это стандарт IETF, который предоставляет формат данных JSON, необходимых для приложения, и способов взаимодействия с ним. Применение таких стандартов для документа JSON помогает обеспечить согласованность и допустимость данных в данных JSON.
Где используется схема JSON?
- Диспетчер служб Azure использует нотацию схемы JSON в качестве мета-схемы в
schemaDefinitionсвойствах объекта CGSConfigurationGroupSchemaPropertiesFormat. - Диспетчер служб оператора Azure позволяет конструктору и издателю указывать схему JSON, когда оператор должен предоставлять данные (значения JSON) во время создания экземпляра сетевой службы сайта (SNS) или NF.
- Диспетчер служб оператора Azure позволяет свойства мета-схемы быть необязательными или обязательными. Если свойство отмечено
required, его необходимо указать в значениях JSON.
Какие ключевые слова JSON поддерживаются?
Для мета-схемы CGS Диспетчер служб Azure реализует поддержку стандартных ключевых слов JSON на основе типа:
- Для типов объектов поддержка ключевых слов ограничена политикой фильтра. См. объект в справочнике по схеме JSON.
- Для строковых типов поддержка ключевых слов не ограничена или фильтруется. См. string в справочнике по JSON-схеме.
- Для числовых типов поддержка ключевых слов не ограничена или фильтруется. См. числовые типы в справочнике по схеме JSON.
Необязательные и обязательные поля
Свойство объявляется необязательным путем включения required ключевого слова, который не включает необязательное свойство. Если ключевое required слово не указано, все свойства считаются обязательными. Для поддержки необязательного типа свойства требуется по крайней мере один обязательный тип свойства.
{
"type": "object",
"properties": {
"abc": {
"type": "integer",
"default": 30
},
"xyz": {
"type": "string",
"default": "abc123"
}
}
"required": ["abc"]
}
Значения по умолчанию в схеме JSON
Для необязательных свойств Диспетчер служб Оператора Azure реализует настраиваемый метод обработки значений по умолчанию. Если значение по умолчанию определено в мета-схеме CGS, диспетчер служб Azure использует это значение, где свойство отсутствует или не определено в входных данных CGV. Логика проверяющего средства Диспетчера операторов Azure по сути гидратирует значение CGV со значением по умолчанию, если оператор не предоставляет значение.
Определение значений по умолчанию
Значения по умолчанию должны быть указаны внутри свойств или внутри элементов массива. В следующем примере показаны значения по умолчанию с типами целочисленных и строковых свойств:
{
"type": "object",
"properties": {
"abc": {
"type": "integer",
"default": 30
},
"xyz": {
"type": "string",
"default": "abc123"
}
}
}
Правила определения значений по умолчанию
При проверке значения по умолчанию применяются следующие правила. Учитывайте эти правила при использовании значений по умолчанию для обеспечения ожидаемых результатов.
- Значение по умолчанию не должно применяться к обязательному свойству.
- Значение по умолчанию вычисляется в порядке сверху вниз, из которого сначала отображается ключевое слово.
- Если в входном CGV существует значение свойства, только дочерние элементы этих свойств оцениваются на предмет значений по умолчанию.
- Где значение свойства не существует в входном CGV, вычисляется значение по умолчанию вместе с дочерними элементами.
- Где значение свойства является типом
object, и его ключ не существует в входном CGV, значения по умолчанию для объекта не оцениваются.