Förstå Azure Policy effekter

Varje principdefinition i Azure Policy har en enda effekt. Den effekten avgör vad som händer när principregeln utvärderas för att matcha. Effekterna beter sig annorlunda om de gäller för en ny resurs, en uppdaterad resurs eller en befintlig resurs.

Dessa effekter stöds för närvarande i en principdefinition:

• Lägg till
• Audit (Granska)
• AuditIfNotExists
• Neka
• DeployIfNotExists
• Disabled (Inaktiverat)
• Modify (Ändra)

Följande effekter är inaktuella:

• EnforceOPAConstraint
• EnforceRegoPolicy

Utvärderingsordning

Begäranden om att skapa eller uppdatera en resurs utvärderas av Azure Policy först. Azure Policy skapar en lista över alla tilldelningar som gäller för resursen och utvärderar sedan resursen mot varje definition. För ett Resource Manager lägeAzure Policy flera av effekterna innan du lämnar över begäran till lämplig resursprovider. Den här ordningen förhindrar onödig bearbetning av en resursprovider när en resurs inte uppfyller de utformade styrningskontrollerna för Azure Policy. I läget Resursproviderhanterar resursprovidern utvärderingen och resultatet och rapporterar resultatet tillbaka till Azure Policy.

• Inaktiverad kontrolleras först för att avgöra om principregeln ska utvärderas.
• Append och Modify utvärderas sedan. Eftersom antingen kan ändra begäran kan en ändring som görs förhindra att en gransknings- eller neka-effekt utlöses. Dessa effekter är bara tillgängliga med ett Resource Manager läge.
• Neka utvärderas sedan. Genom att utvärdera neka före granskning förhindras dubbel loggning av en oönskad resurs.
• Granskningen utvärderas sist.

När resursprovidern returnerar en lyckad kod på en Resource Manager-lägesbegäran utvärderar AuditIfNotExists och DeployIfNotExists för att avgöra om ytterligare efterlevnadsloggning eller åtgärd krävs.

Begäranden som endast PATCH ändrar relaterade fält begränsar dessutom tags principutvärderingen till principer som innehåller villkor som inspekterar tags relaterade fält.

Lägg till

Lägg till används för att lägga till ytterligare fält i den begärda resursen när du skapar eller uppdaterar. Ett vanligt exempel är att ange tillåtna IP-adresser för en lagringsresurs.

Tilläggsutvärdering

Tilläggs utvärderas innan begäran bearbetas av en resursprovider när en resurs skapas eller uppdateras. Lägg till lägger till fält i resursen när if-villkoret för principregeln uppfylls. Om tilläggseffekten skulle åsidosätta ett värde i den ursprungliga begäran med ett annat värde, fungerar den som en neka-effekt och avvisar begäran. Om du vill lägga till ett nytt värde i en befintlig matris använder [*] du aliasversionen.

När en principdefinition som använder tilläggseffekten körs som en del av en utvärderingscykel görs inga ändringar i resurser som redan finns. I stället markerar den alla resurser som uppfyller if-villkoret som icke-kompatibla.

Lägg till egenskaper

En tilläggseffekt har bara en informationsmatris, vilket krävs. Eftersom information är en matris kan det ta antingen ett fält/värde-par eller multiplar. Se definitionsstrukturen för listan över godkända fält.

Exempel på tillägg

Exempel 1: Ett fält/värde-par som använder ett icke-alias med ett [*] matrisvärde för att ange IP-regler för ett lagringskonto. När det [*] icke-aliaset är en matris lägger effekten till värdet som hela matrisen. Om matrisen redan finns inträffar en neka-händelse från konflikten.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
        "value": [{
            "action": "Allow",
            "value": "134.5.0.0/21"
        }]
    }]
}

Exempel 2: Par med ett enskilt fält/värde med [*] ett alias med ett matrisvärde för att ange IP-regler för ett lagringskonto. Med hjälp [*] av aliaset lägger effekten till värdet i en eventuellt befintlig matris. Om matrisen inte finns ännu skapas den.

"then": {
    "effect": "append",
    "details": [{
        "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
        "value": {
            "value": "40.40.40.40",
            "action": "Allow"
        }
    }]
}

Granska

Granskning används för att skapa en varningshändelse i aktivitetsloggen vid utvärdering av en icke-kompatibel resurs, men den stoppar inte begäran.

Granskningsutvärdering

Granskning är den sista effekten som kontrolleras Azure Policy när en resurs skapas eller uppdateras. För ett Resource Manager läge Azure Policy skickar sedan resursen till resursprovidern. När du utvärderar en begäran om att skapa eller uppdatera en resurs Azure Policy lägger till en åtgärd i aktivitetsloggen och markerar resursen som Microsoft.Authorization/policies/audit/action icke-kompatibel. Under en utvärderingscykel för standardefterlevnad uppdateras endast kompatibilitetsstatusen för resursen.

