Dela via

Grunderna i Azure Policy-definitionsstruktur

  • Artikel

Azure Policy-definitioner beskriver resursefterlevnadsvillkor och vilken effekt som ska gälla om ett villkor uppfylls. Ett villkor jämför ett fält eller ett värde för en resursegenskap med ett obligatoriskt värde. Resursegenskapsfält används med hjälp av alias. När ett resursegenskapsfält är en matris kan ett särskilt matrisalias användas för att välja värden från alla matrismedlemmar och tillämpa ett villkor på var och en. Läs mer om villkor.

Genom att använda principtilldelningar kan du styra kostnader och hantera dina resurser. Du kan till exempel ange att endast vissa typer av virtuella datorer tillåts. Eller så kan du kräva att resurserna har en viss tagg. Tilldelningar i ett omfång gäller för alla resurser i det omfånget och nedan. Om en principtilldelning används för en resursgrupp är den tillämplig på alla resurser i den resursgruppen.

Du använder JSON för att skapa en principdefinition som innehåller element för:

  • displayName
  • description
  • mode
  • version
  • metadata
  • parameters
  • policyRule
    • logiska utvärderingar
    • effect

Följande JSON visar till exempel en princip som begränsar var resurser distribueras:

{
  "properties": {
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "metadata": {
      "version": "1.0.0",
      "category": "Locations"
    },
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [
          "westus2"
        ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Mer information finns i principdefinitionsschemat. Inbyggda Azure Policy-mönster finns i Azure Policy-exempel.

Visningsnamn och beskrivning

Du använder displayName och description för att identifiera principdefinitionen och ange kontext för när definitionen används. Har displayName en maximal längd på 128 tecken och description en maximal längd på 512 tecken.

Kommentar

När du skapar eller uppdaterar en principdefinition iddefinieras , typeoch name av egenskaper utanför JSON och behövs inte i JSON-filen. Om du hämtar principdefinitionen via SDK returneras idegenskaperna , typeoch som en del av JSON, men var och name en är skrivskyddad information som är relaterad till principdefinitionen.

Principtyp

policyType Egenskapen kan inte anges, men det finns tre värden som returneras av SDK och visas i portalen:

  • Builtin: Microsoft tillhandahåller och underhåller dessa principdefinitioner.
  • Custom: Alla principdefinitioner som skapats av kunder har det här värdet.
  • Static: Anger en principdefinition för regelefterlevnad med Microsoft Ownership. Efterlevnadsresultaten för dessa principdefinitioner är resultatet av granskningar som inte kommer från Microsoft av Microsofts infrastruktur. I Azure Portal visas det här värdet ibland som Microsoft-hanterat. Mer information finns i Delat ansvar i molnet.

Läge

mode Konfigureras beroende på om principen är riktad mot en Azure Resource Manager-egenskap eller en resursprovideregenskap.

Resource Manager-lägen

Avgör mode vilka resurstyper som utvärderas för en principdefinition. De lägen som stöds är:

  • all: utvärdera resursgrupper, prenumerationer och alla resurstyper
  • indexed: Utvärdera endast resurstyper som stöder taggar och platser

Resursen stöder till exempel Microsoft.Network/routeTables taggar och platser och utvärderas i båda lägena. Resursen kan dock Microsoft.Network/routeTables/routes inte taggas och utvärderas inte i indexed läge.

Vi rekommenderar att du anger mode till all i de flesta fall. Alla principdefinitioner som skapas via portalen använder all läget. Om du använder PowerShell eller Azure CLI kan du ange parametern mode manuellt. Om principdefinitionen inte innehåller något mode värde, är det som standard all i Azure PowerShell och null i Azure CLI. Ett null läge är detsamma som att använda indexed för att stödja bakåtkompatibilitet.

indexed bör användas när du skapar principer som tillämpar taggar eller platser. Även om det inte krävs förhindrar det att resurser som inte stöder taggar och platser visas som icke-kompatibla i efterlevnadsresultaten. Undantaget är resursgrupper och prenumerationer. Principdefinitioner som framtvingar plats eller taggar i en resursgrupp eller prenumeration bör anges mode till all och specifikt riktas mot Microsoft.Resources/subscriptions/resourceGroups eller-typen Microsoft.Resources/subscriptions . Ett exempel finns i Mönster: Taggar – Exempel 1. En lista över resurser som stöder taggar finns i Taggstöd för Azure-resurser.

Lägen för resursprovider

Följande lägen för resursprovider stöds fullt ut:

Följande lägen för resursprovider stöds för närvarande som en förhandsversion:

  • Microsoft.ManagedHSM.Data för att hantera HSM-nycklar (Managed Hardware Security Module) med hjälp av Azure Policy.
  • Microsoft.DataFactory.Data för att använda Azure Policy för att neka utgående trafikdomännamn för Azure Data Factory som inte anges i en tillåtna lista. Det här läget för resursprovider är endast tvingande och rapporterar inte efterlevnad i offentlig förhandsversion.
  • Microsoft.MachineLearningServices.v2.Data för att hantera distributioner av Azure Machine Learning-modell . Det här resursproviderläget rapporterar efterlevnad för nyligen skapade och uppdaterade komponenter. Under allmänt tillgänglig förhandsversion finns efterlevnadsposter kvar i 24 timmar. Modelldistributioner som finns innan dessa principdefinitioner tilldelas rapporterar inte efterlevnad.
  • Microsoft.LoadTestService.Data för att begränsa Azure Load Testing-instanser till privata slutpunkter.

Kommentar

Om inte uttryckligen anges stöder resursproviderlägen endast inbyggda principdefinitioner och undantag stöds inte på komponentnivå.

När Azure Policy-versionshantering släpps har följande lägen för resursprovider inte stöd för inbyggd versionshantering:

  • Microsoft.DataFactory.Data
  • Microsoft.MachineLearningServices.v2.Data
  • Microsoft.ManagedHSM.Data

Version (förhandsversion)

Inbyggda principdefinitioner kan vara värd för flera versioner med samma definitionID. Om inget versionsnummer anges visar alla funktioner den senaste versionen av definitionen. Om du vill se en specifik version av en inbyggd version måste den anges i API, SDK eller användargränssnitt. Information om hur du refererar till en specifik version av en definition i en tilldelning finns i definitionsversion inom tilldelning

Azure Policy-tjänsten använder versionegenskaperna , previewoch deprecated för att förmedla tillstånd och ändringsnivå till en inbyggd principdefinition eller ett initiativ. Formatet version är: {Major}.{Minor}.{Patch}. När en principdefinition är i förhandsversionstillstånd läggs förhandsgranskningen av suffixet till i version egenskapen och behandlas som ett booleskt värde. När en principdefinition är inaktuell registreras utfasningen som ett booleskt värde i definitionens metadata med hjälp av "deprecated": "true".

  • Huvudversion (exempel: 2.0.0): Introducera icke-bakåtkompatibla ändringar, till exempel större regellogikändringar, ta bort parametrar och lägga till en tillämpningseffekt som standard.
  • Delversion (exempel: 2.1.0): introducera ändringar som mindre regellogikändringar, lägga till nya tillåtna parametervärden, ändra till , lägga till roleDefinitionIdseller flytta definitioner inom ett initiativ.
  • Korrigeringsversion (exempel: 2.1.4): Introducera sträng- eller metadataändringar och säkerhetsscenarier för brytglas (sällsynta).

Mer information om inbyggda Azure Policy-versioner finns i Inbyggd versionshantering. Mer information om vad det innebär för en princip att bli inaktuell eller i förhandsversion finns i Förhandsversion och inaktuella principer.

Metadata

Den valfria metadata egenskapen lagrar information om principdefinitionen. Kunder kan definiera alla egenskaper och värden som är användbara för organisationen i metadata. Det finns dock några vanliga egenskaper som används av Azure Policy och i inbyggda. Varje metadata egenskap har en gräns på 1 024 tecken.

Vanliga metadataegenskaper

  • version (sträng): Spårar information om versionen av innehållet i en principdefinition.
  • category(sträng): Avgör under vilken kategori i Azure Portal principdefinitionen visas.
  • preview (booleskt): Sant eller falskt flagga för om principdefinitionen är förhandsversion.
  • deprecated (booleskt): Sant eller falskt flagga för om principdefinitionen har markerats som inaktuell.
  • portalReview (sträng): Avgör om parametrar ska granskas i portalen, oavsett vilka indata som krävs.

Definitionsplats

När du skapar ett initiativ eller en princip måste du ange definitionsplatsen. Definitionsplatsen måste vara en hanteringsgrupp eller en prenumeration. Den här platsen avgör omfånget som initiativet eller principen kan tilldelas till. Resurser måste vara direkta medlemmar i eller underordnade i hierarkin för den definitionsplats som ska riktas för tilldelning.

Om definitionsplatsen är en:

  • Prenumeration – Endast resurser inom den prenumerationen kan tilldelas principdefinitionen.
  • Hanteringsgrupp – Endast resurser i underordnade hanteringsgrupper och underordnade prenumerationer kan tilldelas principdefinitionen. Om du planerar att tillämpa principdefinitionen på flera prenumerationer måste platsen vara en hanteringsgrupp som innehåller varje prenumeration.

Mer information finns i Förstå omfång i Azure Policy.

Nästa steg