Начнем с технической части повествования – чтобы народу было интересно и полезно почитать, а уже потом перейдем к «политическо-ИТшной» – это уже по желанию, но как по мне так смешно, что аж печально… 😉

Итак, в некоем решении используются Azure Functions, написанные на PowerShell Core (потому что все мои админы знакомы и легко могут модифицировать, развивать решение при необходимости) и в качестве безопасности (аутентификации пользователей) работающие со стандартной идентификацией от Azure AD при вызове того, что называется Http Trigger, т.е. функции, имеющей свой персональный URL, по которому ее и можно запустить, передав требуемые параметры.

Требуется – при развитии решения появилась потребность не только аутентифицировать пользователей, но и иметь некие аналоги аудита (кто какие функции вызывает) и ролевой модели (запрет некоторым людям вызывать функции или использовать глобальные параметры).

Аутентификация на базе Azure AD для Azure Functions включается в пару кликов и не требует какого-либо изменения кода самой Azure Functions – для функции вся аутентификация работает при описанном ниже сценарии «прозрачно», всю работу по аутентификации на себя берет «движок» Azure. Не путать, кстати, с опцией Identity, которая позволяет имперсонализировать сам исполняемый экземпляр Azure Functions в Azure и выполнять код под определенным аккаунтом в Azure, которому можно предоставлять разные права – чем, собственно, мы и пользуемся – используя Azure Functions для выполнения различных задач обслуживания, предоставляя толпе из L1 для выполнения базовых операций не доступ к порталу Azure и клиентским подпискам, а только к функциям, которые уже все сделают «как нужно и правильно»…

Но вернемся к аутентификации пользователей при вызове Azure Functions. Итак:

Заходим на основную страницу требуемой Azure Functions, переключаемся в закладку Platform Features, и там кликаем на опцию Authentication / Authorization

На открывшейся странице устанавливаем переключатель App Service Authentication в положение On и в появившемся ниже выпадающем списке Action to take when request is not authenticated выбираем опцию Log in with Azure Active Directory, а в следующем списке Authentication Providers кликаем на пункт Azure Active Directory / Not Configured

Откроется новое окно настроек – создания экземпляра приложения для аутентификации в Azure AD, где в Managed Mode выбираем опцию Express и далее, в появившихся ниже опциях, выбираем правильный каталог Azure AD (если в вашем профиле их несколько зарегистрировано), Managed Mode оставляем, как есть – Create New AD App – и оставляем имя по умолчанию.

Кликаем Ok в данном диалоге, ждем окончания процесса создания объекта, и в форме Authentication / Authorization, куда вас вернет портал, кликаем вверху на иконку Save. Опять таки – ждем окончания операции и получаем сконфигурированное приложение с аутентификацией от Azure AD. Теперь, при обращении к Azure Functions, которые зарегистрированы, как Http Trigger, Azure будет запрашивать у вызывающего пройти аутентификацию и предъявить аккаунт пользователя из указанной выше Azure Active Directory. Так что анонимные пользователи такую функцию теперь не вызовут.

НО! Такой сценарий достаточен только для «отсечения» анонимных пользователей, а вот если требуется какое-либо подобие RBAC внутри самих Azure Functions – например, пользователь аутентифицируется, но при этом часть параметров функции ему недоступна или доступ к данным внутри самой функции должен быть ограничен – здесь, увы, такая аутентификация не поможет. Да и вообще, у Azure нет толкового RBAC для Functions.

Т.е. после вызова функции вызов перенаправляется на аутентификацию в Azure AD и если все ок – управление передается на Azure Functions и нам надо теперь внутри исполняемой функции получить клейм пользователя и все атрибуты его учетной записи – ID в аутентифицирующей системе, имя, саму систему и прочие токены. При этом все это еще требуется получить в PowerShell.

И тут начинается самое интересное – хотя Microsoft со всех трибун кричит про внедрение Serverless решений, рассказывает про использование Azure Functions вместе с PowerShell для процессов автоматизации – в реальности никакой официальной документации от Microsoft, особенно фундаментальной, по теме Functions/PowerShell вы не найдете. В Интернете ее тоже нет, даже на любимом всеми StackOverflow – просто никто не использует решение, не смотря на громкие заявления Microsoft.

Нашел пару документов про работу с идентити/информацией аутентификации в Functions/Web Apps применительно к C#, но это нагромождение классов и вызовов было явно не релевантно для кода PowerShell. Чтобы понять всю глубину проблемы, стоит сказать, что ни я, ни моя команда – ни разу не девелоперы – только PowerShell скрипты для автоматизации процессов заказчиков и auto-healing, только хардкор, как, например, скриптик PowerShell на 1000 строк для правильного «развертывания всего» с соответствующими внутренностями VM. Для нас вообще удивительно, кстати, почему работа с тем же Azure Storage Queues в PowerShell пишется в 3 строки, а в C# сначала надо создать десяток классов при неочевидном выигрыше в производительности самой Functions. Но это уже лирика, а вывод простой – для людей, которые занимаются автоматизацией процессов на PowerShell, документации по разработке на сайте Microsoft совершенно недостаточно, приходится собирать по крупицам с разных источников, работать «методом тыка» или открыть тикет в саппорте. На том и порешили – продолжаем «копать» и обращаемся в саппорт.