Granskningsegenskaper

För ett Resource Manager-läge har inte granskningseffekten några ytterligare egenskaper för användning i sedan-villkoret för principdefinitionen.

För resursproviderläget Microsoft.Kubernetes.Data har granskningseffekten följande ytterligare underegenskaper med information. Användning av templateInfo krävs för nya eller uppdaterade principdefinitioner eftersom är constraintTemplate inaktuella.

• templateInfo (krävs)
  • Kan inte användas med constraintTemplate .
  • sourceType (krävs)

    • Definierar typen av källa för begränsningsmallen. Tillåtna värden: PublicURL eller Base64Kodad.

    • Om PublicURL är kopplat till egenskapen url för att ange platsen för begränsningsmallen. Platsen måste vara offentligt tillgänglig.

      Varning

      Använd inte SAS-URI:er eller token i url eller något annat som kan exponera en hemlighet.

    • Om Base64Encoded, paras med egenskapen för att tillhandahålla mallen content för base 64-kodad begränsning. Se Skapa principdefinition från begränsningsmall för att skapa en anpassad definition från en befintlig OPA-mall för Open Policy Agent (OPA) GateKeeper v3-begränsning.

• constraint (valfritt)
  • Kan inte användas med templateInfo .
  • CRD-implementeringen av begränsningsmallen. Använder parametrar som skickas via värden som {{ .Values.<valuename> }} . I exempel 2 nedan är dessa värden {{ .Values.excludedNamespaces }} och {{ .Values.allowedContainerImagesRegex }} .
• namnrymder (valfritt)
  • En matris med Kubernetes-namnrymder för att begränsa principutvärderingen till.
  • Ett tomt eller saknat värde gör att principutvärderingen inkluderar alla namnområden, förutom de som definierats i excludedNamespaces.
• excludedNamespaces (krävs)
  • En matris med Kubernetes-namnrymder som ska undantas från principutvärderingen.
• labelSelector (krävs)
  • Ett objekt som innehåller egenskaperna matchLabels (objekt) och matchExpression (matris) så att du kan ange vilka Kubernetes-resurser som ska inkluderas för principutvärdering som matchade de angivna etiketterna och väljarna.
  • Ett tomt eller saknat värde gör att principutvärderingen inkluderar alla etiketter och väljare, förutom namnområden som definieras i excludedNamespaces.
• apiGroups (krävs när du använder templateInfo)
  • En matris som innehåller de API-grupper som ska matchas. En tom matris ( [""] ) är den centrala API-gruppen medan matchar alla ["*"] API-grupper.
• typer (krävs när du använder templateInfo)
  • En matris som innehåller typen av Kubernetes-objekt att begränsa utvärderingen till.
• värden (valfritt)
  • Definierar alla parametrar och värden som ska överföras till begränsningen. Varje värde måste finnas i CRD-mallen Begränsningsmall.
• constraintTemplate (inaktuell)
  • Kan inte användas med templateInfo .
  • Måste ersättas med när templateInfo du skapar eller uppdaterar en principdefinition.
  • Mallen Begränsning CustomResourceDefinition (CRD) som definierar nya begränsningar. Mallen definierar Rego-logiken, schemat för begränsning och de begränsningsparametrar som skickas via värden från Azure Policy.

Granskningsexempel

Exempel 1: Använda granskningseffekten för Resource Manager lägen.

"then": {
    "effect": "audit"
}

Exempel 2: Använda granskningseffekten för resursproviderläget Microsoft.Kubernetes.Data . Den ytterligare informationen i details.templateInfo deklarerar användningen av PublicURL och anger platsen för constraint-mallen som ska användas i Kubernetes för att begränsa de tillåtna url containeravbildningarna.

