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

Lavorare con azioni dirette

AWS DevOps L'agente può agire sui servizi e sugli AWS account connessi quando un operatore lo richiede esplicitamente. Ad esempio, un operatore che indaga su un incidente può chiedere all'agente di descrivere lo stato di una risorsa. Con le autorizzazioni e le approvazioni appropriate, l'operatore può anche chiedere all'agente di risolvere direttamente un problema.

L'agente distingue due tipi di operazioni:

Il modello di sicurezza per le azioni dirette è la difesa approfondita. La funzionalità è disabilitata per impostazione predefinita. L'attivazione avviene tramite livelli indipendenti: abilitando azioni dirette nello spazio degli agenti, registrando un ruolo IAM per account e classificando ogni strumento. Ogni azione diretta richiede l'approvazione dell'operatore al momento dell'esecuzione. Ogni approvazione e azione risultante è attribuibile all'operatore che approva in. AWS CloudTrail

Per le azioni contro AWS le risorse, l'agente applica i propri guardrail sulle operazioni AWS SDK che richiama, indipendentemente dalle autorizzazioni concesse. Per ulteriori informazioni su questi guardrail, consulta Operazioni che l'agente non eseguirà. #operations-the-agent-will-not-perform

Esempio: esecuzione di un piano di mitigazione sulla base di un'indagine

Questo esempio mostra l'esperienza end-to-end per uno scenario comune. Un operatore esamina il piano di mitigazione di un'indagine o una raccomandazione di miglioramento. L'operatore chiede all'agente di eseguirlo senza interrompere la conversazione.

Un tecnico dell'affidabilità del sito (SRE) chiede all'agente in chat di cercare eventuali account che consentano l'accesso tramite SSH. 0.0.0.0/0 L'agente trova un gruppo di sicurezza con una regola di accesso aperta. Raccomanda una soluzione: limita la regola all'intervallo della rete interna. L'operatore dice all'agente di applicarla.

Lo stesso flusso si applica quando si ispeziona qualsiasi piano di indagine, mitigazione o raccomandazione di miglioramento e si chiede all'agente di eseguire una fase. L'agente trasforma la fase in un'operazione proposta specifica e richiede l'approvazione prima di agire.

Lo stesso flusso si applica agli strumenti di terze parti. Un operatore che valuta il rumore di allerta chiede all'agente di aumentare la soglia in base a una regola di allerta Grafana. AWS DevOps L'agente classifica questo strumento come mutante e il team lo ha abilitato per un accesso elevato all'integrazione. L'agente presenta una richiesta di approvazione che mostra lo strumento e i parametri. Dopo l'approvazione, l'agente richiama lo strumento tramite l'integrazione. AWS DevOps L'agente attribuisce l'azione all'operatore che approva.

Prima che le azioni dirette siano abilitate o senza un ruolo elevato registrato, l'agente indaga comunque con azioni di sola lettura. Fornisce passaggi di riparazione manuali anziché una modifica eseguibile.

Prerequisiti

Prima di poter utilizzare le azioni dirette, è necessario quanto segue:

Abilitazione delle azioni dirette sullo spazio di un agente

Le azioni dirette devono essere abilitate nello spazio dell'agente prima che qualsiasi altra configurazione elevata abbia effetto. Questo è il controllo principale per le azioni dirette. Se è disabilitato, le registrazioni dei ruoli e gli opt-in elevati degli strumenti non hanno alcun effetto. I tentativi di registrazione di una configurazione elevata potrebbero essere rifiutati.

Abilitazione di nella console

Abilitazione tramite l'API

È possibile abilitare le azioni dirette tramite lo spazio degli agentipreferences. Questo campo è una mappa dattiloscritta delle chiavi di preferenza rispetto ai valori booleani. Lo hai impostato su e. CreateAgentSpace UpdateAgentSpace

L'esempio seguente abilita le azioni dirette con la AWS CLI.

aws devops-agent update-agent-space \
    --agent-space-id <your-agent-space-id> \
    --preferences elevatedActionsEnabled=true

Il preferences campo presenta i seguenti comportamenti:

Registrazione di un ruolo elevato per un AWS account

Per ogni AWS account associato, puoi facoltativamente registrare un ruolo elevato. L'account di monitoraggio e tutti gli account di origine supportano ciascuno una registrazione dei ruoli con privilegi elevati. Un ruolo elevato è un ruolo IAM nel tuo account che AWS DevOps l'agente assume per eseguire azioni dirette per tuo conto. Si registra il ruolo agentElevatedRoleArn impostando la configurazione dell' AWS associazione.

