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:
+ **Read-only azioni**: operazioni che leggono solo le informazioni dai servizi e dagli AWS account connessi. Sono disponibili per impostazione predefinita.
+ **Azioni dirette**: operazioni che creano, modificano o alterano in altro modo le risorse. Le azioni dirette sono elevate: sono disabilitate per impostazione predefinita e richiedono un opt-in esplicito e a più livelli e l'approvazione dell'operatore per azione.
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](#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.
1. **L'agente propone la modifica. ** L'agente ispeziona il gruppo di sicurezza (un'azione di sola lettura). Propone di rimuovere la `0.0.0.0/0` regola e di aggiungere una regola con ambito all'intervallo della rete interna. La proposta identifica l'esatto funzionamento dell'API, il gruppo di sicurezza target, una valutazione del rischio, il raggio di esplosione previsto e le fasi di ripristino.
1. **L'operatore esamina e approva. ** L'operazione modifica una risorsa, quindi è un'azione diretta. La richiesta di approvazione mostra l'operazione e i relativi parametri. L'operatore può modificare i parametri, ad esempio restringere `10.0.0.0/8` o rifiutare la richiesta. `10.1.0.0/16` Nulla viene eseguito senza un'approvazione esplicita.
1. **L'agente esegue con credenziali con ambito. ** L'agente utilizza le credenziali del ruolo elevato registrato. Le credenziali sono limitate all'operazione e alla risorsa approvate e valide per una finestra limitata. L'approvazione non può essere riutilizzata per un'operazione o risorsa diversa.
1. **L'azione è completamente verificabile. ** La chiamata viene visualizzata AWS CloudTrail con un'identità di origine che la attribuisce all'operatore di approvazione. CloudTrail registra i parametri approvati ed eseguiti.
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:
+ Uno spazio AWS DevOps agente in Agent con almeno un'associazione a un AWS account o un'integrazione di terze parti supportata.
+ Autorizzazioni per aggiornare lo spazio dell'agente e le relative associazioni, ad esempio tramite la console o l'API AWS DevOps dell'agente.
+ Autorizzazioni nell'account di destinazione per creare un ruolo IAM e definirne le politiche di attendibilità e autorizzazione, per azioni dirette contro gli AWS account.
+ `iam:PassRole`autorizzazione all'accesso `arn:aws:iam:::role/*` nel proprio account, con la chiave condizionale `iam:PassedToService` impostata su`aidevops.amazonaws.com`, per registrare il ruolo nell'associazione. Una `iam:PassRole` sovvenzione più ampia soddisfa anche questo requisito.
+ Accesso allo spazio degli agenti per gli operatori che approveranno le azioni dirette.
## 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
1. Aprire la console AWS DevOps dell'agente.
1. Scegli il tuo spazio agente.
1. Accedi alle impostazioni dello spazio agente e abilita le azioni dirette.
1. Conferma la modifica.
### Abilitazione tramite l'API
È possibile abilitare le azioni dirette tramite lo spazio degli agenti`preferences`. 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 \
--preferences elevatedActionsEnabled=true
```
Il `preferences` campo presenta i seguenti comportamenti:
+ L'immissione di `preferences` on `UpdateAgentSpace` sostituisce il set completo, pertanto le preferenze omesse vengono ripristinate ai valori predefiniti.
+ L'omissione del campo lascia invariati i valori correnti. `preferences`
+ L'impostazione `elevatedActionsEnabled` è facoltativa, poiché la preferenza predefinita è. `false`
+ L'immissione di una chiave di preferenza sconosciuta ha esito negativo. `ValidationException`
+ La modifica di una preferenza ha effetto immediato ed è equivalente all'interruttore della console.
+ La chiamata `GetAgentSpace` restituisce la `preferences` mappa corrente, che conferma l'impostazione.
## 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:
+ La registrazione è facoltativa per account. Se non registri un ruolo elevato per un account, per quell'account sono disponibili solo le azioni di sola lettura.
+ Consigliamo una convenzione di denominazione riconoscibile, in `DevOpsAgent-ElevatedAction-*` modo che i ruoli con privilegi elevati siano facili da controllare. Il servizio non richiede un nome specifico.
+ La politica di autorizzazione del ruolo è gestita dal cliente. Applicala alle azioni che vuoi che l'agente sia in grado di intraprendere. Il ruolo definisce il * limite massimo * di ciò che l'agente può fare nel tuo account. Non è una sovvenzione permanente. Ogni azione diretta richiede inoltre l'approvazione dell'operatore al momento dell'esecuzione e la sessione dell'agente è ulteriormente limitata alla specifica operazione approvata.
### 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`, e`sts:TagSession`. Se si omette `sts:SetSourceIdentity` o`sts: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:
+ Concede autorizzazioni ampie: tutte le azioni, su tutte le risorse. Sono esclusi i servizi di gestione delle identità, delle credenziali e dell'organizzazione. I servizi esclusi sono`account:*`,`cognito-identity:*`,`iam:*`,`identitystore:*`,`organizations:*`,, `ram:*` `rolesanywhere:*``sso:*`, e. `sts:*` Di conseguenza, il ruolo non può gestire le identità o ottenere ulteriori accessi.
+ Consente una piccola serie di azioni di sola lettura a partire da tali servizi:`account:GetAccountInformation`,,`account:GetGovCloudAccountInformation`,`account:GetPrimaryEmail`,, `account:ListRegions` `iam:ListRoles``organizations:DescribeEffectivePolicy`, `organizations:DescribeOrganization` e. `sts:DecodeAuthorizationMessage`
+ Include le azioni di eliminazione delle classi nel limite massimo. L'agente stesso rifiuta le operazioni di eliminazione della classe indipendentemente dalle autorizzazioni del ruolo. Per ulteriori informazioni sulle operazioni rifiutate dall'agente, consulta [ Operazioni che l'agente non eseguirà. ](#operations-the-agent-will-not-perform)
+ La politica definisce solo il massimale. Le autorizzazioni effettive per ogni singola azione vengono limitate in fase di esecuzione all'operazione approvata.
**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](aws-devops-agent-security-limiting-agent-access-in-an-aws-account.md)
### Ciclo di vita della convalida
Il modo in cui viene eseguita la convalida delle politiche di fiducia dipende dal tipo di account.
+ **Account di monitoraggio (principale). ** La convalida è sincrona. AWS DevOps L'agente convalida il ruolo quando lo si salva. Il risultato è disponibile quando la pagina viene ricaricata o viene restituita la chiamata API. `agentElevatedRoleArnStatus`riflette `valid` o `invalid` immediatamente.
+ **Account di origine (secondari). ** La convalida è asincrona. Dopo aver registrato un ruolo elevato, si verifica quanto segue:
1. L'associazione accetta immediatamente la registrazione e segnala `agentElevatedRoleArnStatus` come`pending-confirmation`.
1. AWS DevOps L'agente convalida il ruolo esercitando il percorso di assunzione del ruolo.
1. Lo stato passa a `valid` se la convalida ha esito positivo o negativo. `invalid`
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. ](#categorizing-tools-for-third-party-integrations) Queste barriere si applicano anche quando la politica del ruolo elevato ne consente l'operazione. L'approvazione dell'operatore non li sostituisce.
+ **Eliminare le risorse. ** L'agente rifiuta le operazioni di eliminazione della classe, ad esempio l'eliminazione di un'istanza, un bucket, una tabella, una funzione o uno stack. L'operatore elimina le risorse autonomamente con le proprie credenziali.
+ **Modifica i limiti delle autorizzazioni. ** L'agente rifiuta le operazioni che impostano o rimuovono i limiti delle autorizzazioni IAM:`iam:PutRolePermissionsBoundary`, `iam:DeleteRolePermissionsBoundary``iam:PutUserPermissionsBoundary`, e. `iam:DeleteUserPermissionsBoundary` I limiti sono un controllo che l'organizzazione utilizza per vincolare l'agente, quindi l'agente non può modificarli.
+ **Richiedere`iam:PassRole`. ** Per impostazione predefinita, l'agente non supporta le operazioni che trasferiscono un ruolo IAM a un AWS servizio. Gli esempi includono l'avvio di un'istanza con un profilo di istanza o la creazione di una funzione Lambda con un ruolo di esecuzione. L'avvio di un'attività con un ruolo di attività è un altro esempio. Il passaggio di un ruolo può estendere indirettamente ciò che un servizio fa per tuo conto.
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.
| Classificazione | Significato | Comportamento |
| --- | --- | --- |
| READ\_ONLY | Lo strumento legge solo le informazioni. | Disponibile come azione di sola lettura. |
| MUTATIVE | Lo strumento può creare o modificare risorse. | Richiede l'attivazione delle azioni dirette e l'approvazione dell'operatore per azione in chat. |
| DESTRUCTIVE | Lo strumento può eliminare o modificare in modo irreversibile le risorse. | L'agente non richiama mai gli strumenti inclusi in questa classificazione. |
### 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`
+ Ciascuna `name` deve corrispondere esattamente a una voce nell'elenco degli strumenti abilitati dell'associazione. Una mancata corrispondenza viene rifiutata al momento della registrazione.
+ Per impostazione predefinita, gli strumenti senza una classificazione memorizzata sono. `READ_ONLY` Se si registra o si aggiorna un'associazione di server MCP a livello di programmazione, tramite un AWS SDK, la AWS CLI o una chiamata API diretta, e non la si fornisce`toolDetails`, AWS DevOps Agent considera tutti gli strumenti di tale associazione come tali. `READ_ONLY` L'agente esegue strumenti di sola lettura senza richiedere l'approvazione. Per richiedere l'approvazione dell'operatore prima che venga eseguito uno strumento che crea o modifica risorse, classifica tale strumento in modo esplicito come. `MUTATIVE` La console richiede di classificare ogni strumento scoperto. I chiamanti programmatici devono impostarsi da soli. `toolDetails`
+ I nomi degli strumenti sono composti da 1 a 128 caratteri. È possibile classificare fino a 500 strumenti per associazione.
Per ulteriori informazioni sulla connessione e sull'autorizzazione all'elenco degli strumenti MCP, vedere. [Connessione dei server MCP](configuring-integrations-and-knowledge-connecting-mcp-servers.md)
### 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.
+ `MUTATIVE`Possono essere abilitati solo gli strumenti classificati da AWS DevOps Agent.
+ Gli strumenti classificati come `DESTRUCTIVE` (ad esempio`grafana_delete_alert_rule`) non possono mai essere abilitati.
## 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:
1. L'agente richiede l'approvazione, presentando all'operatore lo strumento, l'operazione e la risorsa di destinazione specifici.
1. L'operatore esamina la richiesta e la approva o la rifiuta.
1. Se approvato, l'agente esegue l'operazione. Ogni approvazione riguarda solo lo strumento, l'operazione e la risorsa specifici richiesti. Rimane valida per una finestra temporale limitata e non può essere riutilizzata per un'operazione o risorsa diversa.
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
+ `SendMessage`trasmette una richiesta di approvazione. La richiesta identifica lo strumento, l'operazione e la risorsa di destinazione, con identificatori di interruzione per la ripresa. Ad esempio, supponiamo che un operatore lavori in un assistente AI come Claude. L'operatore gli chiede di eliminare la coda delle lettere morte. `arn:aws:sqs:us-east-1:111122223333:my-app-dlq` Claude chiama `SendMessage` l' AWS DevOps agente e il flusso di risposta contiene una richiesta di approvazione che identifica lo strumento`use_aws`, l'operazione e l'ARN della coda`sqs:PurgeQueue`, insieme a e identificatori. `toolUseId` `interruptId` `approvalId`
+ L'operatore registra la decisione con. `UpdateApprovalAction` L'operatore approva con un ambito definito o rifiuta con un motivo opzionale. Qui Claude presenta la richiesta all'operatore, quindi chiama `UpdateApprovalAction` con `action: APPROVED` e a `finalPattern` of tool`use_aws`, aggiungendo e `argumentPins` inserendo l'ARN della `operation` coda`sqs:PurgeQueue`. `resource_arn`
+ L'ambito definito può restringere la richiesta, ma non può mai ampliarla.
+ L'operatore contrassegna un'approvazione come monouso o imposta una finestra di riutilizzo fino a 4 ore. L'eliminazione della coda è un'operazione una tantum, pertanto l'operatore contrassegna questa approvazione come monouso (no). `singleUse: true` `ttlSeconds`
+ Il cliente riprende la conversazione in pausa richiamando nuovamente con la decisione allegata. `SendMessage` In questo esempio, Claude imposta `userActionResponse` `APPROVAL_ACTION` e fornisce `approvalAction` la`toolUseId`, `interruptId``approvalId`, e la decisione. `APPROVED` AWS DevOps L'agente quindi elimina la coda.
+ Il ciclo di vita dell'approvazione è quindi `APPROVED` (`PENDING`riscattabile) o (terminale). `REJECTED` `APPROVED`L'approvazione diventa una `REDEEMED` volta consumata e può avvenire prima dell'uso. `REVOKED` Qui la richiesta avviene `PENDING` mentre l'operatore decide, `APPROVED` dopo la decisione e `REDEEMED` dopo che l'agente ha eliminato la coda.
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: chiama`SendMessage`, trasmetti la richiesta di approvazione a un operatore, registra la decisione con e riprendi la conversazione con`UpdateApprovalAction`. `SendMessage`
## Monitoraggio e revisione
+ **Stato di convalida dei ruoli**: monitora `agentElevatedRoleArnStatus` AWS le tue associazioni (tramite `GetAssociation` o`ListAssociations`) per confermare che i ruoli elevati rimangano nello stato. `valid`
+ **AWS CloudTrail**— Le azioni dirette eseguite nei tuoi AWS account vengono visualizzate in. CloudTrail La sessione con ruolo presunto ha un'identità di origine che attribuisce l'azione all'operatore che approva. È possibile far risalire ogni azione diretta all'umano che l'ha approvata.
## Risoluzione dei problemi
**Un ruolo registrato rimane attivo`pending-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:
+ La policy di fiducia nomina l' AWS DevOps agente principale del servizio.
+ La politica di fiducia consente tutte le azioni STS richieste (`sts:AssumeRole``sts:SetSourceIdentity`,, e`sts:TagSession`), non solo`sts:AssumeRole`.
+ La `aws:SourceAccount` condizione corrisponde all'account proprietario dello spazio agente.
+ La regione nella `aws:SourceArn` condizione corrisponde alla regione dello spazio agente (o utilizza una jolly regionale).
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.
**`ValidationException`quando 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 fornitura`toolDetails`. ** 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.