"then": {
    "effect": "audit",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

AuditIfNotExists

AuditIfNotExists möjliggör granskning av resurser relaterade till resursen som matchar if-villkoret, men inte har de egenskaper som anges i informationen om villkoret.

AuditIfNotExists-utvärdering

AuditIfNotExists körs efter att en resursprovider har hanterat en begäran om att skapa eller uppdatera en resurs och har returnerat en statuskod för lyckad körning. Granskningen inträffar om det inte finns några relaterade resurser eller om resurserna som definieras av ExistenceCondition inte utvärderas till true. För nya och uppdaterade resurser Azure Policy lägger till en åtgärd i aktivitetsloggen och markerar resursen som Microsoft.Authorization/policies/audit/action icke-kompatibel. När den utlöses är den resurs som uppfyllt if-villkoret den resurs som markerats som icke-kompatibel.

Egenskaper för AuditIfNotExists

Informationsegenskapen för AuditIfNotExists-effekterna har alla underegenskaper som definierar de relaterade resurserna som ska matchas.

• Typ (krävs)
  • Anger vilken typ av relaterad resurs som ska matchas.
  • Om details.type är en resurstyp under if-villkorsresursen frågar principen efter resurser av den här typen inom omfånget för den utvärderade resursen. Annars kan principfrågor inom samma resursgrupp som den utvärderade resursen.
• Namn (valfritt)
  • Anger det exakta namnet på resursen som ska matchas och gör att principen hämtar en specifik resurs i stället för alla resurser av den angivna typen.
  • När villkorsvärdena för if.field.type och then.details.type matchar, blir Name obligatoriskt och måste vara , eller för en underordnad [field('name')] [field('fullName')] resurs. En granskningseffekt bör dock övervägas i stället.
• ResourceGroupName (valfritt)
  • Gör att matchningen av den relaterade resursen kan komma från en annan resursgrupp.
  • Gäller inte om typen är en resurs som finns under if-villkorsresursen.
  • Standardvärdet är if-villkorsresursens resursgrupp.
• ExistenceScope (valfritt)
  • Tillåtna värden är Subscription och ResourceGroup.
  • Anger omfånget för var den relaterade resursen ska hämtas att matcha från.
  • Gäller inte om typen är en resurs som finns under if-villkorsresursen.
  • För ResourceGroup skulle begränsa till if-villkorets resursgrupp eller resursgruppen som anges i ResourceGroupName.
  • För Prenumeration frågar hela prenumerationen efter den relaterade resursen. Tilldelningsomfånget ska anges till prenumerationen eller högre för korrekt utvärdering.
  • Standardvärdet är ResourceGroup.
• EvaluationDelay (valfritt)
  • Anger när förekomsten av relaterade resurser ska utvärderas. Fördröjningen används endast för utvärderingar som är ett resultat av en begäran om att skapa eller uppdatera resurs.
  • Tillåtna värden AfterProvisioning är , , eller en ISO AfterProvisioningSuccess AfterProvisioningFailure 8601-varaktighet mellan 0 och 360 minuter.
  • AfterProvisioning-värdena inspekterar etableringsresultatet för resursen som utvärderades i principregelns IF-villkor. AfterProvisioning körs när etableringen är klar, oavsett resultat. Om etableringen tar längre tid än 6 timmar behandlas den som ett fel när du fastställer efteretablering av utvärderingsfördröjningar.
  • Standardvärdet PT10M är (10 minuter).
  • Om du anger en lång utvärderingsfördröjning kan det leda till att resursens registrerade kompatibilitetstillstånd inte uppdateras förrän nästa utvärdering utlöser.
• ExistenceCondition (valfritt)
  • Om inget anges uppfyller alla relaterade resurser av typen effekten och utlöser inte granskningen.
  • Använder samma språk som principregeln för if-villkoret, men utvärderas mot varje relaterad resurs individuellt.
  • Om en matchande relaterad resurs utvärderas till sant uppfylls effekten och utlöser inte granskningen.
  • Kan använda [field()] för att kontrollera likvärdighet med värden i if-villkoret.
  • Kan till exempel användas för att verifiera att den överordnade resursen (i if-villkoret) finns på samma resursplats som den matchande relaterade resursen.

AuditIfNotExists-exempel

Exempel: Utvärderar Virtual Machines för att avgöra om tillägget mot skadlig programvara finns och granskar sedan om det saknas.

{
    "if": {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
    },
    "then": {
        "effect": "auditIfNotExists",
        "details": {
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
                "allOf": [{
                        "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                        "equals": "Microsoft.Azure.Security"
                    },
                    {
                        "field": "Microsoft.Compute/virtualMachines/extensions/type",
                        "equals": "IaaSAntimalware"
                    }
                ]
            }
        }
    }
}

Neka

Neka används för att förhindra en resursbegäran som inte matchar definierade standarder via en principdefinition och misslyckas med begäran.

Neka utvärdering

När du skapar eller uppdaterar en matchad resurs i Resource Manager läge förhindrar neka begäran innan den skickas till resursprovidern. Begäran returneras som 403 (Forbidden) en . I portalen kan förbjuden visas som en status för distributionen som förhindrades av principtilldelningen. För ett resursproviderläge hanterar resursprovidern utvärderingen av resursen.

Under utvärderingen av befintliga resurser markeras resurser som matchar en principdefinition för att neka som icke-kompatibla.

Neka egenskaper

För ett Resource Manager-läge har neka-effekten inga ytterligare egenskaper för användning i sedan-villkoret för principdefinitionen.

För resursproviderläget Microsoft.Kubernetes.Data har neka-effekten följande ytterligare underegenskaper med information. Användning av templateInfo krävs för nya eller uppdaterade principdefinitioner eftersom är constraintTemplate inaktuella.

