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à.
# Tutorial IAM
I seguenti tutorial presentano end-to-end procedure complete per le attività comuni per AWS Identity and Access Management (IAM). Gli scenari presentati sono solo esempi con nomi di società e utenti fittizi destinati a essere usati in un ambiente di laboratorio. Il loro scopo è di fornire linee guida di carattere generico. Non devono essere utilizzati direttamente nell'ambiente di produzione, senza un'accurata opera di revisione e adattamento alle necessità esclusive del tuo ambiente lavorativo.
**Topics**
+ [Delega l'accesso tra Account AWS i ruoli di utilizzo](tutorial_cross-account-with-roles.md)
+ [Creazione di una policy gestita dal cliente](tutorial_managed-policies.md)
+ [Uso del controllo degli accessi basato su attributi (ABAC)](tutorial_attribute-based-access-control.md)
+ [Consentire agli utenti di gestire le loro credenziali e le impostazioni MFA](tutorial_users-self-manage-mfa-and-creds.md)
+ [Crea SAML IdP con CloudFormation](tutorial_saml-idp.md)
+ [Crea un ruolo federato SAML con CloudFormation](tutorial_saml-federated-role.md)
+ [Crea un IdP SAML e un ruolo federato con CloudFormation](tutorial_saml-idp-and-federated-role.md)
# Tutorial IAM: delega l'accesso tra AWS account utilizzando i ruoli IAM
**Importante**
[Le migliori pratiche](best-practices.md) IAM consigliano di richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee anziché utilizzare utenti IAM con credenziali a lungo termine. Ti consigliamo di utilizzare gli utenti IAM solo per [casi d'uso specifici](gs-identities-iam-users.md) non supportati dagli utenti federati.
In questo tutorial viene descritto come utilizzare un ruolo per delegare l'accesso a risorse che si trovano in diversi Account AWS di tua proprietà denominati **Destination** e **Originating**. Puoi condividere le risorse di un account con gli utenti di un altro account. Configurando in questo modo l'accesso fra account, non dovrai creare singoli utenti IAM per ogni account. Inoltre, gli utenti non devono uscire da un account e accedere a un altro per utilizzare risorse in Account AWS diversi. Dopo aver configurato il ruolo, vedrai come utilizzarlo tramite Console di gestione AWS AWS CLI, e l'API.
In questo tutorial, l'account **Destination** gestisce i dati delle applicazioni a cui accedono diverse applicazioni e team. In ciascun account puoi archiviare le informazioni sull'applicazione in bucket Amazon S3. Gestisci gli utenti IAM nell'account **Originating**, dove hai due ruoli utente IAM: **sviluppatori** e **analisti**. Gli sviluppatori e gli analisti utilizzano l'account **Originating** per generare dati condivisi da più microservizi. Entrambi i ruoli dispongono delle autorizzazioni per lavorare nell'account Originating e accedere alle sue risorse. Occasionalmente, uno sviluppatore deve aggiornare i dati condivisi nell'account **Destination**. Gli sviluppatori archiviano questi dati in un bucket Amazon S3 denominato `amzn-s3-demo-bucket-shared-container`.
Alla fine di questo tutorial, si dispone di quanto segue:
+ Utenti nell'account **Originating** (l'account attendibile) che possono assumere un ruolo specifico nell'account **Destination**.
+ Un ruolo nell'account **Destination** (l'account attendibile) che può accedere a uno specifico bucket Amazon S3.
+ Il bucket `amzn-s3-demo-bucket-shared-container` nell'account **Destination**.
Gli sviluppatori possono utilizzare il ruolo in Console di gestione AWS per accedere al `amzn-s3-demo-bucket-shared-container` bucket nell'account **Destination**. Inoltre, possono accedere al bucket utilizzando chiamate API autenticate tramite credenziali provvisorie fornite dal ruolo. La stessa operazione eseguita da un analista avrà esito negativo.
Questo flusso di lavoro ha tre fasi di base:
**[Creare un ruolo dell'account Destination](#tutorial_cross-account-with-roles-1)**
Innanzitutto, si utilizza il Console di gestione AWS per stabilire un rapporto di fiducia tra l'account di **destinazione** (numero ID 9999) e l'account di **origine** (numero ID 1111). Si inizia creando un ruolo IAM denominato. *UpdateData* Quando crei il ruolo, devi definire l'account **Originating** come entità attendibile e specificare una policy di autorizzazioni che consenta agli utenti attendibili di aggiornare il bucket `amzn-s3-demo-bucket-shared-container`.
**[Concedi autorizzazione per l'accesso al ruolo](#tutorial_cross-account-with-roles-2)**
In questa sezione, puoi modificare la policy del ruolo per negare l'accesso al ruolo `UpdateData` agli analisti. Perché gli analisti hanno PowerUser accesso in questo scenario e tu devi *negare* esplicitamente la possibilità di utilizzare il ruolo.
**[Accesso al test tramite cambio di ruoli](#tutorial_cross-account-with-roles-3)**
Infine, in qualità di sviluppatore utilizzerai il ruolo `UpdateData` per aggiornare il bucket `amzn-s3-demo-bucket-shared-container` nell'account **Destination**. Scopri come accedere al ruolo tramite la AWS console, l'e l' AWS CLI API.
## Considerazioni
Prima di utilizzare i ruoli IAM per delegare l'accesso alle risorse su più fronti Account AWS, è importante considerare quanto segue:
+ Non è possibile passare a un ruolo se l'accesso è stato effettuato come Utente root dell'account AWS.
+ I ruoli IAM e le policy basate sulle risorse delegano l'accesso tra account solo all'interno di una singola partizione. Ad esempio, si supponga di disporre di un account nella regione Stati Uniti occidentali (California settentrionale) nella partizione `aws` standard. Hai anche un account nella regione Cina (Pechino) nella partizione `aws-cn`. Non è possibile utilizzare una policy basata sulle risorse Amazon S3 nel tuo account nella regione Cina (Pechino) per consentire l'accesso agli utenti del tuo account `aws` standard.
+ Puoi utilizzarlo AWS IAM Identity Center per facilitare il Single Sign-On (SSO) per account esterni Account AWS (account esterni al tuo) utilizzando Security Assertion Markup Language (SAML AWS Organizations). Per i dettagli, consulta [Integrazione di sistemi esterni Account AWSAWS IAM Identity Center per la gestione centralizzata degli accessi](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en) con fatturazione indipendente tramite SAML 2.0
+ Puoi associare ruoli a AWS risorse come istanze o funzioni di Amazon EC2. AWS Lambda Per informazioni dettagliate, vedi [Creare un ruolo per delegare le autorizzazioni a un servizio AWS](id_roles_create_for-service.md).
+ Se desideri che un'applicazione assuma un ruolo in un'altra Account AWS, puoi utilizzare l' AWS SDK per l'assunzione di ruoli tra account. Per ulteriori informazioni, consulta [Autenticazione e accesso nella Guida](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) di *riferimento agli strumenti AWS SDKs e agli strumenti.*
+ Il cambio di ruolo utilizzando il funziona Console di gestione AWS solo con account che non richiedono un`ExternalId`. Ad esempio, si supponga di concedere l'accesso al proprio account a terzi e di richiedere un `ExternalId` in un elemento `Condition` nella policy di autorizzazione. In tal caso, la terza parte può accedere all'account solo utilizzando l' AWS API o uno strumento da riga di comando. Le terze parti non possono utilizzare la console perché non sono in grado di fornire un valore per `ExternalId`. Per ulteriori informazioni su questo scenario[Accesso a Account AWS siti di proprietà di terzi](id_roles_common-scenarios_third-party.md), consulta e [Come abilitare l'accesso da più account a Console di gestione AWS nel](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) AWS Security Blog.
## Prerequisiti
Questo tutorial presuppone che tu abbia a disposizione quanto segue:
+ È possibile utilizzarne **due** Account AWS distinti, uno per rappresentare l'account di **origine** e uno per rappresentare l'account di **destinazione**.
+ Utenti e gruppi nell'account **Originating**, creati e configurati in questo modo:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ Non è necessario creare utenti nell'account **Destination**.
+ Un bucket Amazon S3 creato nell'account **Destination**. Nel tutorial puoi chiamarlo `amzn-s3-demo-bucket-shared-container`, ma dato che i nomi dei bucket S3 devono essere univoci a livello globale, dovrai selezionare un nome diverso.
## Creare un ruolo dell'account Destination
Puoi consentire agli utenti di uno di accedere Account AWS alle risorse di un altro Account AWS. In questo tutorial, ciò verrà effettuato creando un ruolo che definisca chi può accedervi e quali autorizzazioni concedere agli utenti che lo assumono.
In questo passaggio del tutorial, dovrai creare il ruolo nell'account **Destination** e impostare l'account **Originating** come entità attendibile. Inoltre, dovrai limitare le autorizzazioni del ruolo al solo accesso di lettura e scrittura per il bucket `amzn-s3-demo-bucket-shared-container`. Chiunque abbia ricevuto l'autorizzazione a usare il ruolo potrà leggere e scrivere nel bucket `shared-container`.
Prima di poter creare un ruolo, è necessario l'*ID dell'account* di **Originating** Account AWS. A ognuno Account AWS è assegnato un identificatore ID account univoco.
**Per ottenere l'ID di origine Account AWS**
1. Accedi Console di gestione AWS come amministratore dell'account **Originating** e apri la console IAM all'indirizzo. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Nella console IAM, scegli il tuo nome utente nella barra di navigazione in alto a destra. Di solito ha il seguente aspetto: ***username*@ *account\$1ID\$1number\$1or\$1alias***.
Per questo scenario, puoi utilizzare l'ID account 111111111111 per l'account **Originating**. Tuttavia, devi utilizzare un ID account valido se stai usando questo scenario nell'ambiente di test.
**Per creare un ruolo nell'account Destination che possa essere utilizzato dall'account Originating**
1. Accedi Console di gestione AWS come amministratore dell'account di **destinazione** e apri la console IAM.
1. Prima di creare il ruolo, prepara la policy gestita che definisce le autorizzazioni per i requisiti del ruolo. La policy verrà collegata al ruolo in una fase successiva.
Impostare l'accesso in lettura e scrittura al bucket `amzn-s3-demo-bucket-shared-container`. Sebbene AWS fornisca alcune policy gestite di Amazon S3, non ce n'è una che fornisca l'accesso in lettura e scrittura a un singolo bucket Amazon S3. Se lo desideri, puoi creare una policy personalizzata.
Nel pannello di navigazione, seleziona **Policy** e **Crea policy**.
1. Seleziona la scheda **JSON** e copia il testo dal documento della seguente policy JSON. Incollare il testo nella casella di testo **JSON**, sostituendo l'ARN della risorsa (`arn:aws:s3:::shared-container`) con quello per reale per il bucket Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
L'azione `ListAllMyBuckets` concede l'autorizzazione per elencare tutti i bucket di proprietà del mittente autenticato della richiesta. L'autorizzazione `ListBucket` consente agli utenti di visualizzare gli oggetti del bucket `amzn-s3-demo-bucket-shared-container`. Le autorizzazioni `GetObject`, `PutObject` e `DeleteObject` consentono agli utenti di visualizzare, aggiornare ed eliminare i contenuti del bucket `amzn-s3-demo-bucket-shared-container`.
**Nota**
È possibile alternare le opzioni dell'editor **Visivo** e **JSON** in qualsiasi momento. Se tuttavia si apportano modifiche o si seleziona **Successivo** nell'editor **Visivo**, IAM potrebbe ristrutturare la policy in modo da ottimizzarla per l'editor visivo. Per ulteriori informazioni, consulta [Modifica della struttura delle policy](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Nella pagina **Verifica policy**, digita **read-write-app-bucket** come nome della policy. Esamina le autorizzazioni concesse dalla policy, quindi scegli **Crea policy** per salvare il lavoro.
La nuova policy viene inserita nell'elenco delle policy gestite.
1. Nel riquadro di navigazione, scegli **Ruoli**, quindi **Crea ruolo**.
1. Scegli il tipo di ruolo **Un Account AWS**.
1. Per **ID account**, digita l'ID dell'account **Originating**.
Questo tutorial utilizza l'ID account di esempio **111111111111** per l'account di **Originating**. Tuttavia, è consigliabile utilizzare un ID account valido. Se utilizzi un ID account non valido, come ad esempio **111111111111**, IAM non ti consentirà di creare il nuovo ruolo.
Per il momento non è necessario richiedere un ID esterno, né chiedere agli utenti un'autenticazione a più fattori (MFA) per assumere il ruolo. Tali opzioni possono rimanere deselezionate. Per ulteriori informazioni, consulta [AWS Autenticazione a più fattori in IAM](id_credentials_mfa.md).
1. Selezionare **Next:Permissions (Avanti:Autorizzazioni)** per impostare le autorizzazioni associate al ruolo.
1. Seleziona la casella di controllo accanto alla policy creata in precedenza.
**Suggerimento**
In **Filter (Filtro)** selezionare **Customer managed (Gestite dal cliente)** per visualizzare solo le policy create. Il filtro nasconde le policy create da AWS per semplificare la ricerca.
Quindi, seleziona **Successivo**.
1. (Facoltativo) Aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull'utilizzo dei tag in IAM, consultare [Tag per AWS Identity and Access Management le risorse](id_tags.md).
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il nuovo ruolo.
1. Dopo avere rivisto il ruolo, fare clic su **Create Role (Crea ruolo)**.
Il ruolo `UpdateData` viene visualizzato nell'elenco dei ruoli.
A questo punto, è necessario ottenere l'Amazon Resource Name (ARN), un identificatore univoco per il ruolo. Quando modifichi il ruolo dello sviluppatore nell'account Originating, specifica l'ARN del ruolo dell'account Destination per concedere o negare le autorizzazioni.
**Per ottenere l'ARN per UpdateData**
1. Nel pannello di navigazione della console IAM seleziona **Ruoli**.
1. Nell'elenco dei ruoli, selezionare il ruolo `UpdateData`.
1. Nella sezione **Summary (Riepilogo)** del riquadro dei dettagli, copiare il valore **Role ARN (ARN ruolo)**.
L'ID dell'account Destination è 999999999999, pertanto l'ARN del ruolo sarà `arn:aws:iam::999999999999:role/UpdateData`. Assicurati di fornire l' Account AWS ID reale dell'account di destinazione.
A questo punto, hai stabilito un rapporto di fiducia tra gli account **Destination** e **Originating**. È stato possibile creando un ruolo nell'account **Destination** che identifica l'account **Originating** come principale attendibile. Inoltre, hai definito le operazioni consentite agli utenti che passano al ruolo `UpdateData`.
Quindi, modifica le autorizzazioni per il ruolo da sviluppatore.
## Concedi autorizzazione per l'accesso al ruolo
A questo punto, sia gli analisti che gli sviluppatori dispongono delle autorizzazioni che consentono di gestire i dati dell'account **Originating**. Usare i seguenti passaggi necessari per aggiungere le autorizzazioni per il cambio di ruolo.
**Modificare il ruolo Sviluppatori per consentire loro di passare al UpdateData ruolo**
1. Accedi come amministratore nell'account **Originating** e apri la console IAM.
1. Seleziona **Ruoli** e quindi **Developers**.
1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Crea policy in linea**.
1. Scegli la scheda **JSON**.
1. Aggiungi la seguente istruzione di policy per consentire l'azione `AssumeRole` sul ruolo `UpdateData` nell'account Destination. Assicurati di modificare *DESTINATION-ACCOUNT-ID* l'`Resource`elemento con l' Account AWS ID effettivo dell'account di destinazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L'effetto `Allow` consente in modo esplicito al gruppo Sviluppatori l'accesso al ruolo `UpdateData` dell'account Destination. Qualsiasi sviluppatore potrà accedere al ruolo.
1. Scegliere **Esamina policy**.
1. Digita un **nome**, ad esempio **allow-assume-S3-role-in-destination**.
1. Scegli **Crea policy**.
Nella maggior parte degli ambienti, la procedura seguente risulta superflua. Se, tuttavia, utilizzi PowerUserAccess le autorizzazioni, alcuni gruppi potrebbero già essere in grado di cambiare ruolo. La procedura descritta di seguito mostra come aggiungere un'autorizzazione `"Deny"` al gruppo Analisti, per impedire ai suoi membri di assumere il ruolo. Se questa procedura non è necessaria nel tuo ambiente, è preferibile non aggiungerla. Le autorizzazioni `"Deny"` di tipo generale sono più complicate da gestire e comprendere. Utilizza le autorizzazioni `"Deny"` solo quando non sono disponibili alternative migliori.
**Per modificare il ruolo Analisti e negare l'autorizzazione ad assumere tale ruolo `UpdateData`**
1. Scegli **Ruoli**, quindi scegli **Analisti**.
1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Crea policy in linea**.
1. Scegli la scheda **JSON**.
1. Aggiungere la seguente istruzione di policy per negare l'operazione `AssumeRole` nel ruolo `UpdateData`. Assicurati di modificare *DESTINATION-ACCOUNT-ID* l'`Resource`elemento con l' Account AWS ID effettivo dell'account di destinazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L'effetto `Deny` impedisce in modo esplicito al gruppo Analisi l'accesso al ruolo `UpdateData` dell'account Destination. Se un analista prova ad accedere al ruolo riceve un messaggio di accesso negato.
1. Scegliere **Esamina policy**.
1. Digita un **nome** come **deny-assume-S3-role-in-destination**.
1. Scegli **Crea policy**.
Il gruppo Sviluppatori ora dispone delle autorizzazioni per utilizzare il ruolo `UpdateData` nell'account Destination. Il ruolo Analista invece non può utilizzare il ruolo `UpdateData`.
Successivamente, vedrai come David, uno sviluppatore, può accedere al bucket `amzn-s3-demo-bucket-shared-container` nell'account Destination. David può accedere al bucket dalla Console di gestione AWS AWS CLI, dalla o dall' AWS API.
## Accesso al test tramite cambio di ruoli
Al termine dei primi due passaggi del tutorial, disponi di un ruolo che concede l'accesso a una risorsa dell'account **Destination**. Hai anche creato un ruolo nell'account **Originating** con utenti autorizzati a utilizzare tale ruolo. In questo passaggio viene illustrato come testare il passaggio a quel ruolo tramite Console di gestione AWS AWS CLI, l'e l' AWS API.
Per ottenere assistenza su problemi comuni che possono verificarsi durante l'utilizzo dei ruoli IAM, consulta [Risoluzione dei problemi relativi ai ruoli IAM](troubleshoot_roles.md).
### Cambio di ruoli (Console)
Se David deve aggiornare i dati nell'account **Destination** in Console di gestione AWS, può farlo utilizzando **Switch Role**. Specificando l'ID account o l'alias e il nome del ruolo, le sue autorizzazioni passano immediatamente a quelle consentite dal ruolo. Potrà quindi utilizzare la console per lavorare con il bucket `amzn-s3-demo-bucket-shared-container`, ma non sarà in grado utilizzare le altre risorse dell'account **Destination**. Inoltre, mentre utilizza il ruolo, David non può sfruttare i suoi privilegi di utente avanzato, validi per l'account **Originating**, perché non si possono attivare più set di autorizzazioni contemporaneamente.
IAM fornisce due alternative per accedere alla pagina **Switch Role (Cambia ruolo)**:
+ David riceve dal suo amministratore un link che rimanda a una configurazione "Switch Role" (Cambia ruolo) predefinita. Il collegamento viene fornito all'amministratore nella pagina finale della procedura guidata **Create role (Crea ruolo)** oppure nella pagina **Role Summary (Riepilogo ruolo)** per un ruolo tra più account. Selezionando questo link, David viene indirizzato alla pagina **Switch Role (Cambia ruolo)** con i campi **Account ID (ID account)** e **Role name (Nome ruolo)** già compilati. David non deve fare altro che selezionare **Cambia ruoli**.
+ Anziché spedire un'e-mail con il link, l'amministratore invia il numero **Account ID (ID account)** e i valori per **Role Name (Nome ruolo)**. Per cambiare ruolo, David deveinserire manualmente i valori. Tale procedura viene descritta di seguito.
**Come assumere un ruolo**
1. David accede Console di gestione AWS utilizzando il suo utente normale nell'account **Originating**.
1. Seleziona il link che l'amministratore gli ha inviato per e-mail. A questo punto, David viene indirizzato alla pagina **Switch Role** (Cambia ruolo) che contiene già le informazioni relative all'ID account o all'alias e il nome del ruolo.
oppure
David seleziona il proprio nome nel menu Identity (Identità) della barra di navigazione, quindi sceglie **Switch Roles** (Cambia ruolo).
Se questa è la prima volta che David cerca di accedere alla pagina Switch Role (Cambia ruolo) in questo modo, verrà visualizzata una pagina introduttiva di **Switch Role (Cambia ruolo)** In questa pagina sono riportate ulteriori informazioni su come il cambio di ruolo può consentire agli utenti di gestire le risorse su più Account AWS. In questa pagina, David deve selezionare **Switch Role (Cambia ruolo)** per completare il resto della procedura.
1. Successivamente, per accedere al ruolo, David dovrà digitare manualmente il numero di ID dell'account Destination (`999999999999`) e il nome del ruolo (`UpdateData`).
Inoltre, David vuole monitorare quali ruoli e autorizzazioni associate sono attualmente attivi su IAM. Per tenere traccia di queste informazioni, digita `Destination` nella casella di testo **Nome di visualizzazione**, seleziona l'opzione di colore rosso e quindi seleziona **Cambia ruolo**.
1. Ora David può utilizzare la console Amazon S3 per lavorare con il bucket Amazon S3 o con qualsiasi altra risorsa per la quale il ruolo `UpdateData` dispone di autorizzazioni.
1. Al termine, David può tornare alle sue autorizzazioni originali. A tale scopo, seleziona il nome del ruolo **Destination** nella barra di navigazione, quindi seleziona **Torna a David @ 111111111111**.
1. Se dovesse avere nuovamente bisogno di cambiare ruolo, David potrà selezionare il menu **Identità** nel riquadro di navigazione e troverà già presente la voce Destination. Non dovrà fare altro che selezionare tale voce per cambiare immediatamente ruolo, senza immettere nuovamente l'account ID e il nome del ruolo.
### Cambio di ruoli (AWS CLI)
Se David dovesse avere bisogno di lavorare nell'ambiente **Destination**, alla riga di comando, può farlo tramite la [AWS CLI](https://aws.amazon.com/cli/). Esegue il comando `aws sts assume-role` e trasferisce l'ARN del ruolo per ottenere le credenziali di sicurezza provvisorie per quel ruolo. Quindi configura tali credenziali nelle variabili di ambiente in modo che AWS CLI i comandi successivi funzionino utilizzando le autorizzazioni del ruolo. Mentre utilizza il ruolo, David non può sfruttare i suoi privilegi di utente avanzato, validi per l'account **Originating**, perché non si possono attivare più set di autorizzazioni contemporaneamente.
Tutte le chiavi di accesso e i token sono solo esempi e non possono essere utilizzati come mostrato. Sostituiscili con i valori appropriati del tuo ambiente reale.
**Come assumere un ruolo**
1. David apre una finestra del prompt dei comandi e conferma che il AWS CLI client funziona eseguendo il comando:
```
aws help
```
**Nota**
L'ambiente predefinito di David utilizza le credenziali utente `David` ottenute dal profilo predefinito creato con il comando `aws configure`. Per ulteriori informazioni, consulta [Configurazione della AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) nella *Guida per l'utente di AWS Command Line Interface *.
1. Inizia il processo di cambio ruolo eseguendo il seguente comando per passare al ruolo `UpdateData` dell'account **Destination**. Ha ricevuto l'ARN del ruolo dall'amministratore che ha creato il ruolo. Il comando richiede anche un nome di sessione (qualsiasi testo è valido).
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
A questo punto David potrà consultare quanto segue:
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David può trovare le tre parti di cui ha bisogno nella sezione Credentials (Credenziali) dell'output.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David deve configurare l' AWS CLI ambiente per utilizzare questi parametri nelle chiamate successive. Per informazioni sui vari modi di configurare le credenziali, consulta [Configurare AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Non può utilizzare il comando `aws configure`, perché non supporta l'acquisizione il token della sessione. Tuttavia, può inserire manualmente le informazioni in un file di configurazione. Poiché si tratta di credenziali provvisorie, con una durata relativamente breve, è più facile per aggiungerle all'ambiente della sessione corrente della riga di comando.
1. Per aggiungere i tre valori all'ambiente, David taglia e incolla l'output del passaggio precedente nei comandi seguenti. Per risolvere i problemi con gli accapo presenti nel token della sessione, è possibile tagliare e incollare in un semplice editor di testo. Il testo deve essere inserito come un'unica stringa lunga, anche se qui viene riportato spezzato, per motivi di chiarezza.
L'esempio seguente mostra i comandi forniti nell'ambiente Windows, dove "set" è il comando per creare una variabile di ambiente. Su un computer Linux o MacOS, bisogna utilizzare invece il comando "export". Tutte le altre parti dell'esempio sono valide per tutti i tre ambienti.
Per dettagli sull'utilizzo di Tools for Windows Powershell, consulta [Passare a un ruolo IAM (Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
A questo punto, tutti i comandi successivi vengono eseguiti con le autorizzazioni del ruolo identificato da tali credenziali (nel caso di David, il ruolo `UpdateData`).
**Importante**
Puoi salvare le impostazioni di configurazione e le credenziali utilizzate di frequente nei file gestiti da AWS CLI. Per ulteriori informazioni, consulta [File di configurazione e delle credenziali esistenti](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) nella *Guida per l'utente di AWS Command Line Interface *.
1. Eseguire il comando per accedere alle risorse dell'account Destination. In questo esempio, David si limita a elencare il contenuto del suo bucket S3 con il comando seguente.
```
aws s3 ls s3://shared-container
```
Poiché i nomi del bucket Amazon S3 sono universalmente univoci, non è necessario specificare quale ID account possiede il bucket. Per accedere alle risorse di altri AWS servizi, consulta la AWS CLI documentazione del servizio per conoscere i comandi e la sintassi necessari per fare riferimento alle relative risorse.
### Utilizzo di AssumeRole (AWS API)
Per aggiornare l'account **Destination** da codice, David effettua una chiamata `AssumeRole` per assumere il ruolo `UpdateData`. La chiamata restituisce le credenziali provvisorie, utilizzabili per accedere al bucket `amzn-s3-demo-bucket-shared-container` dell'account **Destination**. David può utilizzare tali credenziali per effettuare chiamate API per aggiornare il bucket `amzn-s3-demo-bucket-shared-container`. Tuttavia, non sarà in grado di effettuare chiamate API per accedere alle altre risorse dell'account **Destination**, anche se dispone di autorizzazioni da utente avanzato per l'account **Originating**.
**Come assumere un ruolo**
1. David richiama `AssumeRole` come parte di un'applicazione Deve specificare l'ARN di `UpdateData`: `arn:aws:iam::999999999999:role/UpdateData`.
La risposta alla chiamata `AssumeRole` include le credenziali temporanee con un `AccessKeyId` e un `SecretAccessKey`. Include anche un'ora `Expiration` che indica quando le credenziali scadono e sarà necessario richiederne di nuove. Quando configuri il concatenamento dei ruoli con l' AWS SDK, molti provider di credenziali aggiornano automaticamente le credenziali prima che scadano.
1. David utilizza le credenziali provvisorie per inviare una chiamata `s3:PutObject` per aggiornare il bucket `amzn-s3-demo-bucket-shared-container`. Trasferisce le credenziali alla chiamata API come parametro `AuthParams`. Dato che le credenziali provvisorie del ruolo forniscono solo un accesso in lettura e scrittura al bucket `amzn-s3-demo-bucket-shared-container`, tutte le altre azioni nell'account Destination sono negate.
Per un esempio di codice (con Python), consultare [Passa a un ruolo IAM (AWS API)](id_roles_use_switch-role-api.md).
## Risorse aggiuntive
Le seguenti risorse possono aiutarti a saperne di più sugli argomenti trattati in questo tutorial:
+ Per ulteriori informazioni sugli utenti IAM, consulta [Identità IAM](id.md).
+ Per ulteriori informazioni sui bucket Amazon S3, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
+ Per capire se i principali negli account esterni alla zona di attendibilità (organizzazione o account attendibile) dispongono dell'accesso per assumere i ruoli, consulta [Cos'è IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
## Riepilogo
Hai completato il tutorial per l'accesso alle API di più account. Hai creato un ruolo per stabilire la relazione di trust con un altro account e hai definito le operazioni che possono essere eseguite dalle entità affidabili. Successivamente, hai modificato una policy del ruolo per controllare quali utenti IAM possono accedere al ruolo. Come risultato, gli sviluppatori dell'account **Originating** possono aggiornare il bucket `amzn-s3-demo-bucket-shared-container` dell'account **Destination**, utilizzando credenziali provvisorie.
# Tutorial IAM: Creazione e collegamento della prima policy gestita dal cliente
In questo tutorial, utilizzerai la Console di gestione AWS per creare una [policy gestita dai clienti](access_policies_managed-vs-inline.md#customer-managed-policies) e poi allegherai tale policy a un utente IAM del tuo Account AWS. La policy che crei consente a un utente di test IAM di accedere direttamente a Console di gestione AWS con autorizzazioni di sola lettura.
Questo flusso di lavoro ha tre fasi di base:
**[Fase 1: creazione della policy](#step1-create-policy)**
Per impostazione predefinita, gli utenti IAM non hanno autorizzazioni per alcuna operazione. Non possono accedere alla Console di gestione AWS né gestire i dati al suo interno, a meno che non venga loro permesso di farlo. In questa fase crei una policy gestita dal cliente che permette agli utenti collegati di accedere alla console.
**[Fase 2: collegamento della policy](#step2-attach-policy)**
Quando colleghi una policy a un utente, l'utente eredita tutte le autorizzazioni di accesso associate alla policy. In questa fase, colleghi la nuova policy a un utente di test.
**[Fase 3: test dell'accesso utente](#step3-test-access)**
Una volta che la policy è collegata, puoi effettuare l'accesso come utente e testare la policy.
## Prerequisiti
Per eseguire le fasi in questo tutorial, devi disporre di quanto segue:
+ E a Account AWS cui puoi accedere come utente IAM con autorizzazioni amministrative.
+ Un utente IAM di test che non dispone di autorizzazioni assegnate o di appartenenze ai gruppi, come illustrato di seguito:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_managed-policies.html)
## Fase 1: creazione della policy
In questo passaggio, crei una policy gestita dai clienti che consente a qualsiasi utente collegato di accedere Console di gestione AWS con accesso in sola lettura ai dati IAM.
**Per creare la policy per l'utente di test**
1. Accedi alla console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)con il tuo utente con autorizzazioni di amministratore.
1. Nel pannello di navigazione, seleziona **Policies (Policy)**.
1. Nel riquadro del contenuto seleziona **Create policy (Crea policy)**.
1. Seleziona l'opzione **JSON** e copia il testo dal seguente documento della policy JSON. Incolla il testo nella casella di testo **JSON**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
```
------
1. Risolvi eventuali avvisi di sicurezza, errori o avvisi generali generati durante la [convalida delle policy](access_policies_policy-validator.md), quindi scegli **Next** (Successivo).
**Nota**
È possibile alternare le opzioni dell'editor **Visivo** e **JSON** in qualsiasi momento. Se tuttavia si apportano modifiche o se si seleziona **Rivedi policy** nella scheda **Editor visivo**, IAM potrebbe ristrutturare la policy per ottimizzarla per l'editor visivo. Per ulteriori informazioni, consulta [Modifica della struttura delle policy](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Nella pagina **Verifica policy**, digita **UsersReadOnlyAccessToIAMConsole** come nome della policy. Esamina le autorizzazioni concesse dalla policy, quindi scegli **Crea policy** per salvare il lavoro.
La nuova policy appare nell'elenco delle policy gestite ed è pronta a collegare.
## Fase 2: collegamento della policy
Collega quindi la policy appena creata all'utente di test IAM.
**Per collegare la policy all'utente di test**
1. Nel pannello di navigazione della console IAM seleziona **Policy**.
1. Nella parte superiore dell'elenco delle policy, nella casella di ricerca, inizia a digitare **UsersReadOnlyAccesstoIAMConsole** finché non viene visualizzata la policy. Quindi scegli il pulsante di opzione accanto **UsersReadOnlyAccessToIAMConsole**all'elenco.
1. Fai clic sul pulsante **Actions** (Operazioni), quindi scegli **Attach** (Collega).
1. In Entità IAM scegli l'opzione per filtrare in base a **Utenti**.
1. Nella casella di ricerca, inizia a digitare **PolicyUser** fino a quando l'utente non è visibile nell'elenco. Quindi seleziona la casella accanto a tale utente nell'elenco.
1. Scegli **Collega policy**.
La policy è stata collegata all'utente di test IAM quindi ora l'utente dispone di accesso in sola lettura alla console IAM.
## Fase 3: test dell'accesso utente
Per questa esercitazione, consigliamo di verificare l'accesso autenticandosi come utente di prova in modo da poter visualizzare la potenziale esperienza degli utenti.
**Per testare l'accesso accedendo con l'utente di test**
1. Accedi alla console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)con il tuo utente `PolicyUser` di prova.
1. Esplora le pagine della console e prova a creare un nuovo utente o gruppo. Tieni presente che `PolicyUser` può visualizzare i dati, ma non può creare o modificare i dati IAM esistenti.
## Risorse correlate
Per informazioni correlate, consulta le seguenti risorse:
+ [Policy gestite e policy inline](access_policies_managed-vs-inline.md)
+ [Controlla l'accesso degli utenti IAM a Console di gestione AWS](console_controlling-access.md)
## Riepilogo
Hai completato tutte le fasi necessarie per creare e collegare una policy gestita dal cliente. Di conseguenza, è possibile accedere alla console IAM con il proprio account di test per verificare l'esperienza degli utenti.
# Tutorial IAM: definisci le autorizzazioni per accedere alle AWS risorse in base ai tag
Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. In AWS, questi attributi sono chiamati *tag*. Puoi allegare tag alle risorse IAM, incluse le entità IAM (utenti o ruoli) e alle AWS risorse. È possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni ai principali sulla base dei relativi tag. Quando usi i tag per controllare l'accesso alle tue AWS risorse, consenti ai team e alle risorse di crescere con meno modifiche alle AWS policy. Le politiche ABAC sono più flessibili delle AWS politiche tradizionali, che richiedono di elencare ogni singola risorsa. Per ulteriori informazioni su ABAC e i suoi vantaggi rispetto alle policy tradizionali, consulta [Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC](introduction_attribute-based-access-control.md).
**Nota**
È necessario passare un singolo valore per ogni tag di sessione. AWS Security Token Service non supporta tag di sessione multivalore.
**Topics**
+ [
## Panoramica del tutorial
](#tutorial_attribute-based-access-control-overview)
+ [
## Prerequisiti
](#tutorial_abac_prereqs)
+ [
## Fase 1: creazione degli utenti di test
](#tutorial_abac_step1)
+ [
## Fase 2: creazione della policy ABAC
](#tutorial_abac_step2)
+ [
## Fase 3: creazione di ruoli
](#tutorial_abac_step3)
+ [
## Fase 4: verifica della creazione di segreti
](#tutorial_abac_step4)
+ [
## Fase 5: verifica della visualizzazione dei segreti
](#tutorial_abac_step5)
+ [
## Fase 6: verifica della scalabilità
](#tutorial_abac_step6)
+ [
## Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti
](#tutorial_abac_step7)
+ [
## Riepilogo
](#tutorial-abac-summary)
+ [
## Risorse correlate
](#tutorial_abac_related)
+ [
# Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC
](tutorial_abac-saml.md)
## Panoramica del tutorial
Questo tutorial mostra come creare e testare una policy che consente ai ruoli IAM con tag del principale di accedere alle risorse con i tag corrispondenti. Quando un principale effettua una richiesta ad AWS, le autorizzazioni vengono concesse in base al fatto che i tag del principale e quelli della risorsa corrispondano. Questa strategia consente alle persone di visualizzare o modificare solo AWS le risorse necessarie per il proprio lavoro.
**Scenario**
Si supponga di essere uno sviluppatore responsabile in una grande azienda denominata Example Corporation e di essere un amministratore IAM esperto. Si ha familiarità con la creazione e la gestione di utenti, ruoli e policy IAM. Si desidera garantire che i gli ingegneri dedicati allo sviluppo e i membri del team di garanzia della qualità possano accedere alle risorse di cui hanno bisogno. C'è anche bisogno di una strategia in grado di ridimensionarsi man mano che l'azienda cresce.
Scegli di utilizzare i tag AWS delle risorse e i tag principali dei ruoli IAM per implementare una strategia ABAC per i servizi che la supportano, a cominciare Gestione dei segreti AWS da. Per informazioni su quali servizi supportano l'autorizzazione basata sui tag, consulta [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md). Per scoprire quali chiavi di condizione di etichettatura puoi utilizzare in una policy con le azioni e le risorse di ciascun servizio, consulta [Azioni, risorse e chiavi di condizione per i AWS](reference_policies_actions-resources-contextkeys.html) servizi. È possibile configurare il provider di identità basato su SAML o web per passare [i tag di sessione](id_session-tags.md) ad AWS. Quando i dipendenti si uniscono AWS, i loro attributi vengono applicati al responsabile risultante. AWSÈ quindi possibile utilizzare ABAC per consentire o negare le autorizzazioni sulla base di tali attributi. Per informazioni su come l'utilizzo di tag di sessione con un'identità federata SAML differisce da questa esercitazione, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md).
I membri dei team Engineering e Quality Assurance fanno parte del progetto **Pegasus** o **Unicorn** . È possibile scegliere i seguenti valori di tag lunghi 3 caratteri per progetto e team:
+ `access-project` = `peg` per il progetto **Pegasus**
+ `access-project` = `uni` per il progetto **Unicorn**
+ `access-team` = `eng` per il team di Engineering
+ `access-team` = `qas` per il team di Quality Assurance
Inoltre, scegli di richiedere il tag di allocazione dei `cost-center` costi per abilitare i report di fatturazione personalizzati AWS . Per ulteriori informazioni, consulta la pagina sull'[utilizzo dei tag per l'allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) nella *Guida per l'utente di Gestione dei costi e fatturazione AWS *.
**Riepilogo delle scelte principali**
+ I dipendenti eseguono l'accesso con le credenziali dell'utente IAM e quindi assumono il ruolo IAM associato ai relativi team e il progetto. Se l'azienda dispone di un proprio sistema di identità, puoi configurare la federazione per consentire ai dipendenti di assumere un ruolo senza dover passare attraverso gli utenti IAM. Per ulteriori informazioni, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md).
+ La stessa policy è collegata a tutti i ruoli. Le operazioni sono consentite o negate in base ai tag.
+ I dipendenti possono creare nuove risorse, ma solo se collegano alla risorsa gli stessi tag che sono applicati al loro ruolo. In questo modo i dipendenti possono visualizzare la risorsa dopo averla creata. Gli amministratori non sono più tenuti ad aggiornare le policy con l'ARN delle nuove risorse.
+ I dipendenti possono leggere le risorse di proprietà del loro team, indipendentemente dal progetto.
+ I dipendenti possono aggiornare ed eliminare le risorse di proprietà del proprio team e progetto.
+ Gli amministratori IAM possono aggiungere un nuovo ruolo per i nuovi progetti. Possono creare e associare tag a un nuovo utente IAM per consentire l'accesso al ruolo appropriato. Gli amministratori non sono tenuti a modificare una policy per supportare un nuovo progetto o membro del team.
In questa esercitazione, verranno associati tag a tutte le risorse e ai ruoli del progetto e aggiunte policy ai ruoli per consentire il comportamento precedentemente descritto. La policy risultante consente ai ruoli `Create`, `Read`, `Update` e `Delete` l'accesso alle risorse contrassegnate con gli stessi tag di progetto e team. La policy consente inoltre l'accesso tra progetti in modalità `Read` per le risorse contrassegnate con lo stesso team.
![\[Il diagramma mostra due progetti in cui i ruoli sono limitati all'accesso in sola lettura all'esterno del progetto e dispongono delle autorizzazioni per creare, leggere, aggiornare ed eliminare risorse nel proprio progetto.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png)
## Prerequisiti
Per eseguire queste fasi in questo tutorial, è necessario quanto segue:
+ E a Account AWS cui puoi accedere come utente con autorizzazioni amministrative.
+ L'ID account a 12 cifre, che si utilizza per creare i ruoli nel passaggio 3.
Per trovare il numero ID dell' AWS account utilizzando Console di gestione AWS, scegli **Supporto** nella barra di navigazione in alto a destra, quindi scegli **Support Center**. Il numero dell'account (ID) viene visualizzato nel riquadro di navigazione a sinistra.
![\[Supporto Pagina centrale che mostra il numero dell'account.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/account-id-support-center.console.png)
+ Creazione e modifica di utenti, ruoli e policy IAM nella Console di gestione AWS. Tuttavia, se hai bisogno di aiuto per ricordare un processo di gestione IAM, questo tutorial fornisce collegamenti in cui puoi visualizzare step-by-step le istruzioni.
## Fase 1: creazione degli utenti di test
A scopo di test, crea quattro utenti IAM con le autorizzazioni per assumere ruoli con gli stessi tag. In questo modo è più facile aggiungere più utenti ai team. Quando si associano i tag agli utenti, questi ottengono automaticamente l'accesso per assumere il ruolo corretto. Non è necessario aggiungere gli utenti alla policy di trust del ruolo se lavorano su un solo progetto e in un solo team.
1. Creare la seguente policy gestita dal cliente denominata `access-assume-role`. Per ulteriori informazioni sulla creazione della policy JSON, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start).
**Policy ABAC: assumere qualsiasi ruolo ABAC, ma solo quando i tag utente e ruolo corrispondono**
La policy seguente consente a un utente di assumere qualsiasi ruolo nell'account con il prefisso `access-` nel nome. Il ruolo deve inoltre essere taggato con gli stessi tag di progetto, team e centro di costi dell'utente.
Per utilizzare questa policy, sostituisci il *testo segnaposto in corsivo* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/access-*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
```
------
Per ridimensionare questa esercitazione a un numero elevato di utenti, è possibile collegare la policy a un gruppo e aggiungere ogni utente al gruppo. Per ulteriori informazioni, consultare [Creare gruppi IAM](id_groups_create.md) e [Modificare gli utenti nei gruppi IAM](id_groups_manage_add-remove-users.md).
1. Creare i seguenti utenti IAM e collegare la policy di autorizzazione `access-assume-role`. Assicurarsi di selezionare **Fornire l'accesso agli utenti a Console di gestione AWS**, poi aggiungere i seguenti tag.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Fase 2: creazione della policy ABAC
Creare la seguente policy denominata **access-same-project-team**. Questa policy verrà aggiunta ai ruoli in un passaggio successivo. Per ulteriori informazioni sulla creazione della policy JSON, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start).
Per ulteriori policy che è possibile adattare a questa esercitazione, vedere le pagine seguenti:
+ [Controllo dell'accesso per i principali IAM](access_iam-tags.md#access_iam-tags_control-principals)
+ [Amazon EC2: consente l'avvio o l'arresto di istanze EC2 che un utente ha contrassegnato, a livello programmatico e nella console](reference_policies_examples_ec2_tag-owner.md)
+ [EC2: avvio o arresto di istanze in base alla corrispondenza dei tag della risorsa e del principale](reference_policies_examples_ec2-start-stop-match-tags.md)
+ [EC2: avvia o interrompe le istanze in base ai tag](reference_policies_examples_ec2-start-stop-tags.md)
+ [IAM: assumere ruoli che dispongono di un tag specifico](reference_policies_examples_iam-assume-tagged-role.md)
**Policy ABAC: accesso alle risorse di Secrets Manager solo quando il tag del principale e quello della risorsa corrispondono**
La policy seguente consente ai principali di creare, leggere, modificare ed eliminare risorse, ma solo quando tali risorse sono contrassegnate con le stesse coppie chiave-valore del principale. Quando un principale crea una risorsa, deve aggiungere i tag `access-project`, `access-team` e `cost-center` con valori corrispondenti ai tag del principale. La policy consente anche l'aggiunta di tag facoltativi `Name` o `OwnedBy`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
},
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}
```
------
**Che cosa fa questa policy?**
+ L'istruzione `AllActionsSecretsManagerSameProjectSameTeam` consente tutte le operazioni relative a questo servizio su tutte le risorse correlate, ma solo se i tag di risorsa corrispondono ai tag del principale. Aggiungendo `"Action": "secretsmanager:*"` alla policy, la policy stessa cresce man mano che Secrets Manager cresce. Se Secrets Manager aggiunge una nuova operazione API, non è necessario aggiungere tale operazione all'istruzione. L'istruzione implementa ABAC utilizzando tre blocchi di condizione. La richiesta è consentita solo se tutti e tre i blocchi restituiscono true.
+ Il primo blocco di condizione di questa istruzione restituisce true se le chiavi tag specificate sono presenti nella risorsa e i loro valori corrispondono ai tag del principale. Questo blocco restituisce false per i tag non corrispondenti o per le operazioni che non supportano il tag delle risorse. Per sapere quali azioni non sono consentite da questo blocco, vedi [Azioni, risorse e chiavi di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html) per. Gestione dei segreti AWS Questa pagina mostra che le operazioni eseguite sul [tipo di risorsa **Segreto**](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) supportano la chiave di condizione `secretsmanager:ResourceTag/tag-key`. Alcune [azioni di Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) non supportano tale tipo di risorsa, inclusi `GetRandomPassword` e `ListSecrets`. Per consentire tali azioni, è necessario creare istruzioni aggiuntive.
+ Il secondo blocco di condizione restituisce true se ogni chiave del tag passata nella richiesta è incluso nell'elenco specificato. Questo viene fatto utilizzando `ForAllValues` con l'operatore condizionale `StringEquals`. Se non vengono passate chiavi o un sottoinsieme del set di chiavi, la condizione restituisce true. Ciò consente operazioni `Get*` che non consentono il passaggio di tag nella richiesta. Se il richiedente include una chiave del tag che non è nell'elenco, la condizione restituisce false. Ogni chiave dei tag passata nella richiesta deve corrispondere a un elemento di tale elenco. Per ulteriori informazioni, consulta [Operatori dell’insieme per le chiavi di contesto multivalore](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ Il terzo blocco di condizioni restituisce true se la richiesta supporta il passaggio dei tag, se tutti e tre i tag sono presenti e se corrispondono ai valori del tag del principale. Questo blocco restituisce true anche se la richiesta non supporta il passaggio di tag. Tale risultato è ottenuto tramite l'utilizzo di [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) nell'operatore condizionale. Il blocco restituisce false se non vi è alcun tag passato durante un'operazione che li supporta o se le chiavi e i valori dei tag non corrispondono.
+ L'istruzione `AllResourcesSecretsManagerNoTags` permette le operazioni `GetRandomPassword` e `ListSecrets` che non sono consentite dalla prima istruzione.
+ L'istruzione `ReadSecretsManagerSameTeam` permette le operazioni di sola lettura se il principale è contrassegnato con lo stesso tag di team di accesso della risorsa. Ciò è consentito indipendentemente dal progetto o dal tag del centro di costi.
+ L'istruzione `DenyUntagSecretsManagerReservedTags` rifiuta le richieste di rimuovere da Secrets Manager i tag con chiavi che iniziano con il prefisso "access-". Questi tag vengono utilizzati per controllare l'accesso alle risorse, pertanto la rimozione dei tag potrebbe rimuovere le autorizzazioni.
+ L'istruzione `DenyPermissionsManagement` nega l'accesso per creare, modificare o eliminare policy basate sulle risorse di Secrets Manager. Queste policy possono essere utilizzate per modificare le autorizzazioni dei segreti.
**Importante**
Questa policy utilizza una strategia per consentire tutte le operazioni per un servizio, ma negando esplicitamente le operazioni di modifica delle autorizzazioni. Il rifiuto di un'operazione sostituisce qualsiasi altra policy che consente al principale di eseguire tale operazione. Ciò può avere risultati imprevisti. Come best practice, usare il rifiuto esplicito solo quando non vi è alcuna circostanza in cui debba essere consentita tale operazione. In caso contrario, consentire un elenco di singole operazioni in modo che le operazioni indesiderate vengano negate per impostazione predefinita.
## Fase 3: creazione di ruoli
Crea i seguenti ruoli IAM e collega la policy **access-same-project-team** creata nella fase precedente. Per ulteriori informazioni sulla creazione dei ruoli IAM, consulta [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md). Se decidi di utilizzare la federazione anziché gli utenti e i ruoli IAM, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md).
| Funzione processo | Nome ruolo | Tag di ruolo | Descrizione del ruolo |
| --- | --- | --- | --- |
| Progetto Pegasus Engineering | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | Consente agli ingegneri di leggere tutte le risorse ingegneristiche e di creare e gestire le risorse ingegneristiche di Pegasus. |
| Progetto Pegasus Quality Assurance | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | Consente al team QA di leggere tutte le risorse di QA e di creare e gestire tutte le risorse QA di Pegasus. |
| Progetto Unicorn Engineering | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | Consente agli ingegneri di leggere tutte le risorse ingegneristiche e creare e gestire le risorse ingegneristiche di Unicorn. |
| Progetto Unicorn Quality Assurance | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | Consente al team QA di leggere tutte le risorse QA e di creare e gestire tutte le risorse QA di Unicorn. |
## Fase 4: verifica della creazione di segreti
La policy di autorizzazione collegata ai ruoli consente ai dipendenti di creare segreti. Questo è consentito solo se il segreto è contrassegnato con il relativo progetto, team e centro di costi. Verifica che le autorizzazioni funzionino come previsto accedendo come i tuoi utenti, assumendo il ruolo corretto e testando l'attività in Secrets Manager.
**Per testare la creazione di un segreto con e senza i tag richiesti**
1. Nella finestra principale del browser, resta connesso come utente amministratore in modo da poter esaminare utenti, ruoli e policy in IAM. Utilizzare una finestra di navigazione in incognito del browser o un browser separato per i test. Lì, accedi come utente `access-Arnav-peg-eng` IAM e apri la console Secrets Manager all'indirizzo [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).
1. Provare a passare al ruolo `access-uni-engineering`.
Questa operazione ha esito negativo perché i valori de tag `access-project` e `cost-center` non corrispondono all'utente `access-Arnav-peg-eng` e al ruolo `access-uni-engineering`.
Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, consulta [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md)
1. Passare al ruolo `access-peg-engineering`.
1. Archiviare un nuovo segreto utilizzando le seguenti informazioni. Per informazioni su come archiviare un segreto, consulta [Creazione di un segreto di base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.
**Importante**
Secrets Manager visualizza avvisi che segnalano che non disponi delle autorizzazioni per i servizi AWS aggiuntivi che funzionano con Secrets Manager. Ad esempio, per creare credenziali per un database Amazon RDS, è necessario disporre dell'autorizzazione per descrivere istanze RDS, cluster RDS e cluster Amazon Redshift. Puoi ignorare questi avvisi poiché non stai utilizzando questi AWS servizi specifici in questo tutorial.
1. Nella sezione **Seleziona tipo di segreto**, scegliere **Altro tipo di segreti**. Nelle due caselle di testo, inserire `test-access-key` e `test-access-secret`.
1. Nel campo **Nome segreto** inserire il valore `test-access-peg-eng`.
1. Aggiungere diverse combinazioni di tag dalla tabella seguente e visualizzare il comportamento previsto.
1. Scegliere **Memorizza** per provare a creare il segreto. Se l'archiviazione non riesce, torna alle pagine della console di Secrets Manager precedenti e utilizza il set di tag successivo dalla tabella seguente. L'ultimo set di tag è consentito e creerà con successo il segreto.
La tabella seguente mostra le combinazioni di tag ABAC per il ruolo `test-access-peg-eng`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. Disconnettersi e ripetere i primi tre passaggi di questa procedura per ciascuno dei seguenti ruoli e valori dei tag. Nel quarto passaggio di questa procedura, verificare tutti i set di tag mancanti, tag facoltativi, tag non consentiti e valori di tag non validi selezionati. Quindi utilizzare i tag richiesti per creare un segreto con i seguenti tag e nome.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Fase 5: verifica della visualizzazione dei segreti
La policy collegata a ciascun ruolo consente ai dipendenti di visualizzare eventuali segreti contrassegnati con il nome del team, indipendentemente dal progetto. Verifica che le autorizzazioni funzionino come previsto testando i ruoli in Secrets Manager.
**Per testare la visualizzazione di un segreto con e senza i tag richiesti**
1. Accedi come uno dei seguenti utenti IAM:
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
1. Passa al ruolo corrispondente:
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-uni-quality-assurance`
Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, vedere. [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md)
1. Nel riquadro di navigazione a sinistra, scegli l'icona del menu per espanderlo, quindi scegliere **Segreti**.
1. Dovrebbero essere visualizzati tutti e quattro i segreti nella tabella, indipendentemente dal proprio ruolo attuale. Ciò accade perché la policy denominata `access-same-project-team` consente l'operazione `secretsmanager:ListSecrets` per tutte le risorse.
1. Scegli il nome di uno dei segreti.
1. Nella pagina dei dettagli del segreto, i tag del ruolo determinano se è possibile visualizzare il contenuto della pagina. Confrontare il nome del proprio ruolo con il nome del segreto. Se condividono lo stesso nome del team, i tag `access-team` corrispondono. Se non corrispondono, l'accesso viene negato.
La tabella seguente mostra il comportamento di visualizzazione del segreto ABAC per ogni ruolo.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. Nel percorso di navigazione nella parte superiore della pagina, scegliere **Segreti** per tornare all'elenco dei segreti. Ripetere i passaggi di questa procedura utilizzando ruoli diversi per verificare se è possibile visualizzare ciascuno dei segreti.
## Fase 6: verifica della scalabilità
Un motivo importante per utilizzare il controllo degli accessi basato su attributi (ABAC) invece del controllo di accesso basato su ruoli (RBAC) è la scalabilità. Man mano che l'azienda aggiunge nuovi progetti, team o persone AWS, non è necessario aggiornare le politiche basate su ABAC. Ad esempio, si supponga che Example Company stia finanziando un nuovo progetto dal nome in codice **Centaur**. Un ingegnere di nome Saanvi Sarkar sarà l'ingegnere responsabile di **Centaur** continuando a lavorare al progetto **Unicorn** . Saanvi esaminerà anche i lavori per il progetto **Peg**. Ci sono anche diversi ingegneri appena assunti, tra cui Nikhil Jayashankar, che lavoreranno solo al progetto **Centaur** .
**Per aggiungere il nuovo progetto a AWS**
1. Accedi come utente amministratore IAM e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione sulla sinistra, scegli **Ruoli** e aggiungi un ruolo IAM denominato `access-cen-engineering`. Collega la policy delle autorizzazioni **access-same-project-team** al ruolo e aggiungere i seguenti tag di ruolo:
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. Nel riquadro di navigazione sinistro, scegli **Utenti**.
1. Aggiungi un nuovo utente denominato `access-Nikhil-cen-eng`, collega la policy denominata `access-assume-role` e aggiungi i seguenti tag utente.
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. Utilizza le procedure in [Fase 4: verifica della creazione di segreti](#tutorial_abac_step4) e [Fase 5: verifica della visualizzazione dei segreti](#tutorial_abac_step5). In un'altra finestra del browser, verifica che Nikhil possa creare segreti solo per il team di ingegneria di **Centaur** e che possa visualizzare tutti i segreti dei team di ingegneria.
1. Nella finestra principale del browser in cui hai effettuato l'accesso come amministratore, scegli l'utente `access-Saanvi-uni-eng`.
1. Nella scheda **Autorizzazioni**, rimuovi la politica delle **access-assume-role**autorizzazioni.
1. Aggiungi la seguente policy inline denominata `access-assume-specific-roles`. Per ulteriori informazioni sull'aggiunta di una policy inline a un utente, consulta [Per incorporare una policy inline per un utente o un ruolo (console)](access_policies_manage-attach-detach.md#embed-inline-policy-console).
**Policy ABAC: assunzione dei soli ruoli specifici**
Questa policy consente a Saanvi di assumere i ruoli ingegneristici per i progetti **Pegasus** e **Centaur**. È necessario creare questa policy personalizzata perché IAM non supporta tag multivalore. Non è possibile etichettare l'utente di Saanvi con `access-project` = `peg` e `access-project` = `cen`. Inoltre, il modello di AWS autorizzazione non può corrispondere a entrambi i valori. Per ulteriori informazioni, consulta [Regole per l'etichettatura in IAM e AWS STS](id_tags.md#id_tags_rules). È invece necessario specificare manualmente i due ruoli che può assumere.
Per utilizzare questa policy, sostituisci il *testo segnaposto in corsivo* con le tue informazioni.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/access-peg-engineering",
"arn:aws:iam::111122223333:role/access-cen-engineering"
]
}
]
}
```
------
1. Utilizza le procedure in [Fase 4: verifica della creazione di segreti](#tutorial_abac_step4) e [Fase 5: verifica della visualizzazione dei segreti](#tutorial_abac_step5). In un'altra finestra del browser, conferma che Saanvi possa assumere entrambi i ruoli. Verifica che sia in grado di creare segreti solo per i suoi progetto, team e centro di costo, a seconda dei tag del ruolo. Verifica anche che possa visualizzare i dettagli su eventuali segreti di proprietà del team di ingegneria, inclusi quelli che ha appena creato.
## Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti
La policy `access-same-project-team` collegata ai ruoli consente ai dipendenti di aggiornare ed eliminare eventuali segreti contrassegnati con il proprio progetto, team e centro costi. Verifica che le autorizzazioni funzionino come previsto testando i ruoli in Secrets Manager.
**Per verificare l'aggiornamento e l'eliminazione di un segreto con e senza i tag richiesti**
1. Accedi come uno dei seguenti utenti IAM:
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
+ `access-Nikhil-cen-eng`
1. Passa al ruolo corrispondente:
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-peg-quality-assurance`
+ `access-cen-engineering`
Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, vedere[Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md).
1. Per ogni ruolo, prova ad aggiornare la descrizione del segreto e quindi prova a eliminare i seguenti segreti. Per ulteriori informazioni, consulta [Modifica di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) ed [Eliminazione e ripristino di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *.
La seguente tabella riporta il comportamento di aggiornamento ed eliminazione dei segreti ABAC per ogni ruolo.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Riepilogo
Tutte le fasi necessarie per utilizzare i tag per il controllo degli accessi basato su attributi (ABAC) sono state completate correttamente. L'utente ha imparato a definire una strategia di tagging. Tale strategia è stata applicata alle proprie entità e risorse. È stata creata e applicata una policy che impone la strategia a Secrets Manager. L'utente ha anche imparato che ABAC è facilmente ridimensionabile nel momento in cui si aggiungono nuovi progetti e membri del team. Di conseguenza, sarai in grado di accedere alla console IAM con i ruoli di test e scoprire come utilizzare i tag per ABAC in AWS.
**Nota**
L'utente ha aggiunto policy che consentono operazioni solo in condizioni specifiche. Se si applica un criterio diverso agli utenti o ai ruoli con autorizzazioni più ampie, è possibile che le azioni non siano limitate a richiedere l'assegnazione di tag. Ad esempio, se concedi a un utente autorizzazioni amministrative complete utilizzando la politica `AdministratorAccess` AWS gestita, tali politiche non limiteranno tale accesso. Per ulteriori informazioni su come vengono determinate le autorizzazioni quando sono coinvolte più policy, vedere [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
## Risorse correlate
Per informazioni correlate, consulta le seguenti risorse:
+ [Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC](introduction_attribute-based-access-control.md)
+ [AWS chiavi di contesto della condizione globale](reference_policies_condition-keys.md)
+ [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md)
+ [Tag per AWS Identity and Access Management le risorse](id_tags.md)
+ [Controllo dell'accesso alle AWS risorse tramite tag](access_tags.md)
+ [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md)
+ [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md)
Per sapere come monitorare i tag nel tuo account, consulta [Monitorare le modifiche ai tag sulle AWS risorse con flussi di lavoro serverless e Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/).
# Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC
Il controllo dell’accesso basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. In AWS, questi attributi sono chiamati tag. Puoi allegare tag alle risorse IAM, incluse le entità IAM (utenti o ruoli) e alle AWS risorse. Quando le entità vengono utilizzate per effettuare richieste a AWS, diventano principali e tali entità includono i tag.
È inoltre possibile passare i [tag di sessione](id_session-tags.md) quando si assume un ruolo o si federa un utente. È quindi possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni alle entità sulla base dei relativi tag. Quando si utilizzano i tag per controllare l'accesso alle risorse AWS , si consente ai team e alle risorse di crescere con la necessità di un minor numero di modifiche alle policy AWS . Le politiche ABAC sono più flessibili delle AWS politiche tradizionali, che richiedono di elencare ogni singola risorsa. Per ulteriori informazioni su ABAC e i suoi vantaggi rispetto alle policy tradizionali, consulta [Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC](introduction_attribute-based-access-control.md).
Se, per gestire le identità degli utenti aziendali, l'azienda utilizza un provider di identità basato su SAML (IdP) è possibile utilizzare gli attributi SAML per il controllo degli accessi AWS a granularità fine. Gli attributi possono includere identificatori del centro di costo, indirizzi e-mail degli utenti, reparti di appartenenza e assegnazioni di progetto. Quando si passano questi attributi come tag di sessione, è quindi possibile controllare l'accesso ad AWS in base a tali tag di sessione.
Per completare l'[esercitazione su ABAC](tutorial_attribute-based-access-control.md) passando gli attributi SAML all'entità sessione, completare le attività descritte in [Tutorial IAM: definisci le autorizzazioni per accedere alle AWS risorse in base ai tag](tutorial_attribute-based-access-control.md), con le modifiche incluse in questa sezione.
## Prerequisiti
Per eseguire la procedura che prevede l'utilizzo dei tag di sessione SAML per ABAC, è necessario disporre preventivamente quanto segue:
+ Accesso a un IdP basato su SAML in cui è possibile creare utenti di test con attributi specifici.
+ La possibilità di effettuare l'accesso come utente con autorizzazioni di amministratore.
+ Creazione e modifica di utenti, ruoli e policy IAM nella Console di gestione AWS. Tuttavia, se hai bisogno di aiuto per ricordare un processo di gestione IAM, il tutorial ABAC fornisce collegamenti in cui puoi visualizzare le istruzioni. step-by-step
+ Completa la configurazione di un IdP basato su SAML in IAM. Per visualizzare maggiori dettagli e i collegamenti alla documentazione IAM dettagliata, consulta [Passaggio dei tag di sessione tramite SAML AssumeRoleWith](id_session-tags.md#id_session-tags_adding-assume-role-saml).
## Fase 1: creazione degli utenti di test
Seguire le istruzioni in [Fase 1: creazione degli utenti di test](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Poiché le identità sono definite dal provider, non è necessario aggiungere gli utenti IAM per i propri dipendenti.
## Fase 2: creazione della policy ABAC
Per creare la policy gestita specificata in IAM, seguire le istruzioni riportate in [Fase 2: creazione della policy ABAC](tutorial_attribute-based-access-control.md#tutorial_abac_step2).
## Fase 3: creazione e configurazione del ruolo SAML
Quando utilizzi il tutorial ABAC per SAML, devi eseguire passaggi aggiuntivi per creare il ruolo, configurare l'IdP SAML e abilitare l'accesso. Console di gestione AWS Per ulteriori informazioni, consulta [Fase 3: creazione di ruoli](tutorial_attribute-based-access-control.md#tutorial_abac_step3).
### Fase 3A: creazione del ruolo SAML
Creare un singolo ruolo in relazione di trust con il provider di identità SAML e l'utente `test-session-tags` creato nel passaggio 1. L'esercitazione ABAC utilizza ruoli separati con diversi tag di ruolo. Poiché si stanno passando i tag di sessione dal proprio IdP SAML, c'è bisogno di un solo ruolo. Per informazioni su come creare un ruolo basato su SAML, consulta [Creare un ruolo per una federazione SAML 2.0 (console)](id_roles_create_for-idp_saml.md).
Denomina il ruolo `access-session-tags`. Collegare la policy di autorizzazione `access-same-project-team` al ruolo. Modificare la policy di trust al fine di utilizzare la policy riportata di seguito. Per istruzioni dettagliate su come modificare la relazione di trust di un ruolo, consulta [Aggiornamento di una policy di attendibilità del ruolo](id_roles_update-role-trust-policy.md).
La seguente policy di trust del ruolo consente al provider di identità SAML e all'utente `test-session-tags` di assumere il ruolo. Al momento dell'assunzione del ruolo, è necessario passare i tre tag di sessione specificati. L'operazione `sts:TagSession` è necessaria per consentire il passaggio dei tag di sessione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSamlIdentityAssumeRole",
"Effect": "Allow",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
"Condition": {
"StringLike": {
"aws:RequestTag/cost-center": "*",
"aws:RequestTag/access-project": "*",
"aws:RequestTag/access-team": [
"eng",
"qas"
]
},
"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
```
------
La `AllowSamlIdentityAssumeRole` dichiarazione consente ai membri dei team di ingegneria e controllo qualità di assumere questo ruolo quando si uniscono all'Example Corporation AWS IdP. Il provider SAML `ExampleCorpProvider` è definito in IAM. L'amministratore ha già impostato l'asserzione SAML per passare i tre tag di sessione richiesti. L'asserzione può passare tag aggiuntivi, ma questi tre devono essere presenti. Gli attributi dell'identità possono presentare qualsiasi valore per i tag `access-project` e `cost-center`. Tuttavia, il valore dell'attributo `access-team` deve corrispondere a `eng` o `qas` a indicare che l'identità corrisponde al team di Engineering o di Quality Assurance.
### Passaggio 3B: configurazione dell'IdP SAML
Configurare l'IdP SAML affinché passi gli attributi `cost-center`, `access-project` e `access-team` come tag di sessione. Per ulteriori informazioni, consulta [Passaggio dei tag di sessione tramite SAML AssumeRoleWith](id_session-tags.md#id_session-tags_adding-assume-role-saml).
Per passare questi attributi come tag di sessione, includere i seguenti elementi nell'asserzione SAML.
```
987654
peg
eng
```
### Fase 3C: attivazione dell'accesso alla console
Abilita l'accesso alla console per gli utenti SAML federati. Per ulteriori informazioni, consulta [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md).
## Fase 4: verifica della creazione di segreti
Unisciti all'utilizzo del ruolo. Console di gestione AWS `access-session-tags` Per ulteriori informazioni, consulta [Consentire ai principali federati SAML 2.0 di accedere a Console di gestione AWS](id_roles_providers_enable-console-saml.md). Quindi seguire le istruzioni in [Fase 4: verifica della creazione di segreti](tutorial_attribute-based-access-control.md#tutorial_abac_step4) per creare segreti. Utilizzare diverse identità SAML con attributi da abbinare ai tag indicati nell'esercitazione ABAC. Per ulteriori informazioni, consulta [Fase 4: verifica della creazione di segreti](tutorial_attribute-based-access-control.md#tutorial_abac_step4).
## Fase 5: verifica della visualizzazione dei segreti
Seguire le istruzioni descritte in [Fase 5: verifica della visualizzazione dei segreti](tutorial_attribute-based-access-control.md#tutorial_abac_step5) per visualizzare i segreti creati nel passaggio precedente. Utilizzare diverse identità SAML con attributi da abbinare ai tag indicati nell'esercitazione ABAC.
## Fase 6: verifica della scalabilità
Seguire le istruzioni descritte in [Fase 6: verifica della scalabilità](tutorial_attribute-based-access-control.md#tutorial_abac_step6) per testare la scalabilità. Eseguire questa operazione aggiungendo una nuova identità nel proprio IdP basato su SAML con i seguenti attributi:
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`
## Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti
Seguire le istruzioni descritte in [Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti](tutorial_attribute-based-access-control.md#tutorial_abac_step7) per aggiornare ed eliminare i segreti. Utilizzare diverse identità SAML con attributi da abbinare ai tag indicati nell'esercitazione ABAC.
**Importante**
Eliminare tutti i segreti creati per evitare addebiti in fattura. Per informazioni sui prezzi di Secrets Manager, consulta [Prezzi di Gestione dei segreti AWS](https://aws.amazon.com/secrets-manager/pricing/).
## Riepilogo
Sono stati completati tutti i passaggi necessari per utilizzare i tag di sessione SAML e i tag delle risorse per la gestione delle autorizzazioni.
**Nota**
L'utente ha aggiunto policy che consentono operazioni solo in condizioni specifiche. Se si applica un criterio diverso agli utenti o ai ruoli con autorizzazioni più ampie, è possibile che le azioni non siano limitate a richiedere l'assegnazione di tag. Ad esempio, se concedi a un utente autorizzazioni amministrative complete utilizzando la policy `AdministratorAccess` AWS gestita, queste politiche non limiteranno tale accesso. Per ulteriori informazioni su come vengono determinate le autorizzazioni quando sono coinvolte più policy, vedere [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md).
# Tutorial IAM: consentire agli utenti di gestire le proprie credenziali e impostazioni MFA
Puoi consentire agli utenti di gestire i loro dispositivi e le credenziali di autenticazione a più fattori (MFA) nella pagina **Credenziali di sicurezza**. Puoi utilizzarlo Console di gestione AWS per configurare le credenziali (chiavi di accesso, password, certificati di firma e chiavi pubbliche SSH), eliminare o disattivare le credenziali non necessarie e abilitare i dispositivi MFA per i tuoi utenti. Sebbene sia utile per un numero ridotto di utenti, è un'operazione che potrebbe richiedere molto tempo se il numero di utenti cresce. Mostrare come abilitare queste best practice senza sovraccaricare gli amministratori è l'obiettivo di questo tutorial.
Questo tutorial mostra come consentire agli utenti di accedere ai AWS servizi, ma **solo** quando accedono con MFA. Se non sono registrati con un dispositivo MFA, gli utenti non possono accedere ad altri servizi.
Questo flusso di lavoro ha tre fasi di base.
**[Fase 1: creazione di una policy per applicare l'accesso MFA](#tutorial_mfa_step1)**
Crea una policy gestita dal cliente che impedisce tutte le azioni ***eccetto*** le poche operazioni IAM. Queste eccezioni consentono a un utente di modificare le sue credenziali e gestire i dispositivi MFA nella pagina **Credenziali di sicurezza**. Per ulteriori informazioni sull'accesso alla pagina, consulta [Come gli utenti IAM possono cambiare le proprie password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**[Fase 2: Collegamento delle policy al gruppo di utenti di test](#tutorial_mfa_step2)**
Crea un gruppo di utenti i cui membri hanno accesso completo a tutte le operazioni Amazon EC2 se effettuano l'accesso con MFA. Per creare un gruppo di utenti di questo tipo, alleghi sia la politica AWS gestita richiamata `AmazonEC2FullAccess` sia la politica gestita dai clienti che hai creato nel primo passaggio.
**[Fase 3: test dell'accesso dell'utente](#tutorial_mfa_step3)**
Accedi come utente di prova per verificare che l'accesso ad Amazon EC2 sia bloccato *fino* a quando l'utente non crea un dispositivo MFA. L'utente può quindi accedere utilizzando tale dispositivo.
## Prerequisiti
Per eseguire queste fasi in questo tutorial, è necessario quanto segue:
+ E a Account AWS cui puoi accedere come utente IAM con autorizzazioni amministrative.
+ Il numero ID dell'account, che si digita nella policy nella Fase 1.
Per trovare il numero ID dell'account nella barra di navigazione in alto sulla pagina, selezionare **Support (Supporto)** e selezionare **Support Center (Centro di supporto)**. Puoi trovare l'ID dell'account nel menu **Supporto** di questa pagina.
+ Un [dispositivo MFA virtuale (basato su software)](id_credentials_mfa_enable_virtual.md), una [chiave di sicurezza FIDO](id_credentials_mfa_enable_fido.md) o un [dispositivo MFA basato su hardware](id_credentials_mfa_enable_physical.md).
+ Un utente IAM di prova che è membro di un gruppo come segue:
| Nome utente | Istruzioni per il nome utente | Nome gruppo di utenti | Aggiungere utente come un membro | Istruzioni per il gruppo di utenti |
| --- | --- | --- | --- | --- |
| MFAUser | Seleziona solo l'opzione per Enable console access – optional (Abilita , l'accesso alla console - facoltativo) e assegna una password. | EC2MFA | MFAUser | NON collegare policy o concedere autorizzazioni a questo gruppo di utenti. |
## Fase 1: creazione di una policy per applicare l'accesso MFA
Per iniziare, crea una policy gestita dal cliente IAM che nega tutte le autorizzazioni tranne quelle richieste per gli utenti IAM per gestire le credenziali e i dispositivi MFA.
1. Accedi alla console di AWS gestione come utente con credenziali di amministratore. Per aderire alle best practice di IAM, non accedere con le tue Utente root dell'account AWS credenziali.
**Importante**
[Le migliori pratiche](best-practices.md) IAM consigliano di richiedere agli utenti umani di utilizzare la federazione con un provider di identità per accedere AWS utilizzando credenziali temporanee anziché utilizzare utenti IAM con credenziali a lungo termine. Ti consigliamo di utilizzare gli utenti IAM solo per [casi d'uso specifici](gs-identities-iam-users.md) non supportati dagli utenti federati.
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione, scegli **Policy** e **Crea policy**.
1. Selezionare la scheda **JSON** e copiare il testo dal documento della seguente policy JSON: [AWS: consente agli utenti IAM autenticati con MFA di gestire le proprie credenziali nella pagina Credenziali di sicurezza](reference_policies_examples_aws_my-sec-creds-self-manage.md).
1. Incolla il testo della policy nella casella di testo **JSON**. Risolvi eventuali avvisi di sicurezza, errori o avvertenze generali generati durante la convalida delle policy, quindi scegli **Successivo**.
**Nota**
È possibile alternare le opzioni dell'editor **Visivo** e **JSON** in qualsiasi momento. Tuttavia, la policy qui sopra include l'elemento `NotAction`, che non è supportato nell'editor visivo. Per questa policy, verrà visualizzata una notifica nella scheda **Visual Editor (Editor visivo)**. Torna alla scheda **JSON** per continuare a lavorare con questa policy.
Questo esempio di policy non consente agli utenti di reimpostare la password durante il primo accesso a Console di gestione AWS . Ti consigliamo di non concedere autorizzazioni ai nuovi utenti fino a quando non hanno effettuato l'accesso e reimpostato la password.
1. Nella pagina **Verifica policy**, digita **Force\$1MFA** come nome della policy. Per la descrizione della policy, digita **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.**. Nell'area **Tag**, puoi facoltativamente aggiungere coppie chiave-valore di tag alla policy gestita dal cliente. Esamina le autorizzazioni concesse dalla policy, quindi scegli **Crea policy** per salvare il lavoro.
La nuova policy appare nell'elenco delle policy gestite ed è pronta a collegare.
## Fase 2: Collegamento delle policy al gruppo di utenti di test
In seguito collega le due policy al gruppo di utenti IAM di test, che verrà utilizzato per concedere le autorizzazioni protette mediante MFA.
1. Nel pannello di navigazione seleziona **Gruppi di utenti**.
1. Nella casella di ricerca digita **`EC2MFA`** e seleziona il nome del gruppo (non la casella di controllo) nell'elenco.
1. Nella scheda **Permissions** (Autorizzazioni), scegli **Add permissions** (Aggiungi autorizzazioni), quindi **Attach policies** (Collega policy).
1. Nella pagina **Allega criteri di autorizzazione al gruppo EC2 MFA**, nella casella di ricerca, digitare. **EC2Full** Quindi seleziona la casella di controllo accanto ad **Amazon EC2 FullAccess** nell'elenco. Non salvare ancora le modifiche.
1. Nella casella di ricerca, digita **Force** e seleziona la casella di controllo accanto a **Force\$1MFA** nell'elenco.
1. Scegli **Collega policy**.
## Fase 3: test dell'accesso dell'utente
In questa parte del tutorial, effettuare l'accesso come utente di prova e verificare che la policy funzioni correttamente.
1. Accedi al tuo annuncio **MFAUser** con Account AWS la password che hai assegnato nella sezione precedente. Utilizzare l'URL: `https://.signin.aws.amazon.com/console`
1. Seleziona **EC2** per aprire la console Amazon EC2 e verifica che l'utente non disponga di autorizzazioni per effettuare alcuna operazione.
1. Selezionare il nome utente `MFAUser` in alto a destra nella barra di navigazione e scegli **Security Credentials** (Credenziali di sicurezza).
![\[AWS Link alle credenziali di sicurezza della console di gestione.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)
1. Aggiungere un dispositivo MFA. Nella sezione **Multi-Factor Authentication (MFA) (Autenticazione a più fattori)**, scegliere **Assign MFA device (Assegna dispositivo MFA)**.
**Nota**
Potrebbe essere visualizzato un errore che indica che non si è autorizzati a eseguire `iam:DeleteVirtualMFADevice`. Questo può accadere se qualcuno in precedenza ha iniziato ad assegnare un dispositivo MFA virtuale a questo utente e ha annullato il processo. Per continuare, l'utente o un altro amministratore devono eliminare il dispositivo MFA virtuale esistente non assegnato dell'utente. Per ulteriori informazioni, consulta [Non sono autorizzato a eseguire: iam: DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).
1. Per questo tutorial, utilizziamo un dispositivo MFA (basato su software), ad esempio Google Authenticator app su un cellulare. Scegli **l'app Authenticator**, quindi fai clic su **Next** (Successivo).
IAM genera e visualizza le informazioni di configurazione per il dispositivo MFA virtuale, tra cui il codice grafico QR. Il grafico è una rappresentazione della chiave di configurazione segreta che è disponibile per l'inserimento manuale su dispositivi che non supportano i codici QR.
1. Aprire l'app MFA virtuale. (Per un elenco di app che si possono utilizzare per ospitare dispositivi MFA virtuali, consulta [Applicazioni MFA virtuali](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications).) Se l'app MFA virtuale supporta più account (più dispositivi MFA virtuali), selezionare l'opzione che consente di creare un nuovo account (un nuovo dispositivo virtuale MFA).
1. Determinare se l'app MFA supporta i codici QR e procedere in uno dei seguenti modi:
+ Nella procedura guidata, scegliere **Show QR code (Mostra codice QR)**. Quindi utilizzare l'app per la scansione del codice QR. Ad esempio, è possibile selezionare l'icona della fotocamera o un'opzione simile a **Scannerizza codice** ed eseguire la scansione del codice tramite la fotocamera del dispositivo.
+ Nella procedura guidata **Set up device** (Configura dispositivo), scegli **Show secret key** (Mostra chiave segreta) e digita la chiave segreta nell'app MFA.
Al termine, il dispositivo MFA virtuale avvia la generazione di password una tantum.
1. Nella procedura guidata **Set up device** (Configura dispositivo), nella casella **Enter the code from your authenticator app** (Immetti il codice dall'app di autenticazione), digita la password una tantum che appare nel dispositivo MFA virtuale. Scegli **Register MFA** (Registra MFA).
**Importante**
Invia la richiesta immediatamente dopo la generazione del codice. Se si generano i codici e si attende troppo a lungo per inviare la richiesta, il dispositivo MFA è correttamente associato all'utente. Tuttavia, il dispositivo MFA non è sincronizzato. Ciò accade perché le password monouso temporanee (TOTP) scadono dopo un breve periodo di tempo. Se ciò accade, è possibile [sincronizzare nuovamente il dispositivo](id_credentials_mfa_sync.md).
Il dispositivo MFA virtuale è ora pronto per l'uso con. AWS
1. Uscire dalla console ed effettuare nuovamente l'accesso come **MFAUser** Questa volta AWS ti viene richiesto un codice MFA dal tuo telefono. Una volta ottenuto, digitare il codice nella casella e selezionare **Submit (Invia)**.
1. Seleziona **EC2** per aprire nuovamente la console Amazon EC2. In questo momento è possibile visualizzare tutte le informazioni ed eseguire tutte le azioni desiderate. Se si accede a qualsiasi altra console come questo utente, vengono visualizzati messaggi di accesso negato. Il motivo è che le policy in questo tutorial concedono l'accesso solo a Amazon EC2.
## Risorse correlate
Per ulteriori informazioni, consulta i seguenti argomenti:
+ [AWS Autenticazione a più fattori in IAM](id_credentials_mfa.md)
+ [Accesso abilitato con MFA](console_sign-in-mfa.md)
# Tutorial IAM: utilizza un CloudFormation modello per creare un provider di identità SAML (IdP)
Per configurare la federazione SAML per il tuo AWS account, devi creare un provider di identità SAML (IdP). Questo tutorial mostra come utilizzare un CloudFormation modello per creare un IdP SAML che stabilisca la fiducia AWS tra e il tuo IdP esterno.
Il modello crea un IdP SAML configurato con il documento di metadati dell’IdP. I ruoli IAM federati possono quindi fare riferimento a questo IdP per consentire agli utenti autenticati del tuo IdP esterno di accedere alle risorse. AWS
La risorsa implementata è costituita da un IdP SAML configurato con il documento di metadati del tuo IdP e impostazioni di crittografia facoltative.
## Prerequisiti
Questo tutorial presuppone che tu abbia a disposizione quanto segue:
+ Python 3.6 o versione successiva installato sul computer locale per eseguire il comando Python utilizzato in questo tutorial per formattare il file XML dei metadati SAML del tuo IdP.
+ Un documento di metadati SAML del tuo IdP esterno salvato come file XML.
## Crea un IdP SAML utilizzando CloudFormation
Per creare l'IdP SAML, creerai CloudFormation un modello e lo utilizzerai per creare uno stack contenente la risorsa IdP.
### Creazione del modello
Innanzitutto, crea il modello. CloudFormation
1. Nella sezione [Modello](#tutorial_saml-idp-template), fai clic sull’icona di copia nella scheda **JSON** o **YAML** per copiare i contenuti del modello.
1. Copia i contenuti del modello in un nuovo file.
1. Salva il file localmente.
### Creazione dello stack
Quindi, usa il modello che hai salvato per effettuare il provisioning di uno CloudFormation stack.
1. Apri la CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Nella pagina **Stack**, scegli **Con nuove risorse (standard)** nel menu **Crea stack**.
1. Specifica il modello:
1. In **Prerequisito**, seleziona **Scegli un modello esistente**.
1. In **Specifica modello**, seleziona **Carica un file di modello**.
1. Seleziona **Scegli file**, quindi passa al file del modello e selezionalo.
1. Scegli **Next (Successivo)**.
1. Specifica i seguenti dettagli dello stack:
1. Inserisci un nome dello stack.
1. Infatti **IdentityProviderName**, puoi lasciare vuoto questo campo per generare automaticamente un nome basato sul nome dello stack o inserire un nome personalizzato per il tuo IdP SAML. I nomi personalizzati devono contenere solo caratteri alfanumerici, punti, trattini bassi e trattini.
1. Per **IdentityProviderSAMLMetadataDocument**, devi formattare il file XML dei metadati SAML come una singola riga prima di incollarlo in questo campo. Ciò è necessario perché la CloudFormation console richiede che il contenuto XML venga formattato come una singola riga quando viene passato attraverso i parametri della console.
Usa il seguente comando Python per riformattare il tuo file XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**Nota**
Il documento di metadati SAML dell’IdP deve essere formattato come una singola riga per poter essere utilizzato come parametro nella console. Il comando Python rimuove le interruzioni di riga e gli spazi bianchi aggiuntivi per creare il formato richiesto, mantenendo però intatti tutti i contenuti e la struttura originali.
Copia l'output dal comando Python e incollalo nel campo **IdentityProviderSAMLMetadataDocumento**.
Esempio di documento di metadati SAML formattato (abbreviato):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Per gli altri parametri, accetta i valori predefiniti o inseriscine altri in base ai tuoi requisiti:
+ **IdentityProviderAddPrivateKey**- Chiave privata opzionale per decifrare le asserzioni SAML
+ **IdentityProviderAssertionEncryptionMode**- Facoltativo, imposta la modalità di crittografia per le asserzioni SAML (consentita, obbligatoria o vuota)
1. Scegli **Next (Successivo)**.
1. Configura le opzioni dello stack:
1. In **Opzioni di errore dello stack**, scegli **Elimina tutte le nuove risorse create**.
**Nota**
Scegliendo questa opzione si evita di ricevere addebiti per risorse la cui policy di eliminazione specifica che devono essere mantenute anche se la creazione dello stack non riesce.
1. Accetta tutti gli altri valori predefiniti.
1. In **Funzionalità**, seleziona la casella per confermare che CloudFormation potresti creare risorse IAM nel tuo account.
1. Scegli **Next (Successivo)**.
1. Rivedi i dettagli dello stack e scegli **Invia**.
CloudFormation crea lo stack. Una volta completata la creazione dello stack, le relative risorse sono pronte per l’uso. Puoi utilizzare la scheda **Risorse** nella pagina dei dettagli dello stack per visualizzare le risorse che sono state fornite nel tuo account.
Lo stack produrrà i seguenti valori, che puoi visualizzare nella scheda **Output**:
+ **ProviderARN**: l’ARN dell’IdP SAML creato (ad esempio, `arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Avrai bisogno di questo ARN per creare ruoli che considerano attendibile questo provider.
+ **ProviderName**: il nome dell'IdP SAML creato (ad esempio`CompanyIdP`, se hai specificato un nome personalizzato `my-saml-stack-saml-provider` o se hai utilizzato la denominazione predefinita).
Questi output vengono anche esportati, consentendone l’importazione da altri stack CloudFormation utilizzando la funzione `Fn::ImportValue`.
## Verifica dell’IdP SAML
Una volta che l’IdP SAML è stato creato, puoi verificarne la configurazione e prendere nota del relativo ARN da utilizzare con i ruoli federati.
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione, scegli **Identity providers** (Provider di identità).
L’elenco dovrebbe mostrare l’IdP SAML appena creato.
1. Scegli il nome dell’IdP per visualizzarne i dettagli.
Nella pagina dei dettagli dell’IdP, puoi vedere il documento di metadati SAML e altri dettagli di configurazione.
1. Prendi nota del **Provider ARN** visualizzato nella pagina dei dettagli.
Avrai bisogno di questo ARN per creare ruoli IAM federati che ritengono attendibile questo IdP.
1. Esamina il documento di metadati per assicurarti che corrisponda a quello che hai fornito dal tuo IdP esterno.
Il tuo IdP SAML è ora pronto per essere utilizzato dai ruoli IAM federati. Puoi creare ruoli che si fidano di questo IdP per consentire agli utenti autenticati del tuo IdP esterno di assumere tali ruoli e accedere alle risorse. AWS
## Pulizia: eliminazione delle risorse
Come passaggio finale, eliminerai lo stack e le risorse in esso contenute.
1. Apri la console. CloudFormation
1. Nella pagina **Stack**, scegli lo stack creato dal modello, poi scegli **Elimina**, quindi conferma con **Elimina**.
CloudFormation avvia l'eliminazione dello stack e di tutte le risorse che include.
## CloudFormation dettagli del modello
### Resources
Il CloudFormation modello di questo tutorial creerà la seguente risorsa nel tuo account:
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP SAML che stabilisce un rapporto di fiducia AWS tra e il tuo IdP esterno.
### Configurazione
Il modello include i seguenti parametri configurabili:
+ **IdentityProviderName**- Il nome del tuo IdP SAML (lascia vuoto il nome generato automaticamente)
Esempio: `CompanyIdP` o `EnterpriseSSO`
+ **IdentityProviderSAMLMetadataDocumento: il documento** di metadati SAML del tuo IdP esterno (formattato come una singola riga)
+ **IdentityProviderAddPrivateKey**- Chiave privata opzionale per decrittografare le asserzioni SAML
+ **IdentityProviderAssertionEncryptionMode**- Facoltativo, imposta la modalità di crittografia per le asserzioni SAML
## CloudFormation modello
Salva il seguente codice JSON o YAML come file separato da utilizzare come CloudFormation modello per questo tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
}
},
"Conditions": {
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]},
"HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"Tags": [
{
"Key": "Name",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}
}
],
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
}
},
"Outputs": {
"ProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"}
}
},
"ProviderName": {
"Description": "Name of the SAML Identity Provider",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens'
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
Conditions:
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]]
Resources:
SAMLProvider:
Type: 'AWS::IAM::SAMLProvider'
Properties:
Name: !If
- HasCustomName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
Tags:
- Key: Name
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
Outputs:
ProviderARN:
Description: 'ARN of the created SAML Identity Provider'
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-ProviderARN'
ProviderName:
Description: 'Name of the SAML Identity Provider'
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
Export:
Name: !Sub '${AWS::StackName}-ProviderName'
```
------
# Tutorial IAM: utilizza un CloudFormation modello per creare un ruolo IAM federato SAML
Se disponi di un provider di identità SAML (IdP) esistente configurato nel AWS tuo account, puoi creare ruoli IAM federati che si fidano di quell'IdP. Questo tutorial mostra come utilizzare un CloudFormation modello per creare un ruolo IAM federato SAML che può essere assunto dagli utenti autenticati tramite il tuo IdP esterno.
Il modello crea un ruolo IAM federato con una policy di attendibilità che consente all’IdP SAML di assumere tale ruolo. Gli utenti autenticati dal tuo IdP esterno possono assumere questo ruolo per accedere alle risorse AWS in base alle autorizzazioni associate al ruolo.
La risorsa implementata include i seguenti elementi:
+ Un ruolo IAM federato che ritiene attendibile il tuo IdP SAML esistente.
+ Policy gestite configurabili che possono essere associate al ruolo per concedere autorizzazioni specifiche.
+ Impostazioni facoltative del limite delle autorizzazioni e della durata della sessione.
## Prerequisiti
Questo tutorial presuppone che tu abbia a disposizione quanto segue:
+ Un IdP SAML esistente configurato nel AWS tuo account. Se non ne possiedi già uno, puoi crearlo utilizzando il tutorial [Tutorial IAM: utilizza un CloudFormation modello per creare un provider di identità SAML (IdP)](tutorial_saml-idp.md).
+ L’ARN del tuo IdP SAML, che dovrai specificare come parametro durante la creazione dello stack.
+ Python 3.6 o versione successiva installato sul computer locale per eseguire il comando Python utilizzato in questo tutorial per formattare il file XML dei metadati SAML del tuo IdP.
## Crea un ruolo federato SAML utilizzando CloudFormation
Per creare il ruolo federato SAML, creerai un CloudFormation modello e lo utilizzerai per creare uno stack contenente il ruolo.
### Creazione del modello
Per prima cosa, crea il modello. CloudFormation
1. Nella sezione [Modello](#tutorial_saml-federated-role-template), fai clic sull’icona di copia nella scheda **JSON** o **YAML** per copiare i contenuti del modello.
1. Copia i contenuti del modello in un nuovo file.
1. Salva il file localmente.
### Creazione dello stack
Quindi, usa il modello che hai salvato per effettuare il provisioning di uno CloudFormation stack.
1. Apri la CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Nella pagina **Stack**, scegli **Con nuove risorse (standard)** nel menu **Crea stack**.
1. Specifica il modello:
1. In **Prerequisito**, seleziona **Scegli un modello esistente**.
1. In **Specifica modello**, seleziona **Carica un file di modello**.
1. Seleziona **Scegli file**, quindi passa al file del modello e selezionalo.
1. Scegli **Next (Successivo)**.
1. Specifica i seguenti dettagli dello stack:
1. Inserisci un nome dello stack.
1. Per **SAMLProviderARN, inserisci l'ARN** del tuo IdP SAML esistente. Dovrebbe essere nel formato `arn:aws:iam::123456789012:saml-provider/YourProviderName`.
Ad esempio: `arn:aws:iam::123456789012:saml-provider/CompanyIdP`
**Nota**
Se hai creato il tuo IdP SAML utilizzando [Tutorial IAM: utilizza un CloudFormation modello per creare un provider di identità SAML (IdP)](tutorial_saml-idp.md) il tutorial, puoi trovare l'ARN del provider nella scheda Output di quello stack. CloudFormation
1. Infatti **RoleName**, puoi lasciare vuoto questo campo per generare automaticamente un nome basato sul nome dello stack o inserire un nome personalizzato per il ruolo IAM.
Esempio: `SAML-Developer-Access` o `SAML-ReadOnly-Role`
1. Per gli altri parametri, accetta i valori predefiniti o inseriscine altri in base ai tuoi requisiti:
+ **RoleSessionDuration**- Durata massima della sessione in secondi (3600-43200, impostazione predefinita 7200)
Esempio: `14400` (4 ore)
+ **RolePermissionsBoundary**- ARN opzionale di una politica sui limiti delle autorizzazioni
Ad esempio: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**- Percorso per il ruolo IAM (l'impostazione predefinita è/)
Ad esempio: `/saml-roles/`
+ **ManagedPolicy1-5** - Possibilità ARNs di allegare fino a 5 policy gestite
Esempio per ManagedPolicy 1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Esempio per ManagedPolicy 2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Scegli **Next (Successivo)**.
1. Configura le opzioni dello stack:
1. In **Opzioni di errore dello stack**, scegli **Elimina tutte le nuove risorse create**.
**Nota**
Scegliendo questa opzione si evita di ricevere addebiti per risorse la cui policy di eliminazione specifica che devono essere mantenute anche se la creazione dello stack non riesce.
1. Accetta tutti gli altri valori predefiniti.
1. In **Capacità**, seleziona la casella per confermare che CloudFormation potresti creare risorse IAM nel tuo account.
1. Scegli **Next (Successivo)**.
1. Rivedi i dettagli dello stack e scegli **Invia**.
CloudFormation crea lo stack. Una volta completata la creazione dello stack, le relative risorse sono pronte per l’uso. Puoi utilizzare la scheda **Risorse** nella pagina dei dettagli dello stack per visualizzare le risorse che sono state fornite nel tuo account.
Lo stack produrrà il seguente valore, che puoi visualizzare nella scheda **Output**:
+ **RoleARN**: l’ARN del ruolo IAM creato (ad esempio, `arn:aws:iam::123456789012:role/SAML-Developer-Access` o `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` se si utilizza un nome generato automaticamente).
Avrai bisogno di questo ARN del ruolo quando configuri il tuo IdP per inviare gli attributi SAML appropriati per l’assunzione del ruolo.
## Prova del ruolo federato SAML
Una volta creato il ruolo federato SAML, puoi verificarne la configurazione e testare l’impostazione della federazione.
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, seleziona **Ruoli**.
1. Trova e scegli il ruolo federato appena creato.
Se hai fornito un nome di ruolo personalizzato, cerca quel nome. Se hai lasciato il RoleName parametro vuoto, il ruolo avrà un nome generato automaticamente basato sul nome dello stack e un identificatore univoco.
1. Scegli la scheda **Relazioni di attendibilità** per rivedere la policy di attendibilità.
La policy di attendibilità dovrebbe mostrare che il tuo IdP SAML è affidabile per assumere questo ruolo a condizione che il pubblico SAML (`SAML:aud`) corrisponda a `https://signin.aws.amazon.com/saml`.
1. Scegli la scheda **Autorizzazioni** per esaminare le policy collegate.
Puoi vedere tutte le policy gestite collegate al ruolo durante la creazione.
1. Prendi nota dell’**ARN del ruolo** visualizzato nella pagina di riepilogo del ruolo.
Questo ARN ti servirà per configurare il tuo IdP esterno e consentire agli utenti di assumere questo ruolo.
Il tuo ruolo federato SAML è ora pronto per essere utilizzato. Configura il tuo IdP esterno per includere l'ARN di questo ruolo nelle asserzioni SAML e gli utenti autenticati potranno assumere questo ruolo per accedere alle risorse. AWS
## Pulizia: eliminazione delle risorse
Come passaggio finale, eliminerai lo stack e le risorse in esso contenute.
1. Apri la CloudFormation console.
1. Nella pagina **Stack**, scegli lo stack creato dal modello, poi scegli **Elimina**, quindi conferma con **Elimina**.
CloudFormation avvia l'eliminazione dello stack e di tutte le risorse che include.
## CloudFormation dettagli del modello
### Resources
Il CloudFormation modello di questo tutorial creerà la seguente risorsa nel tuo account:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): un ruolo IAM federato che può essere assunto dagli utenti autenticati tramite il tuo IdP SAML.
### Configurazione
Il modello include i seguenti parametri configurabili:
+ **RoleName**- Nome del ruolo IAM (lasciare vuoto il campo per il nome generato automaticamente)
+ **SAMLProviderARN - ARN** dell'IdP SAML (obbligatorio)
+ **RoleSessionDuration**- Durata massima della sessione in secondi (3600-43200, impostazione predefinita 7200)
+ **RolePermissionsBoundary**- ARN opzionale della politica dei limiti delle autorizzazioni
+ **RolePath**- Percorso per il ruolo IAM (default/)
+ **ManagedPolicy1-5** - Possibilità ARNs di allegare fino a 5 policy gestite
## CloudFormation modello
Salva il seguente codice JSON o YAML come file separato da utilizzare come CloudFormation modello per questo tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-federated-role",
"Parameters": {
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"SAMLProviderARN": {
"Type": "String",
"Description": "ARN of the SAML Identity Provider",
"AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be a valid SAML provider ARN"
},
"RoleSessionDuration": {
"Type": "Number",
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM role (must start and end with /)",
"Default": "/",
"AllowedPattern": "^\/.*\/$|^\/$",
"ConstraintDescription": "Role path must start and end with forward slash (/)"
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}
},
"Resources": {
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Description": "IAM role with SAML provider trust",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProviderARN"}
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-federated-role'
Parameters:
RoleName:
Type: String
Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')'
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-'
SAMLProviderARN:
Type: String
Description: 'ARN of the SAML Identity Provider'
AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be a valid SAML provider ARN'
RoleSessionDuration:
Type: Number
Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)'
MinValue: 3600
MaxValue: 43200
Default: 7200
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RolePath:
Type: String
Description: 'Path for the IAM role (must start and end with /)'
Default: "/"
AllowedPattern: '^\/.*\/$|^\/$'
ConstraintDescription: 'Role path must start and end with forward slash (/)'
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
Resources:
SAMLFederatedRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Description: 'IAM role with SAML provider trust'
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
Path: !Ref RolePath
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProviderARN
Action: 'sts:AssumeRoleWithSAML'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns:
!Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue']
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue']
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue']
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue']
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue']
Outputs:
RoleARN:
Description: 'ARN of the created IAM Role'
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
```
------
# Tutorial IAM: utilizza un CloudFormation modello per creare un provider di identità SAML (IdP) e un ruolo IAM federato SAML
Per acquisire familiarità con la federazione SAML e le sue funzionalità, utilizzerai un CloudFormation modello per configurare un provider di identità SAML (IdP) e il ruolo IAM federato associato. Questo tutorial mostra come creare entrambe le risorse in un unico stack.
Il modello crea un IdP SAML che può essere utilizzato per l'accesso federato alle risorse, insieme AWS a un ruolo IAM che si fida del provider SAML. Gli utenti autenticati dal tuo IdP esterno possono assumere questo ruolo per accedere alle AWS risorse.
Le risorse implementate includono i seguenti elementi:
+ Un IdP SAML configurato con il documento di metadati dell’IdP.
+ Un ruolo IAM federato che ritiene attendibile l’IdP SAML e che può essere assunto dagli utenti autenticati.
+ Policy gestite configurabili che possono essere associate al ruolo per concedere autorizzazioni specifiche.
## Prerequisiti
Questo tutorial presuppone che tu abbia a disposizione quanto segue:
+ Python 3.6 o versione successiva installato sul computer locale per eseguire il comando Python utilizzato in questo tutorial per formattare il file XML dei metadati SAML del tuo IdP.
+ Un documento di metadati SAML del tuo IdP esterno salvato come file XML.
## Crea un IdP e un ruolo SAML utilizzando CloudFormation
Per creare l'IdP SAML e il ruolo federato, creerai CloudFormation un modello e lo utilizzerai per creare uno stack contenente entrambe le risorse.
### Creazione del modello
Innanzitutto, crea il modello. CloudFormation
1. Nella sezione [Modello](#tutorial_saml-idp-and-federated-role-template), fai clic sull’icona di copia nella scheda **JSON** o **YAML** per copiare i contenuti del modello.
1. Copia i contenuti del modello in un nuovo file.
1. Salva il file localmente.
### Creazione dello stack
Quindi, usa il modello che hai salvato per effettuare il provisioning di uno CloudFormation stack.
1. Apri la CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Nella pagina **Stack**, scegli **Con nuove risorse (standard)** nel menu **Crea stack**.
1. Specifica il modello:
1. In **Prerequisito**, seleziona **Scegli un modello esistente**.
1. In **Specifica modello**, seleziona **Carica un file di modello**.
1. Seleziona **Scegli file**, quindi passa al file del modello e selezionalo.
1. Scegli **Next (Successivo)**.
1. Specifica i seguenti dettagli dello stack:
1. Inserisci un nome dello stack.
1. Infatti **IdentityProviderName**, puoi lasciare vuoto questo campo per generare automaticamente un nome basato sul nome dello stack o inserire un nome personalizzato per il tuo IdP SAML.
Esempio: `CompanyIdP` o `EnterpriseSSO`
1. Per **IdentityProviderSAMLMetadataDocument**, devi formattare il file XML dei metadati SAML come una singola riga prima di incollarlo in questo campo. Ciò è necessario perché la CloudFormation console richiede che il contenuto XML venga formattato come una singola riga quando viene passato attraverso i parametri della console.
Usa il seguente comando Python per riformattare il tuo file XML:
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**Nota**
Il documento di metadati SAML dell’IdP deve essere formattato come una singola riga per poter essere utilizzato come parametro nella console. Il comando Python rimuove le interruzioni di riga e gli spazi bianchi aggiuntivi per creare il formato richiesto, mantenendo però intatti tutti i contenuti e la struttura originali.
Copia l'output dal comando Python e incollalo nel campo **IdentityProviderSAMLMetadataDocumento**.
Esempio di documento di metadati SAML formattato (abbreviato):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Infatti **RoleName**, puoi lasciare vuoto questo campo per generare automaticamente un nome basato sul nome dello stack o inserire un nome personalizzato per il ruolo IAM federato.
Esempio: `SAML-Developer-Access` o `SAML-ReadOnly-Role`
1. Per gli altri parametri, accetta i valori predefiniti o inseriscine altri in base ai tuoi requisiti:
+ **IdentityProviderAddPrivateKey**- Chiave privata opzionale per decrittografare le asserzioni SAML
+ **IdentityProviderAssertionEncryptionMode**- Modalità di crittografia per le asserzioni SAML
Valori di esempio: `Allowed`, `Required` o lasciare vuoto per non utilizzare alcuna crittografia
+ **RoleSessionDuration**- Durata massima della sessione in secondi (3600-43200, impostazione predefinita 7200)
Esempio: `14400` (4 ore)
+ **RolePermissionsBoundary**- ARN opzionale di una politica sui limiti delle autorizzazioni
Ad esempio: `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**- Percorso per il ruolo IAM (l'impostazione predefinita è/)
Ad esempio: `/saml-roles/`
+ **RoleManagedPolicy1-5** - Possibilità ARNs di allegare un massimo di 5 policy gestite
Esempio per RoleManagedPolicy 1: `arn:aws:iam::aws:policy/ReadOnlyAccess`
Esempio per RoleManagedPolicy 2: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Scegli **Next (Successivo)**.
1. Configura le opzioni dello stack:
1. In **Opzioni di errore dello stack**, scegli **Elimina tutte le nuove risorse create**.
**Nota**
Scegliendo questa opzione si evita di ricevere addebiti per risorse la cui policy di eliminazione specifica che devono essere mantenute anche se la creazione dello stack non riesce.
1. Accetta tutti gli altri valori predefiniti.
1. In **Capacità**, seleziona la casella per confermare che CloudFormation potresti creare risorse IAM nel tuo account.
1. Scegli **Next (Successivo)**.
1. Rivedi i dettagli dello stack e scegli **Invia**.
CloudFormation crea lo stack. Una volta completata la creazione dello stack, le relative risorse sono pronte per l’uso. Puoi utilizzare la scheda **Risorse** nella pagina dei dettagli dello stack per visualizzare le risorse che sono state fornite nel tuo account.
Lo stack produrrà i seguenti valori, che puoi visualizzare nella scheda **Output**:
+ **RoleARN**: l’ARN del ruolo IAM creato (ad esempio, `arn:aws:iam::123456789012:role/SAML-Developer-Access` o `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` se si utilizza un nome generato automaticamente).
+ **IdentityProviderARN**: l'ARN dell'IdP SAML creato (ad esempio,). `arn:aws:iam::123456789012:saml-provider/CompanyIdP`
Avrai bisogno di entrambi questi elementi per configurare ARNs il tuo IdP per inviare gli attributi SAML appropriati per l'assunzione del ruolo.
## Test della federazione SAML
Una volta che sono stati creati il ruolo federato e l’IdP SAML, puoi testare l’impostazione della federazione.
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione, scegli **Identity providers** (Provider di identità).
L’elenco dovrebbe mostrare l’IdP SAML appena creato.
1. Scegli il nome dell’IdP per visualizzarne i dettagli.
Nella pagina dei dettagli dell’IdP, puoi vedere il documento di metadati SAML e altri dettagli di configurazione.
1. Nel riquadro di navigazione, seleziona **Ruoli**.
1. Trova e scegli il ruolo federato appena creato.
Nella pagina dei dettagli del ruolo, puoi vedere la policy di attendibilità che consente all’IdP SAML di assumere questo ruolo.
1. Scegli la scheda **Relazioni di attendibilità** per rivedere la policy di attendibilità.
La policy di attendibilità dovrebbe mostrare che l’IdP SAML è affidabile per assumere questo ruolo a condizione che il pubblico SAML (`SAML:aud`) corrisponda a `https://signin.aws.amazon.com/saml`.
## Pulizia: eliminazione delle risorse
Come passaggio finale, eliminerai lo stack e le risorse in esso contenute.
1. Apri la console. CloudFormation
1. Nella pagina **Stack**, scegli lo stack creato dal modello, poi scegli **Elimina**, quindi conferma con **Elimina**.
CloudFormation avvia l'eliminazione dello stack e di tutte le risorse che include.
## CloudFormation dettagli del modello
### Resources
Il CloudFormation modello di questo tutorial creerà le seguenti risorse nel tuo account:
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP SAML che stabilisce un rapporto di fiducia AWS tra e il tuo IdP esterno.
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): un ruolo IAM federato che può essere assunto dagli utenti autenticati tramite l’IdP SAML.
### Configurazione
Il modello include i seguenti parametri configurabili:
+ **IdentityProviderName**- Nome dell'IdP SAML (lascia vuoto il nome generato automaticamente)
+ **IdentityProviderSAMLMetadataDocumento: documento** di metadati SAML del tuo IdP (richiesto)
+ **IdentityProviderAddPrivateKey**- Chiave privata opzionale per decrittografare le asserzioni SAML
+ **IdentityProviderAssertionEncryptionMode**- Modalità di crittografia per le asserzioni SAML
+ **RoleName**- Nome del ruolo IAM (lasciare vuoto il nome generato automaticamente)
+ **RolePath**- Percorso per il ruolo IAM (predefinito/)
+ **RolePermissionsBoundary**- ARN opzionale della politica dei limiti delle autorizzazioni
+ **RoleSessionDuration**- Durata massima della sessione in secondi (3600-43200, impostazione predefinita 7200)
+ **RoleManagedPolicy1-5 - Possibilità** di allegare fino a 5 ARNs policy gestite
## CloudFormation modello
Salva il seguente codice JSON o YAML come file separato da utilizzare come CloudFormation modello per questo tutorial.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
},
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM Role",
"AllowedPattern": "(^\\/$)|(^\\/.*\\/$)",
"Default": "/"
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RoleSessionDuration": {
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"Type": "Number",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]},
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]},
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
},
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"Description": "SAML federated IAM role for SSO access with specified permissions",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProvider"}
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
},
"IdentityProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
RoleName:
Type: String
Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
RolePath:
Type: String
Description: Path for the IAM Role
AllowedPattern: (^\/$)|(^\/.*\/$)
Default: "/"
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RoleSessionDuration:
Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)
Type: Number
MinValue: 3600
MaxValue: 43200
Default: 7200
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]]
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
Resources:
SAMLProvider:
Type: AWS::IAM::SAMLProvider
Properties:
Name: !If
- HasCustomProviderName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasAssertionEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
SAMLFederatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Path: !Ref RolePath
Description: "SAML federated IAM role for SSO access with specified permissions"
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProvider
Action:
- 'sts:AssumeRole'
- 'sts:SetSourceIdentity'
- 'sts:TagSession'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns: !Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"]
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"]
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"]
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"]
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"]
Outputs:
RoleARN:
Description: ARN of the created IAM Role
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
IdentityProviderARN:
Description: ARN of the created SAML Identity Provider
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-IdentityProviderARN'
```
------