Методом логического анализа кода («методом тыка») на C# обнаружилось, что чтобы работать cо всей информацией по аутентификации пользователя, вызывающего Functions с аутентификацией в Azure AD (как настроено выше) в PowerShell коде можно через Headers одной командой:

$Request.Headers

Ниже – представленный в JSON объект заголовка вызова Http Trigger в Azure Functions (тот самый $Request.Headers). Все поля, как на ладони и далее работаем с ними, как с обычным hashtable в PowerShell, т.е. получаем нужное значение по имени ключа (которым являются поля заголовка ниже).

Т.е., чтобы получить имя пользователя, его ID, его Access Token и т.п. в коде PowerShell – требуется максимум 1-2 команды:

$headersObj = $Request.Headers # get call’s headers

$username = $headersObj[“x-ms-client-principal-name”]   # get user account name

$userid = $headersObj[“x-ms-client-principal-id”]       # get user AAD ID

$userip = $headersObj[“x-forwarded-for”]                # get user IP

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

И тут начинается вторая часть истории – которая смешная и печальная, особенно в разрезе предыдущей моей истории про то, как Microsoft Ukraine заблокировала и удалила мои видео по курсу для сертификации AZ-900 по Azure (и продолжения истории c Microsoft Ukraine после).

Итак, открыл я кейс в Microsoft support по данной проблеме и вот выдержка переписки:

1. Я описываю проблему

2. И получаю от Microsoft Support ответ, что в моем сценарии (option 1, процесс конфигурирования которого и описан выше) такую информацию получить нельзя:

3. Причем, получив такой ответ – я уже 100% уверен в возможности получения этих данных, просто еще не имею на руках конкретного кода. И я отправляю письмо типа – «точно нельзя с опцией 1? Уверены?» и получаю от Microsoft support еще один отрицательный ответ – нет, вы не можете получить такую информацию (причем, происходит это через 5 дней, три из которых – рабочие):

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

И вот тут начинается самое интересное и «смешное». Мне сразу же перезванивает (буквально в течение 15 минут, до этого отвечал только по почте и то – через сутки) сотрудник службы поддержки Microsoft, который просит поделиться с ними решением проблемы и кодом!!! Т.е. Microsoft, который до этого активно удалял мои технические видео про Azure из принадлежащей мне группы в Facebook, а потом и удалил мой аккаунт из админов – про это читайте тут и тут – теперь вдруг другой рукой просит поделиться информацией со своей поддержкой?! Серьезно?! Я должен бесплатно делать за сотрудников Microsoft их работу? Той информацией, которую Microsoft в качестве базовой просто обязан опубликовать в документации, поскольку и продукт – платный, и везде, со всяких трибун, Microsoft кричит о важности безопасности вообще и правильного кода – в частности. И уж точно этой информацией должна владеть служба поддержки Microsoft…

Чтобы вам было еще смешнее – я и сейчас продолжаю получать письма с просьбами отдать код, последнее пришло уже сегодня, 25 декабря, через 9 дней после того, как я сообщил, что задача имеет решение. Вот реально?! За 9 дней внутри Microsoft собственный отдел поддержки не смог найти техническое решение и продолжает ждать у моря погоды – поделюсь ли я кодом?!

И самое смешное – Microsoft за последние 3-5 лет сократил практически весь высококвалифицированный технический персонал из своих локальных офисов ввиду того, что Azure поддержки не требует, его надо только продавать, а технической поддержкой пусть занимаются партнеры «за деньги». Azure, как показывает опыт, просто за бла-бла-бла девочек из маркетинга Microsoft не продается (про это я говорю тоже в первой серии курса AZ-900), а партнеры, при таких отношении, «экспертизе», «документации» и «поддержке» от Microsoft – точно не будут вкладываться в «прибыльный и простой бизнес Azure» и не будут развивать компетенции Azure, как и клиенты не горят желанием платить деньги «каким-то партнерам», один раз столкнувшись с подобным невежеством поддержки «самого Microsoft». И, особенно, партнерам не интересно это делать, если развитие компетенций не интересно самому Microsoft и даже поддержка Microsoft не в состоянии дать ответ на простой, как оказалось, вопрос.

И если объективно смотреть на ситуацию c поддержкой Azure, то можно смело сказать, исходя из своего опыта работы С Microsoft последние пару лет, что никакой реальной поддержки и технической компетенции «на местах» у Microsoft сейчас просто нет. Выгребайте сами. И иметь у себя классного специалиста по Azure в штате – это будет даже лучше и безопаснее, чем вам пришлют какого-то «технического консультанта» от Microsoft, который в реальности окажется «не пойми кто», как я уже писал во второй части большого поста про Microsoft.

Но и это еще не все про Microsoft и поддержку Azure… Читайте в следующем посте про развертывание Windows кластеров в Azure и про официальные скрипты от Microsoft.

Друге видео то теме Azure и ИТ-карьеры:

• Подготовка к Exam AZ-900 Azure Fundamentals – http://bit.ly/Exam-Az-900

• Доклады по серверным технологиям Microsoft Windows Server – http://bit.ly/WindowsServer_overview

• ИТ-карьера: как стать ИТ-специалистом, основные шаги для успешной карьеры в ИТ – http://bit.ly/ITcarriera_