• templateInfo (krävs)
  • Kan inte användas med constraintTemplate .
  • sourceType (krävs)

    • Definierar typen av källa för begränsningsmallen. Tillåtna värden: PublicURL eller Base64Kodad.

    • Om PublicURL är kopplat till egenskapen url för att ange platsen för begränsningsmallen. Platsen måste vara offentligt tillgänglig.

      Varning

      Använd inte SAS-URI:er eller token i url eller något annat som kan exponera en hemlighet.

    • Om Base64Encoded, paras med egenskapen för att tillhandahålla mallen för base content 64-kodad begränsning. Se Skapa principdefinition från en begränsningsmall för att skapa en anpassad definition från en befintlig OPA-mall (Open Policy Agent) GateKeeper v3-begränsning.

• constraint (valfritt)
  • Kan inte användas med templateInfo .
  • CRD-implementeringen av begränsningsmallen. Använder parametrar som skickas via värden som {{ .Values.<valuename> }} . I exempel 2 nedan är dessa värden {{ .Values.excludedNamespaces }} och {{ .Values.allowedContainerImagesRegex }} .
• namnrymder (valfritt)
  • En matris med Kubernetes-namnrymder att begränsa principutvärderingen till.
  • Ett tomt eller saknat värde gör att principutvärderingen inkluderar alla namnområden, förutom de som definieras i excludedNamespaces.
• excludedNamespaces (krävs)
  • En matris med Kubernetes-namnrymder som ska undantas från principutvärderingen.
• labelSelector (krävs)
  • Ett objekt som innehåller egenskaperna matchLabels (objekt) och matchExpression (matris) så att du kan ange vilka Kubernetes-resurser som ska inkluderas för principutvärdering som matchade de angivna etiketterna och väljarna.
  • Ett tomt eller saknat värde gör att principutvärderingen inkluderar alla etiketter och väljare, förutom namnområden som definieras i excludedNamespaces.
• apiGroups (krävs när du använder templateInfo)
  • En matris som innehåller de API-grupper som ska matchas. En tom matris ( [""] ) är den centrala API-gruppen medan matchar alla ["*"] API-grupper.
• -typer (krävs när du använder templateInfo)
  • En matris som innehåller den typ av Kubernetes-objekt som utvärderingen ska begränsas till.
• värden (valfritt)
  • Definierar alla parametrar och värden som ska överföras till begränsningen. Varje värde måste finnas i CRD-mallen Begränsning.
• constraintTemplate (inaktuell)
  • Kan inte användas med templateInfo .
  • Måste ersättas med när templateInfo du skapar eller uppdaterar en principdefinition.
  • Mallen Constraint CustomResourceDefinition (CRD) som definierar nya begränsningar. Mallen definierar Rego-logiken, schemat för begränsning och de begränsningsparametrar som skickas via värden från Azure Policy. Vi rekommenderar att du använder den nyare templateInfo för att ersätta constraintTemplate .

Neka exempel

Exempel 1: Använd neka-effekten för Resource Manager lägena.

"then": {
    "effect": "deny"
}

Exempel 2: Använd neka-effekten för resursproviderläget Microsoft.Kubernetes.Data . Den ytterligare informationen i details.templateInfo deklarerar användningen av PublicURL och anger platsen för den begränsningsmall som ska användas i Kubernetes för att begränsa de tillåtna url containeravbildningarna.

"then": {
    "effect": "deny",
    "details": {
        "templateInfo": {
            "sourceType": "PublicURL",
            "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
        },
        "values": {
            "imageRegex": "[parameters('allowedContainerImagesRegex')]"
        },
        "apiGroups": [""],
        "kinds": ["Pod"]
    }
}

DeployIfNotExists

Precis som AuditIfNotExists kör en DeployIfNotExists-principdefinition en malldistribution när villkoret uppfylls.

DeployIfNotExists-utvärdering

DeployIfNotExists körs efter en konfigurerbar fördröjning när en resursprovider hanterar en skapa eller uppdatera prenumeration eller resursbegäran och har returnerat en statuskod för lyckad körning. En malldistribution sker om det inte finns några relaterade resurser eller om resurserna som definieras av ExistenceCondition inte utvärderas till true. Distributionens varaktighet beror på komplexiteten för de resurser som ingår i mallen.

Under en utvärderingscykel markeras principdefinitioner med en DeployIfNotExists-effekt som matchar resurser som icke-kompatibla, men ingen åtgärd vidtas på den resursen. Befintliga icke-kompatibla resurser kan åtgärdas med en reparationsuppgift.

DeployIfNotExists-egenskaper

Informationsegenskapen för effekten DeployIfNotExists har alla underegenskaper som definierar de relaterade resurser som ska matchas och malldistributionen som ska köras.

• Typ (krävs)

  • Anger vilken typ av relaterad resurs som ska matchas.
  • Börjar med att försöka hämta en resurs under if-villkorsresursen och frågar sedan i samma resursgrupp som if-villkorsresursen.

• Namn (valfritt)

  • Anger det exakta namnet på resursen som ska matchas och gör att principen hämtar en specifik resurs i stället för alla resurser av den angivna typen.
  • När villkorsvärdena för if.field.type och then.details.type matchar, blir Name obligatoriskt och måste vara , eller för en underordnad [field('name')] [field('fullName')] resurs.

• ResourceGroupName (valfritt)

  • Gör att matchningen av den relaterade resursen kommer från en annan resursgrupp.
  • Gäller inte om typen är en resurs som skulle vara under if-villkorsresursen.
  • Standardvärdet är if-villkorsresursens resursgrupp.
  • Om en malldistribution körs distribueras den i resursgruppen för det här värdet.

• ExistenceScope (valfritt)

  • Tillåtna värden är Prenumeration och ResourceGroup.
  • Anger omfånget för varifrån den relaterade resursen ska hämtas.
  • Gäller inte om typen är en resurs som skulle vara under if-villkorsresursen.
  • För ResourceGroup skulle begränsa till if-villkorets resursgrupp eller resursgruppen som anges i ResourceGroupName.
  • För Prenumeration frågar hela prenumerationen efter den relaterade resursen. Tilldelningsomfånget ska anges för prenumerationen eller högre för korrekt utvärdering.
  • Standardvärdet är ResourceGroup.

• EvaluationDelay (valfritt)

  • Anger när förekomsten av relaterade resurser ska utvärderas. Fördröjningen används endast för utvärderingar som är ett resultat av en begäran om att skapa eller uppdatera resurser.
  • Tillåtna värden AfterProvisioning är , , eller en ISO AfterProvisioningSuccess AfterProvisioningFailure 8601-varaktighet mellan 0 och 360 minuter.
  • AfterProvisioning-värdena inspekterar etableringsresultatet för resursen som utvärderades i principregelns IF-villkor. AfterProvisioning körs när etableringen är klar, oavsett resultat. Om etableringen tar längre tid än 6 timmar behandlas den som ett fel när du fastställer efteretablering av utvärderingsfördröjningar.
  • Standardvärdet PT10M är (10 minuter).
  • Om du anger en lång utvärderingsfördröjning kan det registrerade kompatibilitetstillståndet för resursen inte uppdateras förrän nästa utvärdering utlöser.

• ExistenceCondition (valfritt)

  • Om inget anges uppfyller alla relaterade resurser av typen effekten och utlöser inte distributionen.
  • Använder samma språk som principregeln för if-villkoret, men utvärderas mot varje relaterad resurs individuellt.
  • Om en matchande relaterad resurs utvärderas som sann uppfylls effekten och utlöser inte distributionen.
  • Kan använda [field()] för att kontrollera likvärdighet med värden i if-villkoret.
  • Kan till exempel användas för att verifiera att den överordnade resursen (i if-villkoret) finns på samma resursplats som den matchande relaterade resursen.

• roleDefinitionIds (krävs)

  • Den här egenskapen måste innehålla en matris med strängar som matchar rollbaserad åtkomstkontrollroll-ID som kan nås av prenumerationen. Mer information finns i Reparation – konfigurera principdefinitionen.

• DeploymentScope (valfritt)

  • Tillåtna värden är Prenumeration och ResourceGroup.
  • Anger vilken typ av distribution som ska utlösas. Prenumeration anger en distribution på prenumerationsnivå, ResourceGroup anger en distribution till en resursgrupp.
  • En platsegenskap måste anges i Distribution när du använder distributioner på prenumerationsnivå.
  • Standardvärdet är ResourceGroup.

• Distribution (krävs)

  • Den här egenskapen bör innehålla den fullständiga malldistributionen eftersom den skulle skickas till Microsoft.Resources/deployments PUT-API:et. Mer information finns i Distributioner REST API.
  • Microsoft.Resources/deploymentsKapslade i mallen bör använda unika namn för att undvika motdrift mellan flera principutvärderingar. Den överordnade distributionens namn kan användas som en del av det kapslade distributionsnamnet via [concat('NestedDeploymentName-', uniqueString(deployment().name))] .

  Anteckning

  Alla funktioner i egenskapen Distribution utvärderas som komponenter i mallen, inte principen. Undantaget är parameteregenskapen som skickar värden från principen till mallen. Värdet i det här avsnittet under ett mallparameternamn används för att skicka det här värdet (se fullDbName i exemplet DeployIfNotExists).

DeployIfNotExists-exempel

Exempel: Utvärderar SQL Server för att avgöra om transparentDataEncryption är aktiverat. Annars körs en distribution som ska aktiveras.

"if": {
    "field": "type",
    "equals": "Microsoft.Sql/servers/databases"
},
"then": {
    "effect": "DeployIfNotExists",
    "details": {
        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
        "name": "current",
        "evaluationDelay": "AfterProvisioning",
        "roleDefinitionIds": [
            "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
            "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
        ],
        "existenceCondition": {
            "field": "Microsoft.Sql/transparentDataEncryption.status",
            "equals": "Enabled"
        },
        "deployment": {
            "properties": {
                "mode": "incremental",
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "fullDbName": {
                            "type": "string"
                        }
                    },
                    "resources": [{
                        "name": "[concat(parameters('fullDbName'), '/current')]",
                        "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
                        "apiVersion": "2014-04-01",
                        "properties": {
                            "status": "Enabled"
                        }
                    }]
                },
                "parameters": {
                    "fullDbName": {
                        "value": "[field('fullName')]"
                    }
                }
            }
        }
    }
}

Inaktiverad

Den här effekten är användbar för att testa situationer eller när principdefinitionen har parametriserat effekten. Den här flexibiliteten gör det möjligt att inaktivera en enskild tilldelning i stället för att inaktivera alla tilldelningar för principen.

Ett alternativ till den inaktiverade effekten är enforcementMode, som anges för principtilldelningen. När enforcementMode är Inaktiverat utvärderas fortfarande resurser. Loggning, till exempel aktivitetsloggar, och principeffekten inträffar inte. Mer information finns i principtilldelning – tvingande läge.

EnforceOPAConstraint

Den här effekten används med principdefinitionsläget Microsoft.Kubernetes.Data . Den används för att skicka Gatekeeper v3-regler för antagningskontroll som definierats med OPA Constraint Framework till Open Policy Agent (OPA) till Kubernetes-kluster i Azure.

EnforceOPAConstraint-utvärdering

Antagningskontrollanten för Open Policy Agent utvärderar alla nya förfrågningar i klustret i realtid. Var 15:e minut slutförs en fullständig genomsökning av klustret och resultatet rapporteras till Azure Policy.

EnforceOPAConstraint-egenskaper

Informationsegenskapen för EnforceOPAConstraint-effekten har underegenskaperna som beskriver regeln för gatekeeper v3-antagningskontroll.

• constraintTemplate (krävs)
  • Mallen Constraint CustomResourceDefinition (CRD) som definierar nya begränsningar. Mallen definierar Rego-logiken, schemat för begränsning och de begränsningsparametrar som skickas via värden från Azure Policy.
• constraint (krävs)
  • CRD-implementeringen av begränsningsmallen. Använder parametrar som skickas via värden som {{ .Values.<valuename> }} . I följande exempel är dessa värden {{ .Values.cpuLimit }} och {{ .Values.memoryLimit }} .
• värden (valfritt)
  • Definierar alla parametrar och värden som ska överföras till begränsningen. Varje värde måste finnas i CRD-mallen Begränsning.

EnforceOPAConstraint-exempel

Exempel: Gatekeeper v3-antagningskontrollregel för att ange gränser för containerns CPU- och minnesresurser i Kubernetes.

"if": {
    "allOf": [
        {
            "field": "type",
            "in": [
                "Microsoft.ContainerService/managedClusters",
                "AKS Engine"
            ]
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "enforceOPAConstraint",
    "details": {
        "constraintTemplate": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/template.yaml",
        "constraint": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-resource-limits/constraint.yaml",
        "values": {
            "cpuLimit": "[parameters('cpuLimit')]",
            "memoryLimit": "[parameters('memoryLimit')]"
        }
    }
}

EnforceRegoPolicy

Den här effekten används med principdefinitionsläget Microsoft.ContainerService.Data . Den används för att skicka gatekeeper v2-regler för antagningskontroll som definierats med Rego till Open Policy Agent (OPA) Azure Kubernetes Service.

EnforceRegoPolicy-utvärdering

Antagningskontrollanten för Open Policy Agent utvärderar alla nya förfrågningar i klustret i realtid. Var 15:e minut slutförs en fullständig genomsökning av klustret och resultatet rapporteras till Azure Policy.

EnforceRegoPolicy-egenskaper

Informationsegenskapen för EnforceRegoPolicy-effekten har underegenskaperna som beskriver regeln för gatekeeper v2-antagningskontroll.

• policyId (krävs)
  • Ett unikt namn som skickas som en parameter till regeln för Rego-antagningskontroll.
• princip (krävs)
  • Anger URI för regeln för Rego-antagningskontroll.
• policyParameters (valfritt)
  • Definierar alla parametrar och värden som ska överföras till rego-principen.

EnforceRegoPolicy-exempel

Exempel: Gatekeeper v2-antagningskontrollregel för att endast tillåta de angivna containeravbildningarna i AKS.

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.ContainerService/managedClusters"
        },
        {
            "field": "location",
            "equals": "westus2"
        }
    ]
},
"then": {
    "effect": "EnforceRegoPolicy",
    "details": {
        "policyId": "ContainerAllowedImages",
        "policy": "https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/KubernetesService/container-allowed-images/limited-preview/gatekeeperpolicy.rego",
        "policyParameters": {
            "allowedContainerImagesRegex": "[parameters('allowedContainerImagesRegex')]"
        }
    }
}

Ändra

Ändra används för att lägga till, uppdatera eller ta bort egenskaper eller taggar för en prenumeration eller resurs under skapandet eller uppdateringen. Ett vanligt exempel är att uppdatera taggar på resurser som costCenter. Befintliga icke-kompatibla resurser kan åtgärdas med en reparationsuppgift. En enda ändringsregel kan ha val av antal åtgärder.

Följande åtgärder stöds av Ändra:

• Lägga till, ersätta eller ta bort resurstaggar. För taggar ska principen Ändra ha mode angetts till Indexerad om inte målresursen är en resursgrupp.
• Lägg till eller ersätt värdet för hanterad identitetstyp ( identity.type ) för virtuella datorer och VM-skalningsuppsättningar.
• Lägg till eller ersätt värdena för vissa alias.
  • Använda Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } i Azure PowerShell 4.6.0 eller senare för att hämta en lista över alias som kan användas med Ändra.

Ändra utvärdering

Ändra utvärderas innan begäran bearbetas av en resursprovider när en resurs skapas eller uppdateras. Ändringsåtgärder tillämpas på begärandeinnehållet när if-villkoret för principregeln uppfylls. Varje ändringsåtgärd kan ange ett villkor som avgör när det tillämpas. Åtgärder med villkor som utvärderas som false hoppas över.

När ett alias anges utförs följande ytterligare kontroller för att säkerställa att åtgärden Ändra inte ändrar begärandeinnehållet på ett sätt som gör att resursprovidern avvisar det:

• Egenskapen som aliaset mappar till markeras som "Ändringsbar" i begärans API-version.
• Tokentypen i åtgärden Ändra matchar den förväntade tokentypen för egenskapen i begärans API-version.

Om någon av dessa kontroller misslyckas faller principutvärderingen tillbaka till den angivna conflictEffect.

När en principdefinition som använder effekten Ändra körs som en del av en utvärderingscykel görs inga ändringar i resurser som redan finns. I stället markerar den alla resurser som uppfyller if-villkoret som icke-kompatibla.

Ändra egenskaper

Informationsegenskapen för effekten Ändra har alla underegenskaper som definierar de behörigheter som krävs för reparation och de åtgärder som används för att lägga till, uppdatera eller ta bort taggvärden.

• roleDefinitionIds (krävs)
  • Den här egenskapen måste innehålla en matris med strängar som matchar rollbaserad åtkomstkontrollroll-ID som kan nås av prenumerationen. Mer information finns i Reparation – konfigurera principdefinitionen.
  • Den definierade rollen måste innehålla alla åtgärder som beviljas rollen Deltagare.
• conflictEffect (valfritt)
  • Avgör vilken principdefinition som "vinner" om mer än en principdefinition ändrar samma egenskap eller när åtgärden Ändra inte fungerar på det angivna aliaset.
    • För nya eller uppdaterade resurser har principdefinitionen med nekande företräde. Principdefinitioner med granskning hoppar över alla åtgärder. Om mer än en principdefinition har nekat nekas begäran som en konflikt. Om alla principdefinitioner har granskning bearbetas ingen av åtgärderna i motstridiga principdefinitioner.
    • Om fler än en principdefinition har nekat för befintliga resurser är kompatibilitetsstatusen Konflikt. Om en eller färre principdefinitioner har nekat returnerar varje tilldelning kompatibilitetsstatusen Icke-kompatibel.
  • Tillgängliga värden: granska, neka, inaktiverad.
  • Standardvärdet nekar.
• åtgärder (krävs)
  • En matris med alla taggåtgärder som ska utföras på matchande resurser.
  • Egenskaper:
    • åtgärd (krävs)
      • Definierar vilken åtgärd som ska vidtas på en matchande resurs. Alternativen är: addOrReplace, Add, Remove. Lägg till fungerar ungefär som tilläggseffekten.
    • fält (krävs)
      • Taggen för att lägga till, ersätta eller ta bort. Taggnamn måste följa samma namngivningskonvention för andra fält.
    • värde (valfritt)
      • Värdet som taggen ska anges till.
      • Den här egenskapen krävs om åtgärden är addOrReplace eller Add .
    • villkor (valfritt)
      • En sträng som innehåller Azure Policy ett språkuttryck med principfunktioner som utvärderas till sant eller falskt.
      • Stöder inte följande principfunktioner: field() , resourceGroup() , subscription() .

