Понимание идентификации рабочих процессов

7 мин

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

Почему рабочий процесс должен пройти проверку подлинности?

При развертывании файла Bicep вы в сущности поручаете диспетчеру ресурсов Azure создание или изменение ресурсов Azure. В примере сценария вы создали файл Bicep для развертывания веб-сайта вашей компании по производству игрушек. Файл Bicep декларирует ресурсы, включая план службы приложений Azure, веб-приложение и экземпляр Application Insights.

При развертывании файла Resource Manager проверяет, существуют ли ресурсы. Если они этого не делают, Resource Manager создает их. Если какие-либо ресурсы уже существуют, Resource Manager гарантирует, что их конфигурация соответствует конфигурации, указанной в файле Bicep.

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

Возможность выполнения развертываний. Развертывания — это ресурсы с типом Microsoft.Resources/deployments.
Возможность создавать и изменять планы и приложения службы приложений.
Возможность создавать и изменять экземпляры системы Application Insights.

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

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

Типы идентичностей

Служба Microsoft Entra ID управляет идентификационными данными для Azure. Некоторые из основных типов идентичностей:

Идентификации пользователей: пользователь представляет человека, который обычно выполняет интерактивную аутентификацию с помощью браузера. Пользователи часто выполняют дополнительные проверки безопасности при входе, такие как многофакторная проверка подлинности (MFA) и условный доступ на основе их расположения или сети.
группы: группа представляет совокупность пользователей. Группы не проходят проверку подлинности напрямую, но предоставляют удобный способ назначения разрешений набору пользователей вместе.
Идентификации рабочих процессов. Рабочая нагрузка – это автоматизированный процесс или система, которой обычно не управляет человек напрямую. Рабочая нагрузка может войти в Microsoft Entra ID, но нет человека, который бы мог войти и взаимодействовать с процессом аутентификации. Учетные записи для рабочих нагрузок не имеют многофакторной аутентификации или других подобных защит, так как эти функции требуют от человека совершить действие для подтверждения своей личности.

Этот модуль посвящен идентификациям рабочей нагрузки.

Управляемые удостоверения

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

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

При работе с рабочими процессами развертываний обычно не используются управляемые удостоверения. Для управляемых удостоверений требуется, чтобы вы владели ресурсами Azure, выполняющими развертывания, и управлять ими. При работе с GitHub Actions обычно используется общая инфраструктура, которую предоставляет Корпорация Майкрософт или GitHub. Однако при использовании идентификации рабочей нагрузки с GitHub Actions вы можете получить основное преимущество управляемых удостоверений: отсутствие необходимости в управлении учетными данными.

Совет

В других частях вашего решения, если у вас есть выбор между использованием управляемого удостоверения или учетной записи службы, наиболее предпочтительно использовать управляемое удостоверение. С управляемыми удостоверениями проще работать, и они обычно более безопасны.

Почему вы просто не можете использовать учетную запись пользователя?

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

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

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

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

Предупреждение

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

По этим причинам встроенные задачи GitHub Actions, взаимодействующие с Azure, не позволяют предоставлять учетные данные учетной записи пользователя. Им нужно использовать идентичность рабочей нагрузки.

Как работают идентификаторы рабочей нагрузки?

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

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

Когда вы создаете приложение и сообщаете о нем Microsoft Entra ID, вы создаете объект под названием регистрация приложения. Регистрация приложения представляет приложение в идентификаторе Microsoft Entra.

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

Когда рабочий процесс GitHub Actions должен пройти проверку подлинности, он обращается к идентификатору Microsoft Entra через GitHub. GitHub сообщает Microsoft Entra ID имя организации и репозитория GitHub, а также некоторые другие сведения. Если вы настроили федеративные учетные данные, соответствующие сведениям репозитория, Microsoft Entra проверяет подлинность рабочего процесса развертывания. Рабочий процесс может использовать разрешения, назначенные приложению.

Совет

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

Вы также можете создать объект субъекта-службы в клиенте Microsoft Entra. Учётная запись службы похожа на копию приложения для вашего собственного арендатора Microsoft Entra. Принципы службы и приложения тесно связаны. Позже в этом модуле вы будете использовать учетную запись службы при предоставлении вашему рабочему процессу разрешения на доступ к Azure.

Заметка