View a markdown version of this page

Sintassi ed esempi delle policy di tag - AWS Organizations

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Sintassi ed esempi delle policy di tag

Questa pagina descrive la sintassi delle policy di tag e fornisce esempi.

Sintassi delle policy di tag

Una policy di tag è un file di testo normale strutturato in base alle regole di JSON. La sintassi per le politiche dei tag segue la sintassi per i tipi di policy dichiarative. Per una discussione completa di tale sintassi, consulta Comprendere l'ereditarietà delle politiche dichiarative. Questo argomento è incentrato sull'applicazione della sintassi generale ai requisiti specifici del tipo di policy di tag.

La seguente policy di tag mostra la sintassi della policy di tag di base:

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "100", "200", "300*" ] }, "enforced_for": { "@@assign": [ "secretsmanager:ALL_SUPPORTED" ] } } } }

La sintassi della policy di tag include i seguenti elementi:

  • Il nome della chiave di campo tags. Le policy di tag iniziano sempre con questo nome di chiave fisso. È la prima riga nella policy di esempio precedente.

  • Una chiave della policy che identifica in modo univoco l'istruzione della policy. Deve corrispondere al valore per la chiave di tag, ad eccezione del trattamento lettere maiuscole o minuscole. Il valore della policy distingue tra maiuscole e minuscole.

    In questo esempio, costcenter è la chiave della policy.

  • Almeno una chiave di tag che specifica la chiave di tag consentita con l'uso delle maiuscole e minuscole a cui desideri che le risorse siano conformi. Se il trattamento lettere maiuscole o minuscole non è definito, minuscole è il trattamento predefinito per le chiavi di tag. Il valore per la chiave di tag deve corrispondere al valore per la chiave della policy. Tuttavia, poiché il valore della chiave della policy non fa distinzione tra maiuscole e minuscole, l'uso delle maiuscole e delle minuscole può essere diverso.

    In questo esempio, CostCenter è la chiave di tag. Questo è il trattamento lettere maiuscole o minuscole che è richiesto per la conformità con la policy di tag. Le risorse con il trattamento alternativo lettere maiuscole o minuscole per questa chiave di tag non sono conformi con la policy di tag.

    In una policy di tag è possibile definire più chiavi di tag.

  • (Facoltativo) Un elenco di uno o più valori di tag accettabili per la chiave di tag. Se la policy di tag non specifica un valore di tag per una chiave di tag, qualsiasi valore (incluso nessun valore) viene considerato conforme.

    In questo esempio, i valori accettabili per la chiave del CostCenter tag sono 100200, e300*.

  • (Facoltativo) Un'opzione enforced_for che indica se impedire le operazioni di tag non conformi su servizi e risorse specificati. Nella console, questa è l'opzione Prevent noncompliant operations for this tag (Impedisci operazioni non conformi per questo tag) nell'editor visivo per la creazione di policy di tag. L'impostazione predefinita per questa opzione è null.

    L'esempio di tag policy specifica che il CostCenter tag applicato a tutte le AWS Secrets Manager risorse deve essere conforme a questo criterio.

    avvertimento

    Cambia l'impostazione predefinita di questa opzione solo se sei esperto dell'utilizzo delle policy di tag. In caso contrario, è possibile agli utenti degli account dell'organizzazione venga impedito di creare le risorse necessarie.

  • Operatori che specificano il modo in cui la policy di tag si unisce con altre policy di tag all'interno dell'albero dell'organizzazione per creare la policy di tag operativa di un account. In questo esempio, @@assign viene utilizzato per assegnare le stringhe a tag_key, tag_value e enforced_for. Per ulteriori informazioni sugli operatori, vedi Operatori di ereditarietà.

  • È possibile utilizzare il carattere * jolly nei valori dei tag.

    • Puoi utilizzare solo un carattere jolly per ogni valore di tag. Ad esempio, *@example.com è consentito, mentre non lo è *@*.com.

    • È possibile utilizzare il carattere ALL_SUPPORTED jolly sul enforced_for campo con alcuni servizi per abilitare l'applicazione di tutte le risorse supportate per quel servizio. Per un elenco dei servizi e dei tipi di risorse che supportano enforced_for, consultare Servizi e tipi di risorse che supportano l'applicazione.

    • Non è possibile utilizzare un carattere jolly per specificare tutti i servizi o per specificare una risorsa per tutti i servizi.

