워크로드 ID 이해

7분

배포 워크플로, 애플리케이션 및 소프트웨어를 인증하려면 특별한 방법이 필요합니다. 이 단원에서는 배포 워크플로에 워크로드 ID가 중요한 이유, 워크로드 ID가 Azure의 보안 모델에 어떻게 부합하는지, 작동 방식에 대해 알아봅니다.

워크플로가 인증해야 하는 이유는 무엇인가요?

Bicep 파일을 배포할 때 Azure Resource Manager에 Azure 리소스를 만들거나 수정하도록 효과적으로 요청합니다. 예제 시나리오에서는 Bicep 파일을 만들어서 토이 회사의 웹 사이트를 배포했습니다. Bicep 파일은 Azure App Service 계획, 앱 및 Application Insights 인스턴스를 포함하는 리소스를 선언합니다.

파일을 배포할 때 Resource Manager는 리소스가 있는지 확인합니다. 그렇지 않으면 Resource Manager가 생성합니다. 리소스가 이미 있는 경우 Resource Manager는 해당 구성이 Bicep 파일에서 지정한 구성과 일치하는지 확인합니다.

이러한 모든 작업은 Azure 리소스에 액세스하고 수정하기 때문에 권한이 필요합니다. 배포에 필요한 특정 권한은 Bicep 파일에 포함된 항목에 따라 달라집니다. 토이 회사의 웹 사이트에 대한 예제 파일을 배포하려면 배포하려는 리소스 그룹 내에서 다음 권한이 있어야 합니다.

배포를 만들 수 있는 권한 배포는 Microsoft.Resources/deployments형식의 리소스입니다.
App Service 계획 및 앱을 만들고 수정하는 기능입니다.
Application Insights 인스턴스를 만들고 수정하는 기능입니다.

지금까지 Azure CLI 또는 Azure PowerShell을 사용하여 Bicep 파일을 직접 배포했을 것입니다. 이러한 도구를 사용하는 경우 일반적으로 사용자 고유의 사용자 계정을 사용하고 브라우저를 사용하여 인증합니다. 이는 사용자 고유의 ID를 사용하여 호출됩니다. 배포를 제출할 때 Azure는 ID에 Bicep 템플릿이 지정한 작업을 수행하는 데 필요한 권한이 있는지 확인합니다.

GitHub Actions 배포 워크플로로 이동한 후에는 워크플로가 직접 개입 없이 배포를 실행하므로 다른 유형의 ID를 사용해야 합니다.

ID 유형

Microsoft Entra ID는 Azure의 ID를 관리하는 서비스입니다. 몇 가지 주요 ID 유형은 다음과 같습니다.

사용자 ID: 사용자는 일반적으로 브라우저를 사용하여 대화형으로 로그인하는 사용자를 나타냅니다. 사용자는 MFA(다단계 인증) 및 해당 위치 또는 네트워크에 기반한 조건부 액세스와 같이 로그인할 때 수행할 추가 보안 검사가 있는 경우가 많습니다.
그룹: 그룹은 사용자 컬렉션을 나타냅니다. 그룹은 직접 인증하지 않지만 사용자 집합에 권한을 함께 할당하는 편리한 방법을 제공합니다.
워크로드 ID: 워크로드는 일반적으로 직접 실행하는 사람이 없는 자동화된 프로세스 또는 시스템입니다. 워크로드는 Microsoft Entra ID에 로그인할 수 있지만 로그인하고 인증 프로세스와 상호 작용할 사람이 없습니다. 워크로드 ID에는 MFA 또는 이와 유사한 보호 기능이 없습니다. 이러한 기능을 사용하려면 사용자가 자신의 ID를 증명하기 위해 무언가를 해야 하기 때문입니다.

이 모듈에서는 워크로드 ID에 중점을 둡니다.

관리되는 아이덴티티

관리 ID는 Azure 리소스와 연결됩니다. Azure는 자격 증명을 자동으로 관리합니다. 리소스가 무언가에 액세스해야 하는 경우 Azure는 자격 증명을 사용하여 자동으로 로그인합니다.

관리 ID는 가상 머신 및 App Service 앱과 같은 Azure 호스팅 리소스에 사용할 수 있습니다. Azure 리소스가 Azure 관리를 자동화하고, 데이터베이스에 연결하고, Azure Key Vault에서 비밀 데이터를 읽는 등의 상황에 대해 인증할 수 있는 좋은 방법입니다. 다른 시나리오에서도 Azure Arc에서 관리 ID를 사용할 수 있습니다.

