You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/governance/policy/concepts/definition-structure.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -136,9 +136,8 @@ see [Tag support for Azure resources](../../../azure-resource-manager/management
136
136
137
137
The following Resource Provider modes are fully supported:
138
138
139
-
-`Microsoft.Kubernetes.Data` for managing your Kubernetes clusters on or off Azure. Definitions
140
-
using this Resource Provider mode use effects _audit_, _deny_, and _disabled_. Use
141
-
of the [EnforceOPAConstraint](./effects.md#enforceopaconstraint) effect is _deprecated_.
139
+
-`Microsoft.Kubernetes.Data` for managing your Kubernetes clusters on or off Azure, and for Azure Policy components that target [Azure Arc-enabled Kubernetes clusters](../../../aks/intro-kubernetes.md) components such as pods, containers, and ingresses. Definitions
140
+
using this Resource Provider mode use effects _audit_, _deny_, and _disabled_.
142
141
-`Microsoft.KeyVault.Data` for managing vaults and certificates in
143
142
[Azure Key Vault](../../../key-vault/general/overview.md). For more information on these policy
@@ -23,16 +23,15 @@ These effects are currently supported in a policy definition:
23
23
-[Manual (preview)](#manual-preview)
24
24
-[Modify](#modify)
25
25
26
-
The following effects are _deprecated_:
26
+
## Interchanging effects
27
27
28
-
-[EnforceOPAConstraint](#enforceopaconstraint)
29
-
-[EnforceRegoPolicy](#enforceregopolicy)
28
+
Sometimes multiple effects can be valid for a given policy definition. Parameters are often used to specify allowed effect values so that a single definition can be more versatile. However, it's important to note that not all effects are interchangeable. Resource properties and logic in the policy rule can determine whether a certain effect is considered valid to the policy definition. For example, policy definitions with effect **AuditIfNotExists** require additional details in the policy rule that aren't required for policies with effect **Audit**. The effects also behave differently. **Audit** policies will assess a resource's compliance based on its own properties, while **AuditIfNotExists** policies will assess a resource's compliance based on a child or extension resource's properties.
30
29
31
-
> [!IMPORTANT]
32
-
> In place of the**EnforceOPAConstraint** or **EnforceRegoPolicy**effects, use _audit_ and
33
-
> _deny_ with Resource Provider mode `Microsoft.Kubernetes.Data`. The built-in policy definitions
34
-
> have been updated. When existing policy assignments of these built-in policy definitions are
35
-
> modified, the _effect_ parameter must be changed to a value in the updated _allowedValues_ list.
30
+
Below is some general guidance around interchangeable effects:
31
+
-**Audit**, **Deny**, and either**Modify** or **Append**are often interchangeable.
32
+
-**AuditIfNotExists** and **DeployIfNotExists** are often interchangeable.
33
+
-**Manual** isn't interchangeable.
34
+
-**Disabled** is interchangeable with any effect.
36
35
37
36
## Order of evaluation
38
37
@@ -163,7 +162,7 @@ definitions as `constraintTemplate` is deprecated.
163
162
template. See
164
163
[Create policy definition from constraint template](../how-to/extension-for-vscode.md) to
The new `manual` (preview) effect enables you to self-attest the compliance of resources or scopes. Unlike other policy definitions that actively scan for evaluation, the Manual effect allows for manual changes to the compliance state. To change the compliance of a resource or scope targeted by a manual policy, you'll need to create an [attestation](attestation-structure.md). The [best practice](attestation-structure.md#best-practices) is to design manual policies that target the scope which defines the boundary of resources whose compliance need attesting.
@@ -821,7 +693,7 @@ The following operations are supported by Modify:
821
693
- Add, replace, or remove resource tags. For tags, a Modify policy should have `mode` set to
822
694
_Indexed_ unless the target resource is a resource group.
823
695
- Add or replace the value of managed identity type (`identity.type`) of virtual machines and
Copy file name to clipboardExpand all lines: articles/governance/policy/concepts/policy-applicability.md
+26-6Lines changed: 26 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ author: timwarner-msft
8
8
---
9
9
# What is applicability in Azure Policy?
10
10
11
-
When a policy definition is assigned to a scope, Azure Policy determines which resources in that scope should be considered for compliance evaluation. A resource will only be assessed for compliance if it is considered **applicable** to the given policy assignment.
11
+
When a policy definition is assigned to a scope, Azure Policy determines which resources in that scope should be considered for compliance evaluation. A resource will only be assessed for compliance if it's considered **applicable** to the given policy assignment.
12
12
13
13
Applicability is determined by several factors:
14
14
-**Conditions** in the `if` block of the [policy rule](../concepts/definition-structure.md#policy-rule).
@@ -21,23 +21,43 @@ Condition(s) in the `if` block of the policy rule are evaluated for applicabilit
21
21
> [!NOTE]
22
22
> Applicability is different from compliance, and the logic used to determine each is different. If a resource is **applicable** that means it is relevant to the policy. If a resource is **compliant** that means it adheres to the policy. Sometimes only certain conditions from the policy rule impact applicability, while all conditions of the policy rule impact compliance state.
23
23
24
-
## Applicability logic for Append/Modify/Audit/Deny/RP Mode specific effects
24
+
## Applicability logic for Resource Manager modes
25
+
26
+
### Append, Audit, Manual, Modify and Deny policy effects
25
27
26
28
Azure Policy evaluates only `type`, `name`, and `kind` conditions in the policy rule `if` expression and treats other conditions as true (or false when negated). If the final evaluation result is true, the policy is applicable. Otherwise, it's not applicable.
27
29
28
30
Following are special cases to the previously described applicability logic:
29
31
30
32
|Scenario |Result |
31
33
|---------|---------|
32
-
|Any invalid aliases in the `if` conditions |The policy is not applicable |
34
+
|Any invalid aliases in the `if` conditions |The policy isn't applicable |
33
35
|When the `if` conditions consist of only `kind` conditions |The policy is applicable to all resources |
34
36
|When the `if` conditions consist of only `name` conditions |The policy is applicable to all resources |
35
37
|When the `if` conditions consist of only `type` and `kind` or `type` and `name` conditions |Only type conditions are considered when deciding applicability |
36
-
|When any conditions (including deployment parameters) include a `location` condition |Will not be applicable to subscriptions |
38
+
|When any conditions (including deployment parameters) include a `location` condition |Won't be applicable to subscriptions |
39
+
40
+
### AuditIfNotExists and DeployIfNotExists policy effects
41
+
42
+
The applicability of `AuditIfNotExists` and `DeployIfNotExists` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy isn't applicable.
43
+
44
+
## Applicability logic for resource provider modes
45
+
46
+
### Microsoft.Kubernetes.Data
47
+
48
+
The applicability of `Microsoft.Kubernetes.Data` policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy isn't applicable.
49
+
50
+
### Microsoft.KeyVault.Data
51
+
52
+
Policies with mode `Microsoft.KeyVault.Data` are applicable if the `type` condition of the policy rule evaluates to true. The `type` refers to component type, such as:
53
+
- Microsoft.KeyVault.Data/vaults/certificates
54
+
- Microsoft.KeyVault.Data/vaults/keys
55
+
- Microsoft.KeyVault.Data/vaults/secrets
37
56
38
-
##Applicability logic for AuditIfNotExists and DeployIfNotExists policy effects
57
+
### Microsoft.Network.Data
39
58
40
-
The applicability of AuditIfNotExists and DeployIfNotExists policies is based off the entire `if` condition of the policy rule. When the `if` evaluates to false, the policy is not applicable.
59
+
Policies with mode `Microsoft.Network.Data` are applicable if the `type` and `name` conditions of the policy rule evaluate to true. The `type` refers to component type:
0 commit comments