Esempi di ereditarietà - AWS Organizations
Esempio 1: consente alle policy figlio di sovrascrivere solo i valori dei tagEsempio 2: aggiungere nuovi valori ai tag ereditatiEsempio 3: rimuovere i valori dai tag ereditatiEsempio 4: limitare le modifiche alle policy figlioEsempio 5: conflitti con gli operatori di controllo figlio Esempio 6: conflitti con l'aggiunta di valori allo stesso livello di gerarchia

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à.

Esempi di ereditarietà

Questi esempi mostrano come funziona l'ereditarietà della policy mostrando come le policy di tag padre e figlio vengono unite in una policy di tag operativa di un account.

Gli esempi presuppongono che la struttura dell'organizzazione sia quella mostrata nel diagramma seguente.

Un'organizzazione con un account principaleOUs, due e diversi account.

Esempio 1: consente alle policy figlio di sovrascrivere solo i valori dei tag

La seguente policy di tag definisce la chiave di tag CostCenter e due valori ammissibili, Development e Support. Se la si collega alla radice dell'organizzazione, la policy di tag è attiva per tutti gli account dell'organizzazione.

Policy A – Policy di tag del root dell'organizzazione

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Si supponga che si desideri che gli utenti utilizzino un valore di tag diverso per una chiave e che si desideri applicare la politica dei tag per tipi di risorse specifici. OU1 Poiché la policy A non specifica quali operatori di controllo figlio sono consentiti, tutti gli operatori sono consentiti. È possibile utilizzare l'@@assignoperatore e creare una politica di tag come la seguente a cui allegareOU1.

Politica B: politica dei OU1 tag

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Sandbox"
                ]
            },
            "enforced_for": {
                "@@assign": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

Specificando l'operatore @@assign per il tag, quando la policy A e la policy B si uniscono per formare la policy di tag operativa per un account:

  • La policy B sovrascrive i due valori di tag specificati nella policy padre, la policy A. Il risultato è che Sandbox è l'unico valore ammissibile per la chiave di tag CostCenter.

  • L'aggiunta di enforced_for specifica che il tag CostCenter deve essere il valore di tag specificato su tutte le risorse Amazon Redshift e le tabelle Amazon DynamoDB.

Come mostrato nel diagramma, OU1 include due account: 1111 e 222222222222.

Policy di tag operativa risultante per gli account 111111111111 e 222222222222.

Nota

Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione. 

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Sandbox"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Esempio 2: aggiungere nuovi valori ai tag ereditati

In alcuni casi si desidera che tutti gli account dell'organizzazione specifichino una chiave di tag con un breve elenco di valori accettabili. Per gli account di un'unità organizzativa, puoi consentire un valore aggiuntivo che solo tali account possono specificare durante la creazione di risorse. Questo esempio specifica come eseguire questa operazione utilizzando l'operatore @@append. L'operatore @@append è una caratteristica avanzata.

Come l'esempio 1, questo esempio inizia con la policy A per la policy del tag root dell'organizzazione.

Policy A – Policy di tag del root dell'organizzazione

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Per questo esempio, allega il criterio C a. OU2 La differenza in questo esempio consiste nel fatto che l'utilizzo dell'operatore @@append nella policy C aggiunge, anziché sovrascrivere, l'elenco dei valori accettabili e la regola enforced_for.

Policy C: politica di OU2 tag per l'aggiunta di valori

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@append": [
                    "Marketing"
                ]
            },
            "enforced_for": {
                "@@append": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

L'associazione della politica C a OU2 ha i seguenti effetti quando la politica A e la politica C si uniscono per formare la politica di tag efficace per un account:

  • Poiché la policy C include l'operatore @@append, consente di aggiungere, non sovrascrivere, l'elenco dei valori di tag accettabili specificati nella policy A.

  • Come nella policy B, l'aggiunta di enforced_for specifica che il tag CostCenter deve essere utilizzato come valore di tag specificato su tutte le risorse Amazon Redshift e le tabelle Amazon DynamoDB. La sovrascrittura (@@assign) e l'aggiunta (@@append) hanno lo stesso effetto se la policy padre non include un operatore di controllo figlio che limita ciò che una policy figlio può specificare.

Come mostrato nel diagramma, OU2 include un account: 9999. Le policy A e C si uniscono per creare la policy di tag operativa per l'account 999999999999.

Policy di tag operativa per l'account 999999999999

Nota

Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione. 

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Development",
                "Support",
                "Marketing"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Esempio 3: rimuovere i valori dai tag ereditati

In alcuni casi, la policy di tag collegata all'organizzazione definisce più valori di tag di quelli che si desidera vengano utilizzati da un account. In questo esempio viene illustrato come modificare una policy di tag utilizzando l'operatore @@remove. @@remove è una caratteristica avanzata.

Come gli altri esempi, anche questo esempio inizia con la policy A per la policy di tag root dell'organizzazione.

Policy A – Policy di tag del root dell'organizzazione

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

In questo esempio, collega la policy D all'account 999999999999.

Policy D – Policy di tag dell'account 999999999999 per la rimozione divalori

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@remove": [
                    "Development",
                    "Marketing"
                ],
                "enforced_for": {
                    "@@remove": [
                        "redshift:*",
                        "dynamodb:table"
                    ]
                }
            }
        }
    }
}