배포 워크플로를 사용하는 경우 일반적으로 관리 ID를 사용하지 않습니다. 관리 ID를 사용하려면 배포를 실행하는 Azure 리소스를 소유하고 관리해야 합니다. GitHub Actions를 사용하는 경우 일반적으로 Microsoft 또는 GitHub에서 제공하는 공유 인프라를 사용합니다. 그러나 GitHub Actions에서 워크로드 ID를 사용하는 경우 관리 ID의 주요 이점을 얻을 수 있습니다. 자격 증명을 관리할 필요가 없습니다.

팁 (조언)

솔루션의 다른 부분에서는 관리 ID 사용 또는 일반 서비스 주체 사용 중에서 선택할 수 있는 경우 관리 ID를 사용하는 것이 가장 좋습니다. 관리 ID는 작업하기 쉽고 일반적으로 더 안전합니다.

사용자 계정만 사용할 수 없는 이유는 무엇인가요?

완벽하게 잘 작동하는 사용자 계정이 있는 경우 배포 워크플로를 인증하기 위해 이 완전히 새로운 유형의 개체를 만들어야 하는 이유가 궁금할 수 있습니다.

사용자 계정은 무인 사용을 위해 설계되지 않았습니다. 사용자 계정에 대한 인증 프로세스는 종종 사용자가 로그인하려는 엔터티인지 확인합니다. 점점 더 많은 조직에서 인증 중에 추가 보안 검사를 사용합니다. 이러한 검사에는 MFA, CAPTCHA 검사, 사용자가 사용하는 디바이스 및 네트워크 검사가 포함되므로 로그인 요청의 정당성을 확인할 수 있습니다.

워크플로는 아무도 배포를 적극적으로 실행하지 않는 경우에도 배포를 실행하도록 설계되었습니다. 실제로 배포 워크플로의 이점은 대부분 자동화되어 있으며 사용자 상호 작용이 필요하지 않는다는 사실에서 비롯됩니다.

워크플로에 사용자 이름과 암호를 저장하고 이를 사용하여 로그인하려고 하면 작동하지 않을 수 있습니다. 작동할 것 같더라도 Microsoft Entra ID 또는 조직 관리자가 사용자 인증 프로세스에 더 많은 보안 검사를 추가하는 경우 나중에 쉽게 중단될 수 있습니다.

경고

다른 사용자가 액세스 권한을 얻고 사용자를 가장하는 데 사용할 수 있으므로 사용자 이름과 암호를 어디에나 저장하는 것도 좋지 않습니다.

이러한 이유로 Azure와 상호 작용하는 기본 제공 GitHub Actions 작업을 통해 사용자 계정의 자격 증명을 제공할 수 없습니다. 워크로드 ID를 사용해야 합니다.

워크로드 ID는 어떻게 작동합니까?

워크로드 ID는 글로벌 ID 서비스인 Microsoft Entra ID의 기능입니다. 많은 회사에서 Microsoft Entra ID를 사용하며 각 회사를 테넌트라고 합니다.

Microsoft Entra ID에는 시스템, 소프트웨어, 프로세스 또는 기타 비인간 에이전트를 나타내는 애플리케이션 개념이 있습니다. 배포 워크플로도 애플리케이션으로 생각할 수 있습니다.

애플리케이션을 만들고 해당 애플리케이션에 대해 Microsoft Entra ID에 알릴 때 애플리케이션 등록이라는 개체를 만듭니다. 애플리케이션 등록은 Microsoft Entra ID의 애플리케이션을 나타냅니다.

애플리케이션 등록에는 페더레이션 자격 증명이 있을 수 있습니다. 페더레이션된 자격 증명은 비밀을 저장할 필요가 없습니다. 대신 GitHub와 같은 지원되는 서비스가 Microsoft Entra 애플리케이션을 사용하도록 설정합니다.

GitHub Actions 워크플로를 인증해야 하는 경우 GitHub를 통해 Microsoft Entra ID에 연결합니다. GitHub는 Microsoft Entra ID에 GitHub 조직 및 리포지토리의 이름과 선택적으로 다른 정보를 알려줍니다. 리포지토리의 세부 정보와 일치하는 페더레이션 자격 증명을 구성한 경우 Microsoft Entra는 배포 워크플로를 인증합니다. 워크플로는 애플리케이션에 할당한 권한을 사용할 수 있습니다.