Implementazione e applicazione dei tag

In questa sezione, presenteremo gli strumenti disponibili per le seguenti strategie di gestione delle risorse: manuale, infrastructure-as code (IaC) e integrazione continua/distribuzione continua (CI/CD). La dimensione chiave di questi approcci è un tasso di implementazione sempre più frequente.

Risorse gestite manualmente

Si tratta in genere di carichi di lavoro che rientrano nelle fasi fondamentali o di migrazione dell'adozione. Spesso si tratta di semplici carichi di lavoro in gran parte statici creati utilizzando procedure scritte tradizionali o di carichi di lavoro migrati così come sono utilizzando strumenti come quelli CloudEndure provenienti da un ambiente locale. Gli strumenti di migrazione, come Migration Hub e CloudEndure, possono applicare tag come parte del processo di migrazione. Tuttavia, se i tag non sono stati applicati durante la migrazione originale o lo schema di etichettatura è cambiato da allora, il Tag Editor (una funzionalità di AWS Management Console) consente di cercare risorse utilizzando una varietà di criteri di ricerca e di aggiungere, modificare o eliminare tag in blocco. I criteri di ricerca possono includere risorse con o senza la presenza di un particolare tag o valore. L'API AWS Resource Tagging consente di eseguire queste funzioni a livello di codice.

Man mano che questi carichi di lavoro vengono modernizzati, vengono introdotti tipi di risorse come i gruppi di Auto Scaling. Questi tipi di risorse consentono una maggiore elasticità e una migliore resilienza. Il gruppo auto scaling gestisce le istanze Amazon EC2 per tuo conto, tuttavia potresti comunque desiderare che le istanze EC2 vengano etichettate in modo coerente con le risorse create manualmente. Un modello di lancio di Amazon EC2 fornisce i mezzi per specificare i tag che Auto Scaling deve applicare alle istanze che crea.

Quando le risorse di un carico di lavoro vengono gestite manualmente, può essere utile automatizzare l'etichettatura delle risorse. Sono disponibili varie soluzioni. Un approccio è quello di utilizzare Regole di AWS Config, che può verificare required_tags e quindi avviare una funzione Lambda per applicarli. Regole di AWS Config è descritto più dettagliatamente più avanti in questo white paper.

risorse gestite dall'infrastruttura come codice (IaC)

AWS CloudFormation fornisce un linguaggio comune per il provisioning di tutte le risorse dell'infrastruttura AWS nell'ambiente. CloudFormation i modelli sono file JSON o YAML che creano AWS risorse in modo automatizzato. Quando si creano AWS risorse utilizzando CloudFormation modelli, è possibile utilizzare la proprietà CloudFormation Resource Tags per applicare tag ai tipi di risorse supportati al momento della creazione. La gestione dei tag e delle risorse con IAc aiuta a garantire la coerenza.

Quando le risorse vengono create da AWS CloudFormation, il servizio applica automaticamente un set di tag AWS definiti alle risorse create dal AWS CloudFormation modello. Questi sono:

aws:cloudformation:stack-name
aws:cloudformation:stack-id
aws:cloudformation:logical-id

È possibile definire facilmente un gruppo di risorse in base allo AWS CloudFormation stack. Questi tag AWS definiti vengono ereditati dalle risorse create dallo stack. Tuttavia, per le istanze Amazon EC2 all'interno di un gruppo Auto Scaling, è AWS::AutoScaling::AutoScalingGroup TagPropertynecessario impostarlo nella definizione del gruppo Auto Scaling nel modello. AWS CloudFormation In alternativa, se utilizzi un modello di avvio EC2 con il gruppo Auto Scaling, puoi definire i tag nella sua definizione. Si consiglia di utilizzare i modelli di avvio EC2 con gruppi di Auto Scaling o con AWS un servizio container. Questi servizi possono contribuire a garantire l'etichettatura coerente delle istanze Amazon EC2 e supportano anche l'Auto Scaling su più tipi di istanze e opzioni di acquisto, che possono migliorare la resilienza e ottimizzare i costi di elaborazione.

AWS CloudFormation Gli hook forniscono agli sviluppatori un mezzo per mantenere gli aspetti chiave delle loro applicazioni coerenti con gli standard della loro organizzazione. Gli hook possono essere configurati per fornire un avviso o impedire l'implementazione. Questa funzionalità è ideale per verificare gli elementi chiave di configurazione nei modelli, ad esempio se un gruppo di Auto Scaling è configurato per applicare tag definiti dal cliente a tutte le istanze Amazon EC2 che lancerà o per garantire che tutti i bucket Amazon S3 siano creati con le impostazioni di crittografia richieste. In entrambi i casi, la valutazione di questa conformità viene spostata alle fasi iniziali del processo di distribuzione, con accorgimenti preliminari alla distribuzione. AWS CloudFormation

AWS CloudFormation fornisce la capacità di rilevare quando una risorsa (vedere Risorse che supportano il rilevamento delle deviazioni) fornita da un modello è stata modificata e le risorse non corrispondono più alle configurazioni del modello previste. Questo fenomeno è noto come deriva. Se usi l'automazione per applicare tag alle risorse gestite tramite IAc, le stai modificando, introducendo drift. Quando si utilizza IaC, attualmente si consiglia di gestire eventuali requisiti di tagging come parte dei modelli IaC, implementare AWS CloudFormation hook e pubblicare set di regole AWS CloudFormation Guard che possono essere utilizzati dall'automazione.

Risorse gestite dalla pipeline CI/CD

Con l'aumentare della maturità del carico di lavoro, è probabile che vengano adottate tecniche come l'integrazione continua e l'implementazione continua (CI/CD). Queste tecniche aiutano a ridurre il rischio di implementazione semplificando l'implementazione di piccole modifiche più frequentemente con una maggiore automazione dei test. Una strategia di osservabilità che rileva comportamenti imprevisti introdotti da una distribuzione può ripristinare automaticamente l'implementazione con un impatto minimo sull'utente. Quando si arriva alla fase di implementazione decine di volte al giorno, l'applicazione retroattiva dei tag semplicemente non è più pratica. Tutto deve essere espresso sotto forma di codice o configurazione, deve essere controllato dalla versione e, ove possibile, testato e valutato prima dell'implementazione in produzione. Nel modello combinato di sviluppo e operazioni (DevOps), molte pratiche riguardano considerazioni operative sotto forma di codice e le convalidano nelle prime fasi del ciclo di vita dell'implementazione.

Idealmente, dovresti eseguire questi controlli il più presto possibile (come illustrato con gli AWS CloudFormation hook), in modo da avere la certezza che il AWS CloudFormation modello soddisfi le tue politiche prima che lascino il computer dello sviluppatore.

AWS CloudFormation Guard 2.0 offre i mezzi per scrivere regole di conformità preventive per tutto ciò che è possibile definire. CloudFormation Il modello è convalidato in base alle regole dell'ambiente di sviluppo. Chiaramente, questa funzionalità ha una vasta gamma di applicazioni, ma in questo white paper esamineremo solo alcuni esempi per garantire che venga sempre utilizzata AWS::AutoScaling::AutoScalingGroup TagProperty.

Di seguito è riportato un esempio di regola CloudFormation Guard:

let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ]