L'associazione della policy D all'account 999999999999 ha i seguenti effetti quando le policy A, C e D si uniscono per formare la policy di tag operativa:

  • Supponendo che siano stati eseguiti tutti gli esempi precedenti, i criteri B, C e C sono criteri secondari di A. I criteri B sono associati solo aOU1, quindi non ha alcun effetto sull'account 99999.

  • Per l'account 9999999999999, l'unico valore accettabile per la chiave di tag CostCenter è Support.

  • La conformità non viene applicata per la chiave di tag CostCenter.

Nuova policy di tag operativa per l'account 999999999999

Nota

Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione. 

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Support"
            ]
        }
    }
}

Se in seguito aggiungessi altri accountOU2, le loro politiche di tag efficaci sarebbero diverse da quelle per l'account 9999. Questo perché la policy D più restrittiva è collegata solo a livello di account e non all'unità organizzativa.

Esempio 4: limitare le modifiche alle policy figlio

Ci possono essere casi in cui vuoi limitare le modifiche nelle policy figlio. Questo esempio spiega come eseguire questa operazione utilizzando gli operatori di controllo figlio.

Questo esempio inizia con una nuova policy di tag root dell'organizzazione e presuppone che le policy di tag non siano ancora collegate alle entità dell'organizzazione.

Policy E - Policy di tag root dell'organizzazione per limitare le modifiche nelle policy figlio

{
    "tags": {
        "project": {
            "tag_key": {
                "@@operators_allowed_for_child_policies": ["@@none"],
                "@@assign": "Project"
            },
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance",
                    "Escalations"
                ]
            }
        }
    }
}

Quando associ la policy E alla root dell'organizzazione, questa impedisce alle policy figlio di modificare la chiave del tag Project. Tuttavia, le policy figlio possono sovrascrivere o aggiungere valori di tag.

Supponi quindi di associare la seguente policy F a un'unità organizzativa.

Policy F – Policy di tag dell'unità organizzativa

{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": [
                    "Escalations - research"
                ]
            }
        }
    }
}

L'unione della policy E e della policy F ha i seguenti effetti sugli account dell'unità organizzativa:

  • La policy F è una policy figlio per la policy E.

  • La policy F tenta di cambiare il trattamento lettere maiuscole o minuscole, ma non può. Questo perché la policy E include l'operatore "@@operators_allowed_for_child_policies": ["@@none"] per la chiave di tag.

  • Tuttavia, la policy F può aggiungere valori di tag per la chiave. Questo perché la policy E include "@@operators_allowed_for_child_policies": ["@@append"] per il valore del tag.

Policy operativa per gli account nell'unità organizzativa

Nota

Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione. 

{
    "tags": {
        "project": {
            "tag_key": "Project",
            "tag_value": [
                "Maintenance",
                "Escalations",
                "Escalations - research"
            ]
        }
    }
}

Esempio 5: conflitti con gli operatori di controllo figlio

Gli operatori di controllo figlio possono esistere nelle policy di tag collegate allo stesso livello nella gerarchia organizzativa. In questo caso, l'intersezione degli operatori consentiti viene utilizzata quando le policy si uniscono per formare la policy operativa per gli account.

Supponi che le policy G e H siano collegate alla root dell'organizzazione.

Policy G – Policy di tag del root dell'organizzazione 1

{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance"
                ]
            }
        }
    }
}

Policy H – Policy di tag del root dell'organizzazione 2

{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
            }
        }
    }
}

In questo esempio, una policy nella root dell'organizzazione definisce che i valori per la chiave di tag possono solo essere aggiunti. L'altra policy collegata alla root dell'organizzazione consente alle policy figlio di aggiungere e rimuovere valori. L'intersezione di queste due autorizzazioni viene utilizzata per le policy figlio. Il risultato è che le policy figlio possono aggiungere valori, ma non rimuovere valori. Pertanto, la policy figlio può aggiungere un valore all'elenco dei valori di tag, ma non può rimuovere il valore Maintenance.

Esempio 6: conflitti con l'aggiunta di valori allo stesso livello di gerarchia

Puoi collegare più policy di tag a ciascuna entità dell'organizzazione. Quando si esegue questa operazione, le policy di tag collegate alla stessa entità dell'organizzazione possono includere informazioni in conflitto. Le policy vengono valutate in base all'ordine in cui sono state associate all'entità dell'organizzazione. Per modificare l'ordine di valutazione delle policy, puoi scollegare e ricollegare una policy.

Supponi che la policy J sia collegata alla root dell'organizzazione e che poi la policy K venga collegata alla root dell'organizzazione.

Policy J – Prima policy di tag collegata al root dell'organizzazione

{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": ["Maintenance"]
            }
        }
    }
}

Policy K – Seconda policy di tag collegata al root dell'organizzazione

{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "project"
            }
        }
    }
}

In questo esempio, la chiave di tag PROJECT viene utilizzata nella policy di tag operativa perché la policy che l'ha definita è stata collegata per prima alla root dell'organizzazione.

Policy JK – Policy di tag effettiva per l'account

La policy operativa per l'account è la seguente.

Nota

Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione. 

{
    "tags": {
        "project": {
            "tag_key": "PROJECT",
            "tag_value": [
                "Maintenance"
            ]
        }
    }
}