코드 워크플로로 Azure Policy 디자인

  • 아티클

Cloud Governance 여정을 진행하면서 Azure Portal이나 다양한 SDK를 통해 각 정책 할당을 수동으로 관리하는 방식을 엔터프라이즈 규모에서 보다 관리하기 쉽고 반복 가능한 방식으로 전환하려고 합니다. 클라우드에서 대규모로 시스템을 관리하는 일반적인 방법 두 가지는 다음과 같습니다.

  • 코드 제공 인프라: ARM 템플릿(Azure Resource Manager 템플릿)부터 Azure Policy 정의, Azure Blueprints까지 환경을 정의하는 모든 콘텐츠를 소스 코드로 처리하는 방식.
  • DevOps: 최종 사용자에게 가치를 지속적으로 제공할 수 있도록 하는 사람, 프로세스 및 제품을 통칭

이러한 아이디어의 조합이 바로 Azure Policy as Code입니다. 기본적으로 정책 정의를 소스 제어에서 유지하고, 변경 내용이 적용될 때마다 해당 변경 내용을 테스트하고, 유효성을 검사합니다. 그러나 이는 코드 제공 인프라 또는 DevOps와 관련된 정책 범위에 있어서는 안 됩니다.

유효성 검사 단계는 애플리케이션 환경 또는 가상 인프라 배포와 같은 다른 CI/CD(연속 통합 또는 지속적인 배포) 워크플로의 일부이기도 합니다. 애플리케이션 및 운영 팀은 빌드 및 배포 프로세스의 초기 구성 요소에 대한 Azure Policy 유효성 검사를 수행하여 너무 늦기 전에 변경 내용이 예상대로 작동하는지 여부를 확인하고 프로덕션 환경에 배포합니다.

정의 및 기본 정보

Azure Policy의 세부 정보를 코드 워크플로로 가져오기 전에 정책 정의 및 이니셔티브 정의를 작성하는 방법 및 해당 정의 할당에 대한 예외를 활용하는 방법과 같은 몇 가지 기본 개념을 이해하는 것이 중요합니다.

파일 이름은 정책 또는 이니셔티브 정의와 기타 정책 리소스의 특정 부분에 해당합니다.

파일 형식 파일 콘텐츠
policy.json 전체 정책 정의
policyset.json 전체 이니셔티브 정의
policy.parameters.json 정책 정의의 properties.parameters 부분
policyset.parameters.json 이니셔티브 정의의 properties.parameters 부분
policy.rules.json 정책 정의의 properties.policyRule 부분
policyset.definitions.json 이니셔티브 정의의 properties.policyDefinitions 부분
exemptionName.json 특정 리소스 또는 범위를 대상으로 하는 정책 예외

이러한 파일 형식의 예는 Azure Policy GitHub 리포지토리에서 사용할 수 있습니다.

워크플로 개요

Azure Policy as Code에 권장되는 일반적인 워크플로는 다음 다이어그램과 같습니다.

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

소스 컨트롤

기존 정책 및 이니셔티브 정의는 PowerShell, CLI 또는 ARG(Azure Resource Graph) 쿼리 같은 다양한 방법으로 내보낼 수 있습니다. 이러한 정의를 저장하기 위해 선택하는 소스 제어 관리 환경은 GitHub 또는 Azure DevOps를 비롯한 여러 옵션 중 하나일 수 있습니다.

정책 정의 만들기 및 관리

정책 정의는 JSON을 사용하여 생성되고 소스 제어에 저장됩니다. 각 정책에는 동일한 폴더에 저장해야 하는 매개 변수, 규칙 및 환경 매개 변수와 같은 고유한 파일 세트가 있습니다. 다음 구조는 소스 제어에서 정책 정의를 유지할 때 권장되는 방법입니다.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

새 정책이 추가되거나 기존 정책이 업데이트되면 워크플로가 Azure의 정책 정의를 자동으로 업데이트해야 합니다. 신규 또는 업데이트된 정책 정의 테스트는 이후 단계에서 수행합니다.

이니셔티브 정의 만들기 및 업데이트

이니셔티브 정의는 정책 정의와 동일한 폴더에 저장되어야 하는 JSON 파일을 사용하여 만들어집니다. 이니셔티브 정의를 사용하려면 정책 정의가 이미 있어야 하므로 정책 소스가 소스 제어에서 업데이트된 후 Azure에서 업데이트되어야만 이니셔티브 정의를 만들거나 업데이트할 수 있습니다. 다음 구조는 소스 제어에서 이니셔티브 정의를 유지할 때 권장되는 방법입니다.

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

정책 정의와 마찬가지로 기존 이니셔티브를 추가하거나 업데이트할 때 워크플로는 Azure에서 이니셔티브 정의를 자동으로 업데이트해야 합니다. 신규 또는 업데이트된 이니셔티브 정의 테스트는 이후 단계에서 수행합니다.

참고 항목

정책을 배포하는 데는 GitHub 워크플로 또는 Azure Pipelines 같은 중앙 집중식 배포 메커니즘을 사용하는 것이 좋습니다. 이렇게 하면 검토된 정책 리소스만 환경에 배포되고 점진적인 중앙 배포 메커니즘이 사용되도록 할 수 있습니다. 정책 리소스에 대한 쓰기 권한은 배포에 사용되는 ID로 제한될 수 있습니다.

업데이트된 정의 테스트 및 유효성 검사

