워크로드 ID 이해

7분

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

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

Bicep 파일을 배포할 때 Azure 리소스를 효과적으로 만들거나 수정하도록 Azure Resource Manager에 요청합니다. 예제 시나리오에서는 장난감 회사의 웹 사이트를 배포하는 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

관리 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 또는 조직 관리자가 사용자 인증 프로세스에 더 많은 보안 검사를 추가하면 나중에 쉽게 손상될 수 있습니다.

Warning

다른 사용자가 액세스하고 가장하는 데 사용할 수 있기 때문에 아무 곳에나 사용자 이름과 암호를 저장하는 것도 좋지 않습니다.

이러한 이유로 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는 배포 워크플로를 인증합니다. 워크플로는 애플리케이션에 할당한 권한을 사용할 수 있습니다.

팁

Azure Portal에서 애플리케이션 등록을 살펴보면 관련이 없는 기타 기능 및 구성이 많이 표시될 수 있습니다. 그 이유는 애플리케이션이 인증과 워크플로 배포 범위를 벗어나는 Microsoft Entra ID의 많은 작업을 수행할 수 있기 때문입니다.

Microsoft Entra 테넌트에서 서비스 주체 개체를 만들 수도 있습니다. 서비스 주체는 고유의 Microsoft Entra 테넌트가 사용할 애플리케이션의 복사본과 같습니다. 서비스 주체 및 애플리케이션은 밀접하게 연결되어 있습니다. 이 모듈의 뒷부분에서 Azure에 액세스할 수 있는 워크플로 권한을 부여할 때 서비스 주체를 사용합니다.

참고