rule tags_asg_automation_EnvironmentId when %all_asgs !empty {
    let required_tags = %all_asgs.Properties.Tags.*[ 
        Key == 'example-inc:automation:EnvironmentId' ] 
    %required_tags[*] {
        PropagateAtLaunch == 'true'
        Value IN ['Prod', 'Dev', 'Test', 'Sandbox']
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

rule tags_asg_costAllocation_CostCenter when %all_asgs !empty {
    let required_tags = %all_asgs.Properties.Tags.*[ 
        Key == 'example-inc:cost-allocation:CostCenter' ]
    %required_tags[*] {
        PropagateAtLaunch == 'true'
        Value == /^123-/
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

Nell'esempio di codice, filtriamo il modello per tutte le risorse del tipo AutoScalingGroup e quindi abbiamo due regole:

• tags_asg_automation_EnvironmentId- Verifica che un tag con questa chiave esista, che abbia un valore all'interno dell'elenco di valori consentito e che PropagateAtLaunch sia impostato su true

• tags_asg_costAllocation_CostCenter- Verifica che esista un tag con questa chiave, che abbia un valore che inizia con il valore del prefisso definito e che PropagateAtLaunch sia impostato su true

Applicazione

Come descritto in precedenza, Resource Groups & Tag Editor fornisce i mezzi per identificare dove le risorse non soddisfano i requisiti di tagging definiti nelle politiche di tag applicate alle unità organizzative dell'organizzazione. L'accesso allo strumento console Resource Groups & Tag Editor dall'interno di un account membro dell'organizzazione mostra le politiche che si applicano a quell'account e la risorsa all'interno dell'account che non soddisfa i requisiti della politica sui tag. Se si accede dall'account di gestione (e se Tag policies ha Access abilitato nei servizi sotto AWS Organizations), è possibile visualizzare la conformità alle politiche sui tag per tutti gli account collegati dell'organizzazione.

All'interno della stessa Tag Policy, puoi abilitare l'applicazione per tipi di risorse specifici. Nel seguente esempio di policy, abbiamo aggiunto l'applicazione in modo tale che tutte le risorse, di qualsiasi tipoec2:instance, ec2:volume debbano essere conformi alla policy. Esistono alcune limitazioni note, ad esempio la presenza di un tag su una risorsa affinché possa essere valutata dalla politica dei tag. Per un elenco, consulta Risorse che supportano l'applicazione delle politiche sui tag.

ExampleInc-Allocazione dei costi. json

Di seguito è riportato un esempio di politica dei tag che riporta e/o applica i tag di allocazione dei costi:

{
  "tags": {
    "example-inc:cost-allocation:ApplicationId": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:ApplicationId"
      },
      "tag_value": {
        "@@assign": [
          "DataLakeX",
          "RetailSiteX"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    },
    "example-inc:cost-allocation:BusinessUnitId": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:BusinessUnitId"
      },
      "tag_value": {
        "@@assign": [
          "Architecture",
          "DevOps",
          "FinanceDataLakeX"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    },
    "example-inc:cost-allocation:CostCenter": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:CostCenter"
      },
      "tag_value": {
        "@@assign": [
          "123-*"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    }
  }
}

AWS Config (required_tag)

AWS Config è un servizio che consente di valutare, controllare e valutare le configurazioni delle AWS risorse (vedi Tipi di risorse supportati da). AWS Config Nel caso del tagging, possiamo usarlo per identificare le risorse prive di tag con chiavi specifiche, utilizzando la required_tags regola (fai riferimento ai tipi di risorse supportati da required_tags). Dall'esempio precedente, potremmo verificare l'esistenza della chiave su tutte le istanze Amazon EC2. Nei casi in cui la chiave non esiste, l'istanza verrà registrata come non conforme. Questo AWS CloudFormation modello descrive una AWS Config regola per verificare la presenza delle chiavi obbligatorie descritte nella tabella, su bucket Amazon S3, istanze Amazon EC2 e volumi Amazon EBS.

 Resources:
  MandatoryTags:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: ExampleIncMandatoryTags
      Description: These tags should be in place
      InputParameters:
        tag1Key: example-inc:cost-allocation:ApplicationId
        tag2Key: example-inc:cost-allocation:BusinessUnitId
        tag3Key: example-inc:cost-allocation:CostCenter
        tag4Key: example-inc:automation:EnvironmentId
      Scope:
        ComplianceResourceTypes:
        - "AWS::S3::Bucket"
        - "AWS::EC2::Instance"
        - "AWS::EC2::Volume"
      Source:
        Owner: AWS
SourceIdentifier: REQUIRED_TAGS

Per gli ambienti in cui le risorse vengono gestite manualmente, è possibile migliorare una AWS Config regola per aggiungere automaticamente la chiave del tag mancante alle risorse utilizzando una correzione automatica tramite una funzione. AWS Lambda Sebbene funzioni bene per i carichi di lavoro statici, è progressivamente meno efficace man mano che si inizia a gestire le risorse tramite IaC e pipeline di implementazione.

AWS Organizations — Le politiche di controllo dei servizi (SCP) sono un tipo di politica organizzativa che è possibile utilizzare per gestire le autorizzazioni all'interno dell'organizzazione. Gli SCP offrono il controllo centralizzato sulle autorizzazioni massime disponibili per tutti gli account dell'organizzazione o dell'unità organizzativa (OU). Gli SCP riguardano solo gli utenti e i ruoli gestiti da account che fanno parte dell'organizzazione. Sebbene non influiscano direttamente sulle risorse, limitano le autorizzazioni degli utenti e dei ruoli, incluse le autorizzazioni per l'etichettatura delle azioni. Per quanto riguarda l'etichettatura, gli SCP possono fornire una granularità aggiuntiva per l'applicazione dei tag oltre a quella fornita dalle politiche sui tag.

Nell'esempio seguente, la policy negherà le ec2:RunInstances richieste in cui il example-inc:cost-allocation:CostCenter tag non è presente.

Quanto segue è un SCP di negazione:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstanceWithNoCostCenterTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:instance/"
      ],
      "Condition": {
        "Null": {
          "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true"
        }
      }
    }
  ]
}

Non è possibile recuperare fin dalla progettazione l'effettiva politica di controllo del servizio che si applica a un account collegato. Laddove si imponga l'utilizzo di tag con SCP, è necessario che la documentazione sia disponibile per gli sviluppatori in modo che possano garantire che le loro risorse soddisfino le politiche applicate ai loro account. Fornire accesso in sola lettura agli CloudTrail eventi all'interno del proprio account può aiutare gli sviluppatori a eseguire il debug quando le loro risorse non sono conformi.