Automation에서 새로 생성되거나 업데이트된 정책 또는 이니셔티브 정의를 가져와 Azure의 개체를 업데이트한 후에는 변경 내용을 테스트해야 합니다. 정책 또는 관련 이니셔티브는 프로덕션 단계보다 훨씬 이전에 리소스에 할당되어야 합니다. 이 환경은 일반적으로 Dev입니다.

참고 항목

이 단계에서는 Azure 환경 내에서 정책 정의의 통합 테스트를 수행합니다. 이는 정의 만들기 프로세스 중에 수행되어야 하는 정책 정의 기능을 확인하는 작업과 별개입니다.

할당은 리소스 생성과 업데이트가 차단되지 않도록 사용 안 함enforcementMode를 사용해야 하지만 기존 리소스는 업데이트된 정책 정의 준수 여부를 계속 감사합니다. enforcementMode를 사용하는 경우에도 할당 범위는 정책 유효성 검사 전용 리소스 그룹 또는 구독이어야 합니다.

참고 항목

적용 모드는 유용하지만 다양한 조건에서 정책 정의를 철저히 테스트하지 않고 사용해서는 안 됩니다. 정책 정의는 PUT 및 PATCH REST API 호출, 준수 및 미준수 리소스, 리소스에서 누락된 속성과 같은 에 지 사례를 사용하여 테스트해야 합니다.

할당이 배포된 후 Azure Policy SDK, Azure Pipelines 보안 및 규정 준수 평가 작업 또는 ARG(Azure Resource Graph) 쿼리(샘플 참조)를 사용하여 새 할당에 대한 규정 준수 데이터를 가져옵니다. 정책 및 할당을 테스트하는 데 사용되는 환경에는 다양한 준수 상태의 리소스가 있어야 합니다. 코드에 대한 유용한 단위 테스트와 마찬가지로, 리소스가 예상대로 작동하고 가양성 또는 가음성이 없는지도 테스트하려고 합니다. 예상되는 항목에 대해서만 테스트 및 유효성 검사를 수행하는 경우 미처 파악하지 못한 예기치 않은 정책 영향이 있을 수 있습니다. 자세한 내용은 새 Azure Policy 정의의 영향 평가를 참조하세요.

수정 작업 사용

할당의 유효성 검사가 기대치를 충족하는 경우 다음 단계는 수정의 유효성을 검사하는 것입니다. deployIfNotExists 또는 modify를 사용하는 정책은 비준수 상태에서 리소스를 수정하고 규정 준수 상태로 전환하기 위해 연결된 수정 작업을 트리거할 수 있습니다.

리소스를 수정하는 첫 번째 단계는 정책 정의에 기술된 역할 할당에 정책 할당을 부여하는 것입니다. 이 역할 할당은 정책 할당 관리 ID에 리소스를 준수하는 데 필요한 변경을 수행할 수 있는 충분한 권한을 제공합니다.

정책 할당에 적절한 권한이 있는 경우 Policy SDK를 사용하여 미준수 상태로 알려진 리소스 세트에 대한 수정 작업을 트리거하세요. 계속하기 전에 이처럼 수정된 작업에 대한 세 가지 테스트를 완료해야 합니다.

  • 수정 작업이 성공적으로 완료되었는지 확인
  • 정책 평가를 실행하여 정책 준수 결과가 예상대로 업데이트되는지 확인
  • 리소스에 대한 환경 단위 테스트를 직접 실행하여 해당 속성이 변경되었는지 확인

업데이트된 정책 평가 결과와 환경을 모두 테스트하면 수정 작업이 올바르게 변경 내용을 적용했으며 정책 정의가 준수 상태 변경을 올바르게 인식했는지 직접 확인할 수 있습니다.

적용된 할당으로 업데이트

모든 유효성 검사 게이트가 완료된 후 enabled라는 enforcementMode를 사용하도록 할당을 업데이트합니다. 프로덕션 단계보다 훨씬 이전에 동일한 환경에서 이 변경을 수행하는 것이 좋습니다. 리소스를 만들고 리소스를 업데이트하는 동안 원하는 효과가 적용되는지 확인합니다. 올바르게 작동하는 환경의 유효성 검사를 완료한 후에는 정책이 프로덕션 리소스에 배포될 때까지 다음 환경을 포함하도록 변경 범위를 지정해야 합니다.

프로세스 통합 평가

일반적인 Azure Policy as Code 워크플로는 정책 및 이니셔티브를 대규모로 개발하고 환경에 배포하기 위한 것입니다. 그러나 인프라를 만들려면 애플리케이션 배포 또는 ARM 템플릿 실행과 같이 Azure에서 리소스를 배포하거나 만드는 모든 워크플로의 배포 프로세스에 정책 평가가 포함되어야 합니다.

이러한 경우 테스트 구독 또는 리소스 그룹에 대해 애플리케이션 또는 인프라 배포가 수행된 후 해당 범위에 대한 정책 평가를 수행하여 모든 기존 정책과 이니셔티브의 유효성을 확인해야 합니다. 이러한 환경에서는 enforcementMode가 사용 안 함으로 구성될 수 있지만 애플리케이션 또는 인프라 배포가 정책 정의를 위반하는지 초기에 확인하기에 유용합니다. 따라서 이 정책 평가는 이러한 워크플로의 한 단계로 포함되어야 하며 미준수 리소스를 만드는 배포에 실패합니다.

검토

이 문서에서는 일반적인 Azure Policy as Code 워크플로를 설명하고, 정책 평가가 다른 배포 워크플로에 포함되어야 하는 경우도 설명합니다. 이 워크플로는 트리거를 기반으로 하는 스크립팅된 단계 및 자동화를 지원하는 모든 환경에서 사용할 수 있습니다.

다음 단계