Ändra åtgärder

Matrisen för operationsegenskap gör det möjligt att ändra flera taggar på olika sätt från en enda principdefinition. Varje åtgärd består av egenskaperna åtgärd, fält och värde. Åtgärden avgör vad reparationsaktiviteten gör med taggarna, fältet avgör vilken tagg som ändras och värdet definierar den nya inställningen för den taggen. Följande exempel gör följande taggändringar:

• Anger environment taggen till "Test", även om den redan finns med ett annat värde.
• Tar bort taggen TempResource .
• Anger Dept taggen till principparametern DeptName som konfigurerats för principtilldelningen.

"details": {
    ...
    "operations": [
        {
            "operation": "addOrReplace",
            "field": "tags['environment']",
            "value": "Test"
        },
        {
            "operation": "Remove",
            "field": "tags['TempResource']",
        },
        {
            "operation": "addOrReplace",
            "field": "tags['Dept']",
            "value": "[parameters('DeptName')]"
        }
    ]
}

Åtgärdsegenskapen har följande alternativ:

Ändra exempel

Exempel 1: Lägg till environment taggen och ersätt befintliga environment taggar med "Test":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "Test"
            }
        ]
    }
}

Exempel 2: Ta bort env taggen och lägg till environment taggen eller ersätt befintliga environment taggar med ett parametriserat värde:

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "conflictEffect": "deny",
        "operations": [
            {
                "operation": "Remove",
                "field": "tags['env']"
            },
            {
                "operation": "addOrReplace",
                "field": "tags['environment']",
                "value": "[parameters('tagValue')]"
            }
        ]
    }
}

Exempel 3: Se till att ett lagringskonto inte tillåter offentlig blobåtkomst. Åtgärden Ändra tillämpas endast vid utvärdering av begäranden med EN API-version som är större än eller lika med "2019-04-01":

"then": {
    "effect": "modify",
    "details": {
        "roleDefinitionIds": [
            "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
        ],
        "conflictEffect": "audit",
        "operations": [
            {
                "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
                "operation": "addOrReplace",
                "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "value": false
            }
        ]
    }
}

Principdefinitioner för skiktning

En resurs kan påverkas av flera tilldelningar. Dessa tilldelningar kan finnas i samma omfång eller i olika omfång. Var och en av dessa tilldelningar har troligen också en annan effekt definierad. Villkoret och effekten för varje princip utvärderas oberoende av varandra. Exempel:

• Princip 1
  • Begränsar resursplatsen till "westus"
  • Tilldelad till prenumeration A
  • Neka-effekt
• Princip 2
  • Begränsar resursplatsen till "eastus"
  • Tilldelad till resursgrupp B i prenumeration A
  • Granskningseffekt

Den här konfigurationen skulle resultera i följande resultat:

• Alla resurser som redan finns i resursgrupp B i "eastus" är kompatibla med princip 2 och icke-kompatibla med princip 1
• Alla resurser som redan finns i resursgrupp B som inte finns i "eastus" är icke-kompatibla med princip 2 och icke-kompatibla med princip 1 om de inte är i "westus"
• Alla nya resurser i prenumeration A som inte finns i "westus" nekas av princip 1
• Alla nya resurser i prenumeration A och resursgrupp B i "westus" skapas och är icke-kompatibla med princip 2

Om både princip 1 och princip 2 hade effekt av neka ändras situationen till:

• Alla resurser som redan finns i resursgrupp B som inte finns i "eastus" är icke-kompatibla med princip 2
• Alla resurser som redan finns i resursgrupp B som inte finns i "westus" är icke-kompatibla med princip 1
• Alla nya resurser i prenumeration A som inte finns i "westus" nekas av princip 1
• Alla nya resurser i resursgrupp B i prenumeration A nekas

Varje tilldelning utvärderas individuellt. Därför finns det ingen möjlighet för en resurs att gå igenom en lucka från skillnader i omfång. Nettoresultatet av principdefinitioner för skiktning anses vara kumulativt mest restriktiva. Om både princip 1 och 2 till exempel hade en neka-effekt skulle en resurs blockeras av de överlappande och motstridiga principdefinitionerna. Om du fortfarande behöver skapa resursen i målomfånget granskar du undantagen för varje tilldelning för att verifiera att rätt principtilldelningar påverkar rätt omfång.

Nästa steg

• Granska exempel på Azure Policy exempel.
• Granska Azure Policy-definitionsstrukturen.
• Förstå hur du programmässigt skapar principer.
• Lär dig hur du hämtar efterlevnadsdata.
• Lär dig hur du åtgärdar icke-kompatibla resurser.
• Granska vad en hanteringsgrupp är med Organisera dina resurser med Azure-hanteringsgrupper.