Нюанс работы с задачей " Azure Key Vault" в Azure DevOps

В своём проекте я столкнулся с необходимостью извлекать секреты из Azure Key Vault (AKV), который изолирован внутри виртуальной сети. Если коротко, то это очень частый сценарий, используемый для повышения безопасности сервисов Azure и AKV в частности.

Заметка: Self-hosted агент мы не рассматриваем.

Агенты Azure DevOps (AzDO) не являются доверенным сервисом для Azure, поэтому настройка "Allow Trusted Microsoft Services to bypass this firewall." для агентов AzDO не работает. 

Если вы использовали Variable groups для инъекции секретов в Pipelines/Release - они, при использовании изолированного AKV, работать перестанут.

В этом случае поможет комбинация задач, из которых: 

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

Есть нюанс: обратите внимание на настройку "Make secrets available to whole job"

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

Неожиданные символы при работе с ARM template для API management

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

Неожиданно для себя я получил какое-то невменяемое сообщение об ошибке а-ля неопознанные команды и т.д. Сначала я заглянул в шаблон через Notepad, но ничего не обнаружил, однако, каково было моё удивление, когда я открыл тот же шаблон в Visual Studio Code.

Изменения производились через PowerShell скрипт и он был всему виной. Другого объяснения у меня не было. 

Происходила замена символа одинарной кавычки на код.

Очень интересно то, что кодированные кавычки появлялись уже после чтения файла, а не после его сохранения.

Проблема решилась достаточно банально.

Get-AzApiManagementPolicy не возвращает политику для области API при наличии параметра -ApiId

Краткая заметка о работе с PowerShell Cmdlets для API management.

Замечено, что команда Get-AzApiManagementPolicy -ApiId "<api_id"> -Context $apimContext может не вернуть ничего в случае, когда политика для конкретного API имеет конфигурацию по-умолчанию.

Стоит добавить что-либо разумное и команда начинает возвращать состав политики.

Неправильный артифакт может скачиваться с Bamboo при определённых обстоятельствах

Забавный баг обнаружился при работе с Google Chrome и Bamboo.

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

 

Smart Screen выдаёт "Publisher: Unknown" при попытке установить собранный MSI или Exe файл

Очень часто встречался с ситуацией, когда люди подписав MSI или EXE с помощью signtool.exe из Windows SDK жаловались на то, что Windows Smart Screen выдаёт в сообщении   "Publisher: Unknown".

Проблема решается достаточно легко даже для самоподписанного сертификата:

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

Ошибка "ServiceExists" при развёртывании Azure API management с помощью ARM template

Можно столкнуться с подобной проблемой при переразвёртывании окружений с помощью ARM templates.

Вызывается данная проблема из-за фунеционала "Soft delete" для сущностей APIM, который реализован в Azure. По умолчанию, удалённый объект сохраняется до 48 часов, чтобы его можно было восстановить, если удаление было случайным.

В тоже время, это мешает развернуть APIM  с таким же именем.

Решить эту проблему можно перейдя по ссылке API ниже и выполнив пару простых действий (указать регион, где был размещён APIM и его имя). Это API позволяет вычистить всё удалённые сущности.

https://docs.microsoft.com/en-us/rest/api/apimanagement/2020-06-01-preview/deletedservices/purge#code-try-0

Кстати, замечу, что для многих сервисов Azure есть разные интересные API,  которые могут помочь решить проблему, если az cli, PowerShell или портал не позволяют добиться желаемого.

Быстрые заметки #4: Azure B2C custom policies

Забавное поведение "склеивания" или наследования замечено для technical profiles в Azure B2C.

К примеру, у меня есть два MultiSelect Checkbox. Если я полностью определяю technical profile в TFE.xml для получения пользовательского ввода, то Checkbox будет внизу страницы, т.к. перед ними будут идти другие claims.

Но если я использую механизм наследования, когда из TFB.xml технический профайл наследуется TFE.xml, где содержаться 4 дополнительных клейма и Checkbox, то Checkbox уедут вверх формы.

UPDATE #1 Очень интересно, но похоже проблема самоустранилась. Не думаю, что это кэш браузера, т.к. использовался Incognito режим. Что-то влияло на поведение формы... Может быть CSS, который применялся для создания надписи внизу формы.

UPDATE #2 Помучил нашего веб-девелопера, оказывается, для того, чтобы решить проблему пришлось гвоздями прибить Check-box в CSS к нижней грани:

.terms-and-policy {​​​​​​​

margin-top: 150px;

margin-bottom: -20px;

font-weight: 600;

}​​​​​​​

li.CheckboxMultiSelect {​​​​​​​

left: 45px;

right: 45px;

}​​​​​​​

li.CheckboxMultiSelect input ~ label {​​​​​​​

margin-right: 30px;

}​​​​​​​

li.CheckboxMultiSelect:nth-of-type(1) {​​​​​​​

position: absolute;

bottom: 130px;

}​​​​​​​

li.CheckboxMultiSelect:nth-of-type(2) {​​​​​​​

position: absolute;

bottom: 70px;

}​​​​​​

Так что, поведение без CSS будет, как описано выше.