Quando registri un ruolo elevato, tieni presente quanto segue:

Redazione della politica di fiducia

Il ruolo elevato deve fidarsi del responsabile del servizio AWS DevOps Agent. La convalida esercita il percorso di assunzione del ruolo. AWS DevOps L'agente utilizza tre azioni STS quando assume il ruolo. La politica di fiducia deve consentire tutte e tre:sts:AssumeRole,sts:SetSourceIdentity, ests:TagSession. Se si omette sts:SetSourceIdentity osts:TagSession, le azioni dirette hanno esito negativo al momento della credenziale anche quando lo stato di convalida è. valid

L'esempio seguente mostra una politica di fiducia per un ruolo elevato. Sostituiscilo 111122223333 con l'ID del tuo AWS account e us-east-1 con la AWS regione del tuo spazio agente.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*"
        }
      }
    }
  ]
}

Le aws:SourceAccount aws:SourceArn condizioni generali proteggono dal confuso problema dei vice. Garantiscono che il ruolo possa essere assunto solo per conto dei vostri spazi per agenti. La regione nella aws:SourceArn condizione deve corrispondere alla regione del tuo spazio agente. Se gestisci spazi agenti in più regioni, utilizza una wildcard regionale (arn:aws:aidevops:*:111122223333:agentspace/*) o l'ARN specifico dello spazio agenti.

Concessione delle autorizzazioni al ruolo elevato

La politica di autorizzazione del ruolo elevato definisce il limite massimo di ciò che l' AWS DevOps agente può fare nel tuo account tramite azioni dirette. L'agente non opera mai a questo limite. Ogni azione diretta richiede l'approvazione dell'operatore. Le credenziali emesse per un'azione approvata comportano una politica di sessione. La politica di sessione li limita all'operazione e alle risorse specifiche approvate dall'operatore. L'agente compone la policy di sessione solo da un elenco accurato di azioni AWS IAM supportate che AWS DevOps l'agente gestisce. Un'azione al di fuori di tale elenco non può mai far parte di una policy di sessione. Per sfogliare l'elenco, aprire la pagina di configurazione nella console AWS DevOps dell'agente. Scegli Visualizza le azioni supportate nella sezione Azioni dell'agente. Sono disponibili due opzioni per la politica delle autorizzazioni.

Opzione 1: allegare la policy AWS gestita. AWS DevOps L'agente fornisce la policy AIDevOpsAgentActionsPolicy gestita. Il suo ARN è arn:aws:iam::aws:policy/AIDevOpsAgentActionsPolicy. Per il documento sulla policy in formato codice, consulta la AWS Managed Policy Reference Guide.

La policy gestita presenta le seguenti caratteristiche:

Opzione 2: scrivere una policy gestita dal cliente. Se desideri un massimale più stretto di quello fornito dalla politica gestita, scrivi la tua politica. Applicala esattamente alle azioni e alle risorse che vuoi che l'agente tocchi e assegnala al ruolo. Segui il principio del privilegio minimo: parti dalle operazioni che ti aspetti che gli operatori approvino ed espandi solo se necessario. Le azioni dirette che il ruolo non consente falliscono in fase di esecuzione anche se approvate.

Con entrambe le opzioni, è possibile limitare ulteriormente ciò che l'agente può fare utilizzando le politiche di controllo del servizio (SCP) e i limiti delle autorizzazioni. Questi controlli si applicano al ruolo elevato come qualsiasi altro ruolo nel tuo account. Per ulteriori informazioni sull'ambito dell'accesso dell'agente, consulta. Limitazione dell'accesso degli agenti in un AWS Account

Ciclo di vita della convalida

Il modo in cui viene eseguita la convalida delle politiche di fiducia dipende dal tipo di account.

Il ruolo viene utilizzato per le azioni dirette solo dopo il suo stato. valid

Per gli account di origine, esegui il polling dell'associazione con GetAssociation o ListAssociations e seleziona il agentElevatedRoleArnStatus campo. La convalida viene in genere completata entro pochi minuti.

Operazioni che l'agente non eseguirà

Indipendentemente dalle autorizzazioni concesse, l'agente applica i propri guardrail sulle operazioni AWS SDK che richiama come azioni dirette. Questi guardrail si applicano solo alle azioni contro le risorse. AWS La classificazione degli strumenti regola invece gli strumenti di terze parti. Per ulteriori informazioni sulla classificazione degli strumenti, consulta Categorizzazione degli strumenti per integrazioni di terze parti. Queste barriere si applicano anche quando la politica del ruolo elevato ne consente l'operazione. L'approvazione dell'operatore non li sostituisce.

Quando viene richiesto di eseguire una di queste operazioni, l'agente rifiuta e spiega perché. Dove possibile, descrive invece i passaggi manuali.

Questi guardrail completano i controlli che possiedi: la politica di autorizzazione del ruolo elevato, gli SCP e i limiti delle autorizzazioni sul ruolo elevato.

Strumenti di categorizzazione per integrazioni di terze parti

Third-party e le integrazioni MCP espongono gli strumenti in tre categorie che determinano se l'agente può richiamare lo strumento e quale approvazione è richiesta. AWS DevOps L'agente assegna classificazioni fisse per le integrazioni native. Li assegni per i server MCP configurati dal cliente.

Customer-configured Server MCP

Per le associazioni di server MCP (inclusa la variante SIGv4), classificate voi stessi gli strumenti attraverso toolDetails un elenco di voci per strumento. Ogni voce ha un e un. name toolClassification

Per ulteriori informazioni sulla connessione e sull'autorizzazione all'elenco degli strumenti MCP, vedere. Connessione dei server MCP

Integrazioni native (Datadog, Grafana)

Per le integrazioni native come Datadog e Grafana, le classificazioni vengono corrette da Agent. AWS DevOps Non fornisci classificazioni. Non è possibile sovrascrivere queste classificazioni. Scegliete invece strumenti di mutazione specifici tramite un elenco di enabledElevatedTools voci relative agli strumenti.

Approvazione di azioni dirette

Le azioni dirette sono umane. Quando l'agente determina che un'operazione che è stato incaricato di eseguire modifica una risorsa, non esegue l'operazione direttamente. Invece, accade quanto segue:

AWS DevOps L'agente presenta le richieste di approvazione degli operatori solo in chat. Se l'agente richiama uno strumento mutante all'esterno della chat, ad esempio durante un'indagine autonoma, la chiamata fallisce invece di presentare una richiesta di approvazione. AWS DevOps L'agente non esegue mai uno strumento mutante senza approvazione.

Le approvazioni e le azioni risultanti sono attribuibili all'operatore che approva in. AWS CloudTrail

Il flusso di approvazione nell'API

Qualsiasi agente consumer può gestire questo flusso allo stesso modo, che si tratti di un assistente AI come Claude, un bot Slack o un client operativo personalizzato: chiamaSendMessage, trasmetti la richiesta di approvazione a un operatore, registra la decisione con e riprendi la conversazione conUpdateApprovalAction. SendMessage

Monitoraggio e revisione

Risoluzione dei problemi

Un ruolo registrato rimane attivopending-confirmation. Questo vale per gli account di origine (secondari), in cui la convalida è asincrona. La convalida viene normalmente completata entro pochi minuti. Se lo stato non cambia, verifica che il ruolo esista e registra nuovamente l'ARN del ruolo per attivare nuovamente la convalida.

Lo stato del ruolo è. invalid La convalida della politica di fiducia non è riuscita. Verifica che:

Correggi la politica di fiducia e registra nuovamente il ruolo.

Le azioni dirette hanno esito negativo anche se lo stato del ruolo èvalid. Lo valid stato riflette il controllo di convalida al momento della registrazione. Se la politica di fiducia è stata modificata dopo la convalida o se la sua aws:SourceArn condizione è fissata a una regione diversa da quella dello spazio dell'agente, la chiamata live assume-role può comunque fallire. Rivedi la politica di fiducia confrontandola con l'elenco di controllo riportato sopra.

ValidationExceptionquando si registra un ruolo elevato. Le azioni dirette devono essere abilitate nello spazio dell'agente prima di poter registrare una configurazione elevata. Abilita prima le azioni dirette nello spazio dell'agente, quindi registra il ruolo.

Errori di mancata corrispondenza del nome dello strumento durante la fornituratoolDetails. Ogni nome toolDetails deve corrispondere esattamente al nome dello strumento nell'elenco degli strumenti abilitati dell'associazione, maiuscole e minuscole incluse. Confronta i due elenchi, correggi eventuali discrepanze e riprova.