Come posso risolvere l'errore della policy di attendibilità di IAM "Impossibile aggiornare la policy di attendibilità. Invalid principal in policy"?
Ricevo l'errore "Impossibile aggiornare la policy di attendibilità. Invalid principal in policy." quando cerco di modificare la policy di attendibilità per il mio ruolo AWS Identity and Access Management (IAM) utilizzando la Console di gestione AWS.
Breve descrizione
Questo messaggio di errore indica che il valore di un elemento Principale nella tua policy di attendibilità IAM non è valido. Per risolvere questo errore, conferma quanto segue:
- La tua policy di attendibilità dei ruoli IAM utilizza valori supportati con una formattazione corretta per l'elemento Principale.
- Se la policy di attendibilità dei ruoli IAM usa Identità IAM (utenti, gruppi di utenti e ruoli) come principali, conferma che l'utente o il ruolo non è stato eliminato.
Nota: anche gli account AWS GovCloud (Stati Uniti) potrebbero ricevere questo errore se l'account AWS standard tenta di aggiungere il numero di account AWS GovCloud (Stati Uniti). Non è possibile creare un ruolo per delegare l'accesso tra un account AWS GovCloud (Stati Uniti) e un account AWS standard. Per ulteriori informazioni, consulta How IAM Differs for AWS GovCloud (US).
Risoluzione
Verifica i valori supportati per l'elemento principale
L'elemento principale nella policy di affidabilità IAM del tuo ruolo deve includere i seguenti valori supportati.
1. Assicurati che la policy IAM includa l'ID account AWS a 12 cifre corretto simile al seguente:
"Principal": { "AWS": "123456789012" }
Nota: l'account AWS può anche essere specificato utilizzando l'utente root Amazon Resource Name (ARN). Ad esempio, arn:aws:iam::123456789012:root.
2. Se i principali della policy di attendibilità IAM sono utenti, ruoli o utenti federati IAM, allora l'intero ARN deve essere specificato in modo simile al seguente:
"Principal": { "AWS": [ "arn:aws:iam::123456789012:user/user-name", "arn:aws:iam::123456789012:role/role-name", "arn:aws:sts::123456789012:assumed-role/role-name/role-session-name", "arn:aws:sts::123456789012:federated-user/user-name" ] }
3. Se la policy di attendibilità di IAM include caratteri jolly, segui queste linee guida.
Nota: non puoi utilizzare un carattere jolly "*" per far corrispondere parte del nome principale o dell'ARN.
L'esempio seguente mostra un uso errato di un carattere jolly in una policy di attendibilità IAM:
"Principal": { "AWS": "arn:aws:iam::123456789012:user/user-*" }
Per far corrispondere una parte del nome principale utilizzando un carattere jolly, usa un elemento Condizione con la chiave di condizione globale aws:PrincipalArn. Quindi, specifica un ARN con il carattere jolly.
Per specificare le identità di tutti gli account AWS, utilizza un carattere jolly simile al seguente:
"Principal": { "AWS": "*" }
Importante: è possibile utilizzare un carattere jolly nell'elemento principale con un effetto Consenti in una policy di attendibilità. Tuttavia, ciò consente a qualsiasi utente IAM, sessione di ruolo presunta o utente federato in qualsiasi account AWS nella stessa partizione di accedere al tuo ruolo. Gli utenti e i ruoli principali IAM all'interno del tuo account AWS non richiedono altre autorizzazioni. I principali di altri account AWS devono disporre di autorizzazioni basate sull'identità per assumere il tuo ruolo IAM.
Questo metodo non consente ai principali delle sessioni di identità web, ai principali delle sessioni SAML o ai principali dei servizi di accedere alle tue risorse.
Come procedura consigliata, utilizza questo metodo solo con l'elemento Condizione e una chiave di condizione come aws:PrincipalArn per limitare le autorizzazioni. Ad esempio, il tuo file potrebbe avere un aspetto simile al seguente:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::123456789012:user/user-*" } } } ] }
Questo esempio di policy di trust utilizza la chiave di condizione aws:PrincipalArn per consentire solo agli utenti con nomi utente corrispondenti di assumere il ruolo IAM.
4. Se il tuo ruolo IAM è un ruolo di servizio AWS, l'intero principale di servizio deve essere specificato in modo simile al seguente:
"Principal": { "Service": "ec2.amazonaws.com" }
5. Puoi utilizzare i principali di sessione SAML con un provider di identità SAML esterno per autenticare gli utenti IAM. La policy di attendibilità del ruolo IAM deve avere un elemento principale simile al seguente:
"Principal": { "Federated": "arn:aws:iam::123456789012:saml-provider/provider-name" }
6. Puoi utilizzare i principali delle sessioni di identità web per autenticare gli utenti IAM. La policy di attendibilità del ruolo IAM che fornisce l'accesso deve avere un elemento principale simile al seguente:
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
7. Se utilizzi diversi tipi principali all'interno di una singola dichiarazione, formatta la policy di attendibilità IAM in modo simile alla seguente:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/user-name", "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
L'utente o il ruolo IAM deve essere un'identità esistente
Se la policy di attendibilità dei ruoli IAM utilizza utenti o ruoli IAM come principali, conferma che tali identità IAM non siano state eliminate. L'errore "Invalid principal in policy" si verifica se si modifica la policy di attendibilità IAM e l'entità principale è stata eliminata.
Nota: se il principale è stato eliminato, annota l'ID univoco del principale nella policy di attendibilità IAM e non l'ARN.
Informazioni correlate
How do I use IAM to allow user access to resources?
Come posso accedere alle risorse di un altro account AWS utilizzando AWS IAM?
Perché c'è un formato principale sconosciuto nella mia policy basata sulle risorse IAM?
Contenuto pertinente
- AWS UFFICIALEAggiornata 3 anni fa
- AWS UFFICIALEAggiornata 3 anni fa
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 3 anni fa