Esempi di policy con tag

Le policy di tag di esempio che seguono sono solo a scopo informativo.

Nota

Prima di tentare di utilizzare queste policy di tag di esempio nell'organizzazione, tieni presente quanto segue:

  • Assicurati di aver seguito il flusso di lavoro raccomandato per iniziare a utilizzare le policy di tag.

  • Esamina attentamente e personalizza queste policy di tag in base ai tuoi requisiti univoci.

  • Tutti i caratteri nella policy di tag sono soggetti a una dimensione massima. Gli esempi in questa guida mostrano le policy di tag formattate con spazio vuoto aggiuntivo per migliorarne la leggibilità. Tuttavia puoi eliminare qualsiasi spazio vuoto per risparmiare spazio, se la dimensione della policy si avvicina a quella massima. Esempi di spazio bianco includono gli spazi e le interruzioni di riga che sono al di fuori delle virgolette.

  • Le risorse senza tag non appaiono nei risultati come non conformi.

Esempio 1: definire l'uso delle maiuscole o minuscole per la chiave di tag a livello di organizzazione

Nell'esempio seguente viene illustrata una policy di tag che definisce solo due chiavi di tag e l'uso delle maiuscole e delle minuscole su cui si desidera che gli account dell'organizzazione vengano standardizzati.

Policy A: policy di tag della root dell'organizzazione

{ "tags": { "CostCenter": { "tag_key": { "@@assign": "CostCenter", "@@operators_allowed_for_child_policies": ["@@none"] } }, "Project": { "tag_key": { "@@assign": "Project", "@@operators_allowed_for_child_policies": ["@@none"] } } } }

Questa policy di tag definisce due chiavi tag: CostCenter e Project. Il collegamento di questa policy di tag alla root dell'organizzazione ha i seguenti effetti:

  • Tutti gli account dell'organizzazione ereditano questa policy di tag.

  • Tutti gli account dell'organizzazione devono utilizzare il trattamento lettere maiuscole o minuscole definito per la conformità. Le risorse con i tag CostCenter e Project sono conformi. Le risorse con il trattamento lettere maiuscole o minuscole alternativo per la chiave di tag (ad esempio costcenter, Costcenter o COSTCENTER) non sono conformi.

  • Le righe @@operators_allowed_for_child_policies": ["@@none"] bloccano le chiavi di tag. Le policy di tag collegate a un livello inferiore nell'albero dell'organizzazione (policy figlio) non possono utilizzare gli operatori di impostazione del valore per modificare la chiave di tag, incluso il trattamento lettere maiuscole o minuscole.

  • Nello stesso modo delle policy di tag, le risorse senza tag o i tag che non sono definiti nella policy di tag non vengono valutati per la conformità con la policy di tag.

AWS consiglia di utilizzare questo esempio come guida per la creazione di una politica di tag simile per le chiavi dei tag che si desidera utilizzare. Collegala alla root dell'organizzazione. Quindi crea una policy di tag simile all'esempio successivo, che definisce solo i valori accettabili per le chiavi di tag definite.

Fase successiva: definizione dei valori

Supponiamo di aver collegato la policy di tag precedente alla root dell'organizzazione. Quindi ora è possibile creare un policy di tag come la seguente e collegarla a un account. Questa policy definisce i valori accettabili per le chiavi di tag CostCenter e Project.

Policy B: policy di tag dell'account

{ "tags": { "CostCenter": { "tag_value": { "@@assign": [ "Production", "Test" ] } }, "Project": { "tag_value": { "@@assign": [ "A", "B" ] } } } }

Se colleghi la policy A alla root dell'organizzazione e la policy B a un account, le policy vengono combinate per creare la seguente policy di tag operativa per l'account:

Policy A+ Policy B = policy di tag operativa per l'account

{ "tags": { "Project": { "tag_value": [ "A", "B" ], "tag_key": "Project" }, "CostCenter": { "tag_value": [ "Production", "Test" ], "tag_key": "CostCenter" } } }

Per ulteriori informazioni sull'ereditarietà delle politiche, inclusi esempi di come funzionano gli operatori di ereditarietà ed esempi di politiche di tag efficaci, vedere. Comprendere l'ereditarietà delle politiche dichiarative

Esempio 2: impedire l'utilizzo di una chiave di tag

Per impedire l'utilizzo di una chiave di tag, è possibile collegare una policy di tag come la seguente a un'entità dell'organizzazione.

Questa policy di esempio specifica che nessun valore è accettabile per la chiave di tag Color. Specifica inoltre che nessun operatore è consentito nelle policy di tag figlio. Pertanto, eventuali tag Color sulle risorse negli account interessati sono considerati non conformi. Tuttavia, l'opzione enforced_for impedisce effettivamente agli account interessati di aggiungere un tag solo per le tabelle Amazon DynamoDB con il tag Color.

{ "tags": { "Color": { "tag_key": { "@@operators_allowed_for_child_policies": [ "@@none" ], "@@assign": "Color" }, "tag_value": { "@@operators_allowed_for_child_policies": [ "@@none" ], "@@assign": [] }, "enforced_for": { "@@assign": [ "dynamodb:table" ] } } } }

Esempio 3: Specificare una politica di tag per tutti i tipi di risorse supportati di uno specifico AWS service

Per specificare una politica di tag per tutti i tipi di risorse supportati di un AWS servizio specifico, si utilizza il carattere ALL_SUPPORTED jolly.

Questa policy utilizza il carattere ALL_SUPPORTED jolly per specificare che tutte le istanze Amazon EC2 con la Environment chiave tag possono avere solo un valore di tag pari o. Prod Non-prod Questa jolly offre un'alternativa efficace a riga singola per elencare ogni istanza Amazon EC2 singolarmente. Per un elenco di servizi e tipi di risorse che supportano la ALL_SUPPORTED wildcard, consulta. Servizi e tipi di risorse che supportano l'applicazione

{ "tags": { "Environment": { "tag_key": { "@@assign": "Environment", "@@operators_allowed_for_child_policies": ["@@none"] }, "tag_value": { "@@assign": [ "Prod", "Non-prod" ], "@@operators_allowed_for_child_policies": ["@@none"] }, "enforced_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] } } } }

Esempio 4: Applica le chiavi dei tag richieste per garantire la conformità

Questo esempio dimostra come definire una politica di tag che richieda che tutte le risorse includano tag di conformità obbligatori. Le organizzazioni utilizzano comunemente questo modello per garantire una corretta allocazione dei costi, il monitoraggio della proprietà e l'identificazione dell'ambiente.

{ "tags": { "CostCenter": { "report_required_tag_for": { "@@assign": [ "ec2:instance", "s3:bucket", "rds:db", "lambda:function" ] }, "tag_key": { "@@assign": "CostCenter" } }, "Environment": { "report_required_tag_for": { "@@assign": [ "ec2:ALL_SUPPORTED", "rds:ALL_SUPPORTED", "s3:ALL_SUPPORTED" ] }, "tag_key": { "@@assign": "Environment" }, "tag_value": { "@@assign": [ "Production", "Staging", "Development", "Test" ] } }, "Owner": { "report_required_tag_for": { "@@assign": [ "ec2:ALL_SUPPORTED" ] }, "tag_key": { "@@assign": "Owner" } } } }

Quando applichi questa policy e configuri il tuo strumento IaC con Tag Policy Enforcement:

  • CostCenter: richiesto per istanze EC2, bucket S3, database RDS e funzioni Lambda

  • Ambiente: richiesto per tutte le risorse EC2, RDS e S3, con valori consentiti limitati a Produzione, Staging, Sviluppo o Test

  • Proprietario: richiesto per tutte le risorse EC2 dell'organizzazione

Esempio di codice di infrastruttura conforme a questa politica:

EC2Instance: Type: AWS::EC2::Instance Properties: ImageId: ami-0c02fb55956c7d316 InstanceType: t2.micro Tags: - Key: CostCenter Value: CC-12345 - Key: Environment Value: Test - Key: Owner Value: john.doe@company.com

Se si tenta di creare una risorsa senza i tag richiesti, l'implementazione di IaC fallirà o genererà un avviso durante la fase di pianificazione, a seconda della configurazione. Se configurata in modalità di errore, la distribuzione viene bloccata prima della creazione di qualsiasi risorsa. Se configurata in modalità di avviso, la distribuzione procede ma avvisa il team dei tag mancanti. Il messaggio di errore di convalida identifica esattamente quali tag obbligatori mancano e quali risorse li richiedono.

Per istruzioni di configurazione specifiche per il tuo strumento IAc: