Azure Policy 할당의 안전한 배포

아티클
07/17/2024

환경이 확장됨에 따라 점진적인 노출 제어 기능을 갖춘 제어된 지속적인 배포(CD) 파이프라인에 대한 수요도 늘어납니다. 따라서 DevOps 팀은 SDP(안전한 배포 사례) 프레임워크를 따르는 것이 좋습니다. Azure Policy 정의 및 할당을 안전하게 배포하면 정책 리소스의 의도하지 않은 동작이 미치는 영향을 제한하는 데 도움이 됩니다.

Azure Policy를 사용하여 SDP를 구현하는 개략적인 방식은 링별로 정책 할당을 점진적으로 롤아웃하여 환경에 영향을 미치는 정책 변경이 중요한 클라우드 인프라에 영향을 미치기 전에 초기 단계에서 검색하는 것입니다.

배포 링은 다양한 방식으로 구성될 수 있습니다. 이 방법 자습서에서 링은 다양한 Azure 지역, 즉 링 0(중요하지 않고 낮은 트래픽 위치를 나타냄)과 링 5(가장 중요하고 가장 높은 트래픽 위치를 나타냄)로 구분됩니다.

거부 또는 추가 효과를 사용하여 Azure Policy 할당을 안전하게 배포하는 단계

deny 또는 append 정책 효과를 사용하는 Azure Policy 할당에 SDP 프레임워크를 적용하는 방법을 설명할 때 다음 순서도를 참조로 사용합니다.

참고 항목

Azure Policy 효과에 대해 자세히 알아보려면 효과 작동 방식 이해를 참조하세요.

새로운 Azure Policy 정의의 안전한 배포 방법 배포를 보여 주는 1~8단계 순서도입니다.

순서도 단계 번호:

정책 정의를 선택한 후에는 모든 배포 링을 포함하는 최고 수준 범위에서 정책을 할당합니다. 리소스 선택기를 적용하여 "kind": "resource location" 속성을 사용하여 가장 중요한 링으로 적용 범위를 좁힙니다. 할당 재정의를 사용하여 audit 효과 형식을 구성합니다. 위치가 eastUS이고 효과가 audit인 샘플 선택기:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Audit" 
}] 
```
할당이 배포되고 초기 준수 검사가 완료되면 준수 결과가 예상대로인지 유효성을 검사합니다.

또한 준수 검사를 실행하는 자동화된 테스트를 구성해야 합니다. 준수 확인에는 다음 논리가 포함되어야 합니다.
- 준수 결과 수집
- 준수 결과가 예상대로라면 파이프라인은 계속되어야 합니다.
- 준수 결과가 예상과 다르면 파이프라인이 실패하고 디버깅을 시작해야 합니다.
예를 들어, 특정 CI/CD(연속 통합/지속적인 배포) 파이프라인 내에서 다른 도구를 사용하여 준수 검사를 구성할 수 있습니다.

각 롤아웃 단계에서 애플리케이션 상태 검사를 통해 서비스의 안정성과 정책의 영향을 확인해야 합니다. 애플리케이션 구성으로 인해 결과가 예상과 다른 경우 애플리케이션을 적절하게 리팩터링합니다.
다음 링을 포함하도록 리소스 선택기 속성 값을 확장하여 반복합니다. 위치의 유효성을 검사하고 예상되는 준수 결과와 애플리케이션 상태의 유효성을 검사합니다. 위치 값이 추가된 선택기의 예:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]
```
audit 모드를 사용하여 모든 링에 정책을 성공적으로 할당하면 파이프라인은 정책 효과를 deny로 변경하는 작업을 트리거하고 리소스 선택기를 링 0과 연결된 위치로 다시 설정해야 합니다. 하나의 영역과 효과가 거부로 설정된 선택기 예:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"overrides":[{ 
  "kind": "policyEffect", 
  "value": "Deny" 
}] 
```
효과가 변경되면 자동화된 테스트를 통해 예상대로 적용이 이루어지고 있는지 확인해야 합니다.
리소스 선택기 구성에 더 많은 링을 포함하여 반복합니다.
모든 프로덕션 링에 대해 이 과정을 반복합니다.

수정 또는 deployIfNotExists 효과를 사용하여 Azure Policy 할당을 안전하게 배포하는 단계

modify 또는 deployIfNotExists 효과를 사용하는 정책 단계는 이전에 적용 모드 사용 및 수정 작업 트리거의 추가 작업에 대해 설명한 단계와 유사합니다. 5~9단계를 수정하여 다음 순서도를 검토합니다.

Azure Policy 안전한 배포 사례 워크플로의 5~9단계를 보여 주는 순서도입니다.

순서도 단계 번호:

정책 정의를 선택한 후에는 모든 배포 링을 포함하는 최고 수준 범위에서 정책을 할당합니다. 리소스 선택기를 적용하여 "kind": "resource location" 속성을 사용하여 가장 중요한 링으로 적용 범위를 좁힙니다. DoNotEnforce에 대한 할당의 적용 모드를 구성합니다. 위치가 eastUS이고 enforcementMode가 DoNotEnforce인 샘플 선택기:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "DoNotEnforce"
```
할당이 배포되고 초기 준수 검사가 완료되면 준수 결과가 예상대로인지 유효성을 검사합니다.

또한 준수 검사를 실행하는 자동화된 테스트를 구성해야 합니다. 준수 확인에는 다음 논리가 포함되어야 합니다.
- 준수 결과 수집
- 준수 결과가 예상대로라면 파이프라인은 계속되어야 합니다.
- 준수 결과가 예상과 다르면 파이프라인이 실패하고 디버깅을 시작해야 합니다.
CI/CD(연속 통합/지속적인 배포) 파이프라인 내에서 다른 도구를 사용하여 준수 검사를 구성할 수 있습니다.

각 롤아웃 단계에서 애플리케이션 상태 검사를 통해 서비스의 안정성과 정책의 영향을 확인해야 합니다. 애플리케이션 구성으로 인해 결과가 예상과 다른 경우 애플리케이션을 적절하게 리팩터링합니다.

기존의 비준수 리소스를 수정하기 위해 수정 작업을 트리거할 수도 있습니다. 수정 작업을 통해 리소스가 예상대로 규정을 준수하는지 확인합니다.
다음 링의 위치를 포함하도록 리소스 선택기 속성 값을 확장하고 예상되는 준수 결과와 애플리케이션 상태의 유효성을 검사하는 과정을 반복합니다. 위치 값이 추가된 선택기의 예:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"] 
  }]
}]
```
DoNotEnforce 모드를 사용하여 모든 링에 정책을 성공적으로 할당하면 파이프라인은 정책 enforcementMode를 기본 사용으로 변경하고 리소스 선택기를 링 0과 연결된 위치로 다시 설정하는 작업을 트리거해야 합니다. 하나의 영역과 효과가 거부로 설정된 선택기 예:
```
"resourceSelectors": [{ 
  "name": "SDPRegions", 
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ] 
  }]
}], 
"enforcementMode": "Default",
```
효과가 변경되면 자동화된 테스트를 통해 예상대로 적용이 이루어지고 있는지 확인해야 합니다.
리소스 선택기 구성에 더 많은 링을 포함하여 반복합니다.
모든 프로덕션 링에 대해 이 과정을 반복합니다.

Azure Policy 할당 내에서 기본 제공 정의 버전을 안전하게 업데이트하는 단계

기존 할당 내에서 재정의를 적용하여 중요도가 가장 낮은 링에 대한 정의 버전을 업데이트합니다. 재정의 조합을 사용하여 정의 버전을 변경하고 재정의 조건 내에서 선택기를 사용하여 "kind": "resource location" 속성으로 적용 범위를 좁힙니다. 지정된 위치 외부에 있는 모든 리소스는 할당의 definitionVersion 최상위 속성 버전에 대해 계속 평가됩니다. 예에서는 정의 버전을 2.0.*으로 업데이트하고 이를 EastUs의 리소스에만 적용하는 것을 재정의합니다.
```
"overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0.*",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus"]
  }]
}] 
```
할당이 업데이트되고 초기 준수 검사가 완료되면 준수 결과가 예상대로인지 유효성을 검사합니다.

또한 준수 검사를 실행하는 자동화된 테스트를 구성해야 합니다. 준수 확인에는 다음 논리가 포함되어야 합니다.
- 준수 결과 수집
- 준수 결과가 예상대로라면 파이프라인은 계속되어야 합니다.
- 준수 결과가 예상과 다르면 파이프라인이 실패하고 디버깅을 시작해야 합니다.
예를 들어, 특정 CI/CD(연속 통합/지속적인 배포) 파이프라인 내에서 다른 도구를 사용하여 준수 검사를 구성할 수 있습니다.

각 롤아웃 단계에서 애플리케이션 상태 검사를 통해 서비스의 안정성과 정책의 영향을 확인해야 합니다. 애플리케이션 구성으로 인해 결과가 예상과 다른 경우 애플리케이션을 적절하게 리팩터링합니다.
다음 링을 포함하도록 리소스 선택기 속성 값을 확장하여 반복합니다. 위치의 유효성을 검사하고 예상되는 준수 결과와 애플리케이션 상태의 유효성을 검사합니다. 위치 값이 추가된 예:
```
 "overrides":[{ 
  "kind": "definitionVersion", 
  "value": "2.0",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus", "westus"]
  }]
}] 
```
_selectors 내에 필요한 모든 위치를 성공적으로 포함시킨 후에는 재정의를 제거하고 할당 내에서 definitionVersion 속성을 업데이트할 수 있습니다.

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

다음 단계

프로그래밍 방식으로 정책을 만드는 방법을 알아봅니다.
코드 워크플로로 Azure Policy를 검토합니다.
안전한 배포 방법에 관한 Microsoft의 지침을 살펴봅니다.
Azure Policy를 사용하여 비준수 리소스 수정을 검토합니다.

다음을 통해 공유

Azure Policy 할당의 안전한 배포

거부 또는 추가 효과를 사용하여 Azure Policy 할당을 안전하게 배포하는 단계

수정 또는 deployIfNotExists 효과를 사용하여 Azure Policy 할당을 안전하게 배포하는 단계

Azure Policy 할당 내에서 기본 제공 정의 버전을 안전하게 업데이트하는 단계

다음 단계

피드백

추가 리소스