```
Inoltre, è necessario evitare gli argomenti del comando Bash quando si eseguono comandi con lo script runner. Di seguito è riportato un esempio che mostra l'impostazione delle proprietà di Spark, con caratteri di escape inclusi:
```
"\"--conf spark.sql.autoBroadcastJoinThreshold=-1\n--conf spark.cradle.RSv2Mode.enabled=true\""
```
+ I ruoli di runtime non forniscono supporto per il controllo dell'accesso alle risorse del cluster, come HDFS e HMS.
+ I ruoli di runtime non forniscono supporto per docker/container.
# Configura i ruoli di servizio IAM per le autorizzazioni Amazon EMR su servizi e risorse AWS
Amazon EMR e applicazioni come Hadoop e Spark hanno bisogno di autorizzazioni per accedere ad altre risorse AWS ed eseguire operazioni quando sono in esecuzione. Ogni cluster in Amazon EMR deve avere un *ruolo di servizio* e un ruolo per il *profilo dell'istanza* Amazon EC2. Per ulteriori informazioni, consulta [Ruoli IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) e [Utilizzo dei profili dell'istanza](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) nella *Guida per l'utente IAM*. Le policy IAM allegate a questi ruoli forniscono al cluster le autorizzazioni per interagire con altri servizi AWS per conto di un utente.
Un ruolo aggiuntivo, il ruolo Auto Scaling, è necessario se il cluster utilizza la scalabilità automatica in Amazon EMR. Il ruolo AWS di servizio per EMR Notebooks è richiesto se si utilizzano EMR Notebooks.
Amazon EMR fornisce ruoli e policy gestite predefiniti che determinano le autorizzazioni per ciascun ruolo. Le policy gestite vengono create e gestite da AWS, quindi vengono aggiornate automaticamente se i requisiti del servizio cambiano. Per ulteriori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies.html) nella* Guida per l'utente IAM*.
Se si sta creando un cluster o un notebook per la prima volta in un account, i ruoli per Amazon EMR non esistono ancora. Dopo averle create, puoi visualizzare i ruoli, le policy ad esse associate e le autorizzazioni consentite o negate dalle politiche nella console IAM ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)). È possibile specificare ruoli predefiniti per Amazon EMR da creare e utilizzare, è possibile creare ruoli propri e specificarli individualmente al momento della creazione di un cluster per personalizzare le autorizzazioni, infine è possibile specificare ruoli predefiniti da utilizzare al momento della creazione di un cluster utilizzando la AWS CLI. Per ulteriori informazioni, consulta [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md).
## Modifica di policy basate sull'identità per le autorizzazioni a passare i ruoli del servizio per Amazon EMR
Le policy gestite predefinite con autorizzazioni complete di Amazon EMR incorporano configurazioni di sicurezza `iam:PassRole`, tra cui:
+ Autorizzazioni `iam:PassRole` solo per specifici ruoli Amazon EMR predefiniti.
+ `iam:PassedToService`condizioni che consentono di utilizzare la policy solo con AWS servizi specifici, come `elasticmapreduce.amazonaws.com` e`ec2.amazonaws.com`.
Puoi visualizzare la versione JSON delle policy Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) nella console IAM. Ti consigliamo di creare i nuovi cluster con le policy gestite v2.
## Riepilogo del ruolo di servizio
La tabella seguente elenca i ruoli del servizio IAM associati ad Amazon EMR per riferimento rapido.
| Funzione | Ruolo predefinito | Description | Policy gestita predefinita |
| --- | --- | --- | --- |
| [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md) | `EMR_DefaultRole_V2` | Consente ad Amazon EMR di chiamare altri AWS servizi per tuo conto durante il provisioning di risorse e l'esecuzione di azioni a livello di servizio. Questo ruolo è obbligatorio per tutti i cluster. | `AmazonEMRServicePolicy_v2` Per richiedere le Istanze spot è necessario un ruolo collegato al servizio. Se questo ruolo non esiste, il ruolo di servizio Amazon EMR deve avere l'autorizzazione per crearlo, altrimenti si verifica un errore di autorizzazione. Se si prevede di richiedere istanze Spot, è necessario aggiornare questa policy per includere un'istruzione che consenta la creazione di questo ruolo collegato al servizio. Per ulteriori informazioni, consulta [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md) il [ruolo collegato ai servizi per le richieste di istanze Spot nella Guida](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) per l'utente di *Amazon EC2*. |
| [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md) | `EMR_EC2_DefaultRole` | I processi applicativi eseguiti sull'ecosistema Hadoop su istanze cluster utilizzano questo ruolo quando chiamano altri servizi. AWS Per accedere ai dati in Amazon S3 utilizzando EMRFS, è possibile specificare diversi ruoli da assumere in base alla posizione dei dati in Amazon S3. Ad esempio, più team possono accedere a un singolo "account di archiviazione" dei dati di Amazon S3. Per ulteriori informazioni, consulta [Configurazione di ruoli IAM per le richieste EMRFS ad Amazon S3](emr-emrfs-iam-roles.md). Questo ruolo è obbligatorio per tutti i cluster. | `AmazonElasticMapReduceforEC2Role`. Per ulteriori informazioni, consulta [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md). |
| [Ruolo di servizio per il dimensionamento automatico in Amazon EMR (ruolo Auto Scaling)](emr-iam-role-automatic-scaling.md) | `EMR_AutoScaling_DefaultRole` | Consente di eseguire azioni aggiuntive per ambienti con dimensionamento dinamico. Necessario solo per i cluster che utilizzano la scalabilità automatica in Amazon EMR. Per ulteriori informazioni, consulta [Utilizzo del ridimensionamento automatico con una politica personalizzata, ad esempio gruppi in Amazon EMR](emr-automatic-scaling.md). | `AmazonElasticMapReduceforAutoScalingRole`. Per ulteriori informazioni, consulta [Ruolo di servizio per il dimensionamento automatico in Amazon EMR (ruolo Auto Scaling)](emr-iam-role-automatic-scaling.md). |
| [Ruolo di servizio per EMR Notebooks](emr-managed-notebooks-service-role.md) | `EMR_Notebooks_DefaultRole` | Fornisce le autorizzazioni necessarie a un notebook EMR per accedere ad AWS altre risorse ed eseguire azioni. Richiesto solo se si utilizza EMR Notebooks. | `AmazonElasticMapReduceEditorsRole`. Per ulteriori informazioni, consulta [Ruolo di servizio per EMR Notebooks](emr-managed-notebooks-service-role.md). `S3FullAccessPolicy` è inoltre collegato per impostazione predefinita. Il contenuto di questa policy è mostrato di seguito. JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
``` |
| [Ruolo collegato ai servizi](using-service-linked-roles.md) | `AWSServiceRoleForEMRCleanup` | Amazon EMR crea automaticamente un ruolo collegato ai servizi. Se il servizio per Amazon EMR ha perso la capacità di eliminare risorse Amazon EC2, Amazon EMR può utilizzare questo ruolo per farlo. Se un cluster usa le istanze Spot, le policy di autorizzazione associate a [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md) devono consentire la creazione di un ruolo collegato al servizio. Per ulteriori informazioni, consulta [Utilizzo di ruoli collegati ai servizi per Amazon EMR](using-service-linked-roles.md). | `AmazonEMRCleanupPolicy` |
**Topics**
+ [Modifica di policy basate sull'identità per le autorizzazioni a passare i ruoli del servizio per Amazon EMR](#emr-iam-roles-passrole)
+ [Riepilogo del ruolo di servizio](#emr-iam-roles-summary)
+ [Ruoli di servizio IAM utilizzati da Amazon EMR](emr-iam-service-roles.md)
+ [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md)
+ [Configurazione di ruoli IAM per le richieste EMRFS ad Amazon S3](emr-emrfs-iam-roles.md)
+ [Utilizza politiche basate sulle risorse per l'accesso di Amazon EMR a Glue Data Catalog AWS](emr-iam-roles-glue.md)
+ [Usa i ruoli IAM con applicazioni che chiamano direttamente AWS i servizi](emr-iam-roles-calling.md)
+ [Consentire a utenti e gruppi di creare e modificare i ruoli](emr-iam-roles-create-permissions.md)
# Ruoli di servizio IAM utilizzati da Amazon EMR
Amazon EMR impiega i ruoli di servizio IAM per eseguire operazioni per conto dell'utente durante il provisioning delle risorse cluster, l'esecuzione di applicazioni, il dimensionamento dinamico delle risorse e la creazione ed esecuzione di EMR Notebooks. Amazon EMR utilizza i seguenti ruoli durante l'interazione con altri servizi AWS . Ogni ruolo dispone di una funzione univoca all'interno di Amazon EMR. Gli argomenti in questa sezione descrivono la funzione del ruolo e forniscono i ruoli e le policy di autorizzazioni predefiniti per ciascun ruolo.
Se nel cluster è presente un codice applicativo che richiama direttamente AWS i servizi, potrebbe essere necessario utilizzare l'SDK per specificare i ruoli. Per ulteriori informazioni, consulta [Usa i ruoli IAM con applicazioni che chiamano direttamente AWS i servizi](emr-iam-roles-calling.md).
**Topics**
+ [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md)
+ [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md)
+ [Ruolo di servizio per il dimensionamento automatico in Amazon EMR (ruolo Auto Scaling)](emr-iam-role-automatic-scaling.md)
+ [Ruolo di servizio per EMR Notebooks](emr-managed-notebooks-service-role.md)
+ [Utilizzo di ruoli collegati ai servizi per Amazon EMR](using-service-linked-roles.md)
# Ruolo di servizio per Amazon EMR (ruolo EMR)
Il ruolo di servizio di Amazon EMR definisce le azioni consentite ad Amazon EMR quando effettua il provisioning delle risorse ed esegue attività a livello di servizio che non vengono eseguite nel contesto di un'istanza Amazon EC2 in esecuzione in un cluster. Ad esempio, il ruolo del servizio viene utilizzato per effettuare il provisioning di istanze EC2 quando viene avviato un cluster.
+ Il nome del ruolo predefinito è `EMR_DefaultRole_V2`.
+ La policy gestita predefinita necessaria per Amazon EMR e associata a `EMR_DefaultRole_V2` è `AmazonEMRServicePolicy_v2`. Questa policy v2 sostituisce la policy gestita predefinita e obsoleta `AmazonElasticMapReduceRole`.
`AmazonEMRServicePolicy_v2` dipende dall'accesso ridotto alle risorse che Amazon EMR fornisce o utilizza. Quando si utilizza questa policy, è necessario passare il tag utente `for-use-with-amazon-emr-managed-policies = true` durante il provisioning del cluster. Amazon EMR propaga automaticamente tali tag. Inoltre, potrebbe essere necessario aggiungere manualmente un tag utente a tipi specifici di risorse, ad esempio gruppi di sicurezza EC2 che non sono stati creati da Amazon EMR. Per informazioni, consulta [Assegnazione di tag alle risorse per l'utilizzo delle policy gestite](emr-managed-iam-policies.md#manually-tagged-resources).
**Importante**
Amazon EMR utilizza questo ruolo di servizio Amazon EMR e il ruolo `AWSServiceRoleForEMRCleanup` per pulire le risorse del cluster del tuo account che non usi più, come le istanze Amazon EC2. È necessario includere azioni relative alle policy del ruolo per eliminare o terminare le risorse. Altrimenti, Amazon EMR non può eseguire queste azioni di pulizia e potresti incorrere in costi per le risorse inutilizzate che rimangono nel cluster.
Nell'esempio seguente viene mostrato il contenuto della policy `AmazonEMRServicePolicy_v2` corrente. È anche possibile visualizzare il contenuto corrente della policy gestita [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) sulla console IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateInTaggedNetwork",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateWithEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplate"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedInstancesAndVolumes",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ResourcesToLaunchEC2",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:capacity-reservation/*",
"arn:aws:ec2:*:*:placement-group/pg-*",
"arn:aws:ec2:*:*:fleet/*",
"arn:aws:ec2:*:*:dedicated-host/*",
"arn:aws:resource-groups:*:*:group/*"
]
},
{
"Sid": "ManageEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplateVersion",
"ec2:DeleteLaunchTemplate",
"ec2:DeleteNetworkInterface",
"ec2:ModifyInstanceAttribute",
"ec2:TerminateInstances"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ManageTagsOnEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateNetworkInterfaceNeededForPrivateSubnet",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateTaggedEMRResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateFleet",
"CreateLaunchTemplate",
"CreateNetworkInterface"
]
}
}
},
{
"Sid": "TagPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "ListActionsForEC2Resources",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeCapacityReservations",
"ec2:DescribeDhcpOptions",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePlacementGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs"
],
"Resource": [
"*"
]
},
{
"Sid": "CreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateDefaultSecurityGroupInVPCWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"ec2:CreateAction": "CreateSecurityGroup"
}
}
},
{
"Sid": "ManageSecurityGroups",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreatePlacementGroup"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "DeletePlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:DeletePlacementGroup"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScaling",
"Effect": "Allow",
"Action": [
"application-autoscaling:DeleteScalingPolicy",
"application-autoscaling:DeregisterScalableTarget",
"application-autoscaling:DescribeScalableTargets",
"application-autoscaling:DescribeScalingPolicies",
"application-autoscaling:PutScalingPolicy",
"application-autoscaling:RegisterScalableTarget"
],
"Resource": [
"*"
]
},
{
"Sid": "ResourceGroupsForCapacityReservations",
"Effect": "Allow",
"Action": [
"resource-groups:ListGroupResources"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScalingCloudWatch",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricAlarm",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:*_EMR_Auto_Scaling"
]
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "CreateAndModifyEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:ModifyVpcEndpoint",
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
},
{
"Sid": "TagEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint",
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
}
]
}
```
------
Il tuo ruolo di servizio dovrebbe utilizzare la seguente policy di attendibilità:
**Importante**
La policy di attendibilità seguente include le chiavi di condizione globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) per limitare le autorizzazioni concesse ad Amazon EMR per determinate risorse dell'account. Il loro utilizzo può proteggerti dal [problema del "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
}
}
]
}
```
------
# Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)
Il ruolo di servizio per le istanze EC2 del cluster (detto anche profilo dell'istanza EC2 per Amazon EMR) è un tipo speciale di ruolo di servizio assegnato a ogni istanza EC2 in un cluster Amazon EMR quando l'istanza viene avviata. I processi delle applicazioni eseguite sull'ecosistema Hadoop presuppongono che questo ruolo per le autorizzazioni interagisca con altri servizi AWS .
Per ulteriori informazioni sui ruoli di servizio per le istanze EC2, consulta [Utilizzo di un ruolo IAM per concedere autorizzazioni ad applicazioni in esecuzione su istanze di Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) nella *Guida per l'utente IAM*.
**Importante**
Il ruolo di servizio predefinito per le istanze EC2 del cluster e la relativa politica gestita AWS predefinita associata `AmazonElasticMapReduceforEC2Role` stanno per diventare obsoleti, senza che vengano fornite politiche gestite sostitutive. AWS Sarà necessario creare e specificare un profilo di istanza per sostituire il ruolo obsoleto e la policy predefinita.
## Ruolo predefinito e policy gestita
+ Il nome del ruolo predefinito è `EMR_EC2_DefaultRole`.
+ Il supporto per la policy gestita da `EMR_EC2_DefaultRole` predefinita (`AmazonElasticMapReduceforEC2Role`) è quasi al termine. Invece di utilizzare una policy gestita predefinita per il profilo dell'istanza EC2, applica policy basate sulle risorse ai bucket S3 e ad altre risorse di cui Amazon EMR necessita, oppure utilizza la policy gestita dal cliente con un ruolo IAM come profilo dell'istanza. Per ulteriori informazioni, consulta [Creazione di un ruolo di servizio per le istanze EC2 del cluster con le autorizzazioni con privilegi minimi](#emr-ec2-role-least-privilege).
Di seguito viene mostrato il contenuto della versione 3 di `AmazonElasticMapReduceforEC2Role`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"cloudwatch:*",
"dynamodb:*",
"ec2:Describe*",
"elasticmapreduce:Describe*",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSteps",
"kinesis:CreateStream",
"kinesis:DeleteStream",
"kinesis:DescribeStream",
"kinesis:GetRecords",
"kinesis:GetShardIterator",
"kinesis:MergeShards",
"kinesis:PutRecord",
"kinesis:SplitShard",
"rds:Describe*",
"s3:*",
"sdb:*",
"sns:*",
"sqs:*",
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Sid": "AllowCLOUDWATCH"
}
]
}
```
------
Il tuo ruolo di servizio dovrebbe utilizzare la seguente policy di attendibilità:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
}
]
}
```
------
## Creazione di un ruolo di servizio per le istanze EC2 del cluster con le autorizzazioni con privilegi minimi
Come best practice, ti consigliamo vivamente di creare un ruolo di servizio per le istanze EC2 del cluster e una politica di autorizzazioni che preveda le autorizzazioni minime per gli altri servizi richiesti dall'applicazione. AWS
La policy gestita predefinita `AmazonElasticMapReduceforEC2Role` offre le autorizzazioni che facilitano l'avvio del primo cluster. Tuttavia, `AmazonElasticMapReduceforEC2Role` è sulla via dell'obsolescenza e Amazon EMR non fornirà una policy predefinita AWS gestita sostitutiva per il ruolo obsoleto. Per avviare un cluster iniziale, è necessario fornire una policy basata sulle risorse gestita dal cliente o basata su ID.
Le seguenti dichiarazioni di policy forniscono esempi di autorizzazioni richieste per differenti caratteristiche di Amazon EMR. È consigliabile utilizzare queste autorizzazioni per la creazione di una policy di autorizzazioni che limita l'accesso alle sole caratteristiche e risorse che richiede il cluster. Tutte le dichiarazioni politiche di esempio utilizzano la regione e l'ID dell'account fittizio*us-west-2*. AWS *123456789012* Sostituirli nel modo appropriato per il cluster.
Per ulteriori informazioni sulla creazione e sula specifica di ruoli personalizzati, consulta [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md).
**Nota**
Se crei un ruolo EMR personalizzato per EC2, segui il flusso di lavoro di base che crea automaticamente un profilo di istanza con lo stesso nome. Amazon EC2 consente di creare profili di istanza e ruoli con nomi diversi, ma Amazon EMR non supporta questa configurazione e genera l'errore "invalid instance profile (profilo di istanza non valido)" quando crei il cluster.
### Lettura e scrittura di dati su Amazon S3 utilizzando EMRFS
Quando un'applicazione in esecuzione su un cluster Amazon EMR riferisce i dati utilizzando il formato `s3://mydata`, Amazon EMR utilizza il profilo dell'istanza EC2 per effettuare la richiesta. In genere, i cluster leggono e scrivono dati su Amazon S3 in questo modo e Amazon EMR utilizza le autorizzazioni associate al ruolo di servizio per le istanze EC2 del cluster per impostazione predefinita. Per ulteriori informazioni, consulta [Configurazione di ruoli IAM per le richieste EMRFS ad Amazon S3](emr-emrfs-iam-roles.md).
Poiché i ruoli IAM per EMRFS verranno ripristinati alle autorizzazioni associate al ruolo di servizio per le istanze EC2 del cluster, come best practice ti consigliamo di utilizzare i ruoli IAM per EMRFS e limitare le autorizzazioni EMRFS e Amazon S3 associate al ruolo di servizio per le istanze EC2 del cluster.
L'istruzione di esempio di seguito mostra le autorizzazioni che EMRFS richiede per effettuare le richieste ad Amazon S3.
+ *my-data-bucket-in-s3-for-emrfs-reads-and-writes* specifica il bucket in Amazon S3 dove il cluster legge e scrive i dati e tutte le sottocartelle utilizzando */\$1*. Aggiungere solo i bucket e le cartelle necessari per la propria applicazione.
+ La dichiarazione di policy che consente le azioni `dynamodb` è necessaria solo se è abilitata la visualizzazione coerente di EMRFS. *EmrFSMetadata* specifica la cartella predefinita per la visualizzazione coerente di EMRFS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:CreateBucket",
"s3:DeleteObject",
"s3:GetBucketVersioning",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:ListBucketVersions",
"s3:ListMultipartUploadParts",
"s3:PutBucketVersioning",
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": [
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes",
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes/*"
],
"Sid": "AllowS3Abortmultipartupload"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateTable",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:PutItem",
"dynamodb:DescribeTable",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem",
"dynamodb:DeleteTable",
"dynamodb:UpdateTable"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/EmrFSMetadata"
],
"Sid": "AllowDYNAMODBCreatetable"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"dynamodb:ListTables",
"s3:ListBucket"
],
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHPutmetricdata"
},
{
"Effect": "Allow",
"Action": [
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:DeleteQueue",
"sqs:SendMessage",
"sqs:CreateQueue"
],
"Resource": [
"arn:aws:sqs:*:123456789012:EMRFS-Inconsistency-*"
],
"Sid": "AllowSQSGetqueueurl"
}
]
}
```
------
### Archiviazione di file di log in Amazon S3
La seguente istruzione di policy consente al cluster Amazon EMR di archiviare i file di log nel percorso Amazon S3 specificato. Nell'esempio seguente, quando il cluster è stato creato, *s3://MyLoggingBucket/MyEMRClusterLogs* è stato specificato utilizzando la **posizione della cartella Log S3** nella console, utilizzando l'`--log-uri`opzione from o utilizzando il `LogUri` parametro nel comando. AWS CLI`RunJobFlow` Per ulteriori informazioni, consulta [Archiviazione di file di log in Amazon S3](emr-plan-debugging.md#emr-plan-debugging-logs-archive).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::MyLoggingBucket/MyEMRClusterLogs/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
### Utilizzo del AWS Glue Data Catalog
La seguente dichiarazione sulla politica consente le azioni necessarie se si utilizza il AWS Glue Data Catalog come metastore per le applicazioni. *Per ulteriori informazioni, consulta [Using the AWS Glue Data Catalog come metastore per Spark SQL](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-glue.html), Using [the AWS Glue Data Catalog come metastore per Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) e Using [Presto with the Glue AWS Data Catalog nella Amazon EMR Release Guide](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html).*
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"*"
],
"Sid": "AllowGLUECreatedatabase"
}
]
}
```
------
# Ruolo di servizio per il dimensionamento automatico in Amazon EMR (ruolo Auto Scaling)
Il ruolo Auto Scaling per Amazon EMR svolge una funzione simile a quella del ruolo di servizio, ma consente azioni aggiuntive per ambienti di scalabilità dinamica.
+ Il nome del ruolo predefinito è `EMR_AutoScaling_DefaultRole`.
+ La policy gestita predefinita associata a `EMR_AutoScaling_DefaultRole` è `AmazonElasticMapReduceforAutoScalingRole`.
I contenuti della versione 1 di `AmazonElasticMapReduceforAutoScalingRole` sono elencati di seguito.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:DescribeAlarms",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHDescribealarms"
}
]
}
```
------
Il tuo ruolo di servizio dovrebbe utilizzare la seguente policy di attendibilità:
**Importante**
La policy di attendibilità seguente include le chiavi di condizione globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) per limitare le autorizzazioni concesse ad Amazon EMR per determinate risorse dell'account. Il loro utilizzo può proteggerti dal [problema del "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/ApplicationAutoScalingEMRRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:application-autoscaling:*:123456789012:scalable-target/*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
# Ruolo di servizio per EMR Notebooks
Ogni notebook EMR necessita delle autorizzazioni per accedere ad altre AWS risorse ed eseguire azioni. Le policy IAM associate a questo ruolo di servizio forniscono le autorizzazioni per consentire al notebook di interagire con altri servizi. AWS Quando si crea un notebook utilizzando Console di gestione AWS, si specifica un ruolo di *AWS servizio*. È possibile utilizzare il ruolo predefinito, `EMR_Notebooks_DefaultRole`, oppure specificare un ruolo creato. Se un notebook non è stato creato in precedenza, è possibile scegliere di creare il ruolo predefinito.
+ Il nome del ruolo predefinito è `EMR_Notebooks_DefaultRole`.
+ Le policy gestite di default allegate a `EMR_Notebooks_DefaultRole` sono `AmazonElasticMapReduceEditorsRole` e `S3FullAccessPolicy`.
Il tuo ruolo di servizio dovrebbe utilizzare la seguente policy di attendibilità:
**Importante**
La policy di attendibilità seguente include le chiavi di condizione globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) per limitare le autorizzazioni concesse ad Amazon EMR per determinate risorse dell'account. Il loro utilizzo può proteggerti dal [problema del "confused deputy"](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Il contenuto della versione 1 di `AmazonElasticMapReduceEditorsRole` è il seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Authorizesecuritygroupegress"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"aws:elasticmapreduce:editor-id",
"aws:elasticmapreduce:job-flow-id"
]
}
},
"Sid": "AllowEC2Createtags"
}
]
}
```
------
Di seguito sono riportati il contenuto di `S3FullAccessPolicy`. La `S3FullAccessPolicy` consente al tuo ruolo di servizio per i EMR Notebooks di eseguire tutte le operazioni di Amazon S3 sugli oggetti nel Account AWS. Quando crei un ruolo di servizio personalizzato per i EMR Notebooks, devi assegnare al tuo ruolo di servizio le autorizzazioni Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
```
------
È possibile individuare l'accesso in lettura e scrittura per il ruolo di servizio nella posizione Amazon S3 in cui si desidera salvare i file del notebook. Utilizza il seguente set minimo di autorizzazioni Amazon S3.
```
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
```
Se il bucket Amazon S3 è crittografato, devi includere le seguenti autorizzazioni per AWS Key Management Service.
```
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
```
Quando si collegano i repository Git al notebook e si deve creare un segreto per il repository, è necessario aggiungere l'autorizzazione `secretsmanager:GetSecretValue` nella policy IAM collegata al ruolo di servizio per i notebooks Amazon EMR. Di seguito è illustrato un esempio di policy:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"*"
]
}
]
}
```
------
## Autorizzazioni del ruolo di servizio EMR Notebooks
In questa tabella sono elencate le azioni eseguite da EMR Notebooks utilizzando il ruolo di servizio, assieme alle autorizzazioni necessarie per ogni azione.
****
| Azione | Permissions |
| --- | --- |
| Stabilisci un canale di rete protetto tra un notebook e un cluster Amazon EMR ed esegui le azioni di pulizia necessarie. | "ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
|
| Utilizza le credenziali Git memorizzate in Gestione dei segreti AWS per collegare i repository Git a un notebook. | "secretsmanager:GetSecretValue"
|
| Applica i AWS tag all'interfaccia di rete e ai gruppi di sicurezza predefiniti creati da EMR Notebooks durante la configurazione del canale di rete sicuro. Per ulteriori informazioni, consulta [Assegnazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). | "ec2:CreateTags"
|
| Accedi o carica i file notebook e i metadati in Amazon S3. | "s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
Le seguenti autorizzazioni sono necessarie solo se utilizzi un bucket Amazon S3 crittografato. "kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
|
## EMR Notebooks: aggiornamenti alle policy gestite AWS
Visualizza i dettagli sugli aggiornamenti delle policy AWS gestite per EMR Notebooks dal 1° marzo 2021.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| AmazonElasticMapReduceEditorsRole - Added permissions | EMR Notebooks ha aggiunto le autorizzazioni `ec2:describeVPCs` e `elastmicmapreduce:ListSteps` a `AmazonElasticMapReduceEditorsRole`. | 8 febbraio 2023 |
| EMR Notebooks ha avviato il tracciamento delle modifiche | EMR Notebooks ha iniziato a tenere traccia delle modifiche per le sue policy gestite. AWS | 8 febbraio 2023 |
# Utilizzo di ruoli collegati ai servizi per Amazon EMR
Amazon EMR utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EMR. I ruoli collegati ai servizi sono predefiniti da Amazon EMR e includono tutte le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
**Topics**
+ [Utilizzo di ruoli collegati ai servizi per Amazon EMR for cleanup](using-service-linked-roles-cleanup.md)
+ [Utilizzo di ruoli collegati ai servizi con Amazon EMR per la registrazione write-ahead](using-service-linked-roles-wal.md)
****Per informazioni su altri servizi che supportano i ruoli collegati ai servizi, consulta i [AWS servizi che funzionano con IAM e cerca i servizi con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) Sì nella colonna Ruoli collegati ai servizi.**** Scegli **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
# Utilizzo di ruoli collegati ai servizi per Amazon EMR for cleanup
Amazon EMR utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EMR. I ruoli collegati ai servizi sono predefiniti da Amazon EMR e includono tutte le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
I ruoli collegati ai servizi interagiscono con il ruolo di servizio Amazon EMR e il profilo dell'istanza Amazon EC2 per Amazon EMR. Per ulteriori informazioni sul ruolo del servizio e il profilo dell'istanza, consulta [Configura i ruoli di servizio IAM per le autorizzazioni Amazon EMR su servizi e risorse AWS](emr-iam-roles.md).
Un ruolo collegato al servizio semplifica la configurazione di Amazon EMR perché non è necessario aggiungere manualmente le autorizzazioni necessarie. Amazon EMR definisce le autorizzazioni dei suoi ruoli collegati ai servizi e, se non diversamente definito, solo Amazon EMR può assumerne i ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un'altra entità IAM.
Puoi eliminare questo ruolo collegato al servizio per Amazon EMR solo dopo aver eliminato tutte le risorse correlate e terminato tutti i cluster EMR nell'account. Ciò protegge le tue risorse Amazon EMR in modo da non poter rimuovere inavvertitamente l'autorizzazione ad accedere alle risorse.
## Utilizzo di ruoli collegati ai servizi per la pulizia
Amazon EMR utilizza il ruolo basato sui servizi per concedere **AWSServiceRoleForEMRCleanup**ad Amazon EMR l'autorizzazione a terminare ed eliminare le risorse Amazon EC2 per tuo conto se il ruolo collegato al servizio Amazon EMR perde tale capacità. Amazon EMR crea automaticamente il ruolo collegato al servizio durante la creazione del cluster, se non esiste già.
Il ruolo AWSService RoleFor EMRCleanup collegato ai servizi si affida ai seguenti servizi per l'assunzione del ruolo:
+ `elasticmapreduce.amazonaws.com`
La politica AWSService RoleFor EMRCleanup di autorizzazione dei ruoli collegati al servizio consente ad Amazon EMR di completare le seguenti azioni sulle risorse specificate:
+ Operazione: `DescribeInstances` su `ec2`
+ Operazione: `DescribeLaunchTemplates` su `ec2`
+ Operazione: `DeleteLaunchTemplate` su `ec2`
+ Operazione: `DescribeSpotInstanceRequests` su `ec2`
+ Operazione: `ModifyInstanceAttribute` su `ec2`
+ Operazione: `TerminateInstances` su `ec2`
+ Operazione: `CancelSpotInstanceRequests` su `ec2`
+ Operazione: `DeleteNetworkInterface` su `ec2`
+ Operazione: `DescribeInstanceAttribute` su `ec2`
+ Operazione: `DescribeVolumeStatus` su `ec2`
+ Operazione: `DescribeVolumes` su `ec2`
+ Operazione: `DetachVolume` su `ec2`
+ Operazione: `DeleteVolume` su `ec2`
+ Operazione: `DescribePlacementGroups` su `ec2`
+ Operazione: `DeletePlacementGroup` su `ec2`
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni.
## Creazione di un ruolo collegato ai servizi per Amazon EMR
Non è necessario creare manualmente il ruolo. AWSService RoleFor EMRCleanup Quando avvii un cluster, per la prima volta o quando il ruolo AWSService RoleFor EMRCleanup collegato al servizio non è presente, Amazon EMR crea il ruolo collegato al AWSService RoleFor EMRCleanup servizio per te. È necessario disporre delle autorizzazioni per creare un ruolo collegato al servizio. Per un'istruzione di esempio che aggiunge questa funzionalità alla politica di autorizzazione di un'entità IAM (come un utente, un gruppo o un ruolo):
Aggiungi la seguente dichiarazione alla politica di autorizzazione per l'entità IAM che deve creare il ruolo collegato al servizio.
```
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
**Importante**
Se hai utilizzato Amazon EMR prima del 24 ottobre 2017, quando i ruoli collegati ai servizi non erano supportati, Amazon EMR ha creato il ruolo collegato al servizio nel tuo account. AWSService RoleFor EMRCleanup Per ulteriori informazioni, consulta [Comparsa di un nuovo ruolo nell'account IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
## Modifica di un ruolo collegato ai servizi per Amazon EMR
Amazon EMR non consente di modificare il ruolo collegato al AWSService RoleFor EMRCleanup servizio. Dopo aver creato un ruolo collegato al servizio, non puoi modificare il nome del ruolo collegato al servizio perché varie entità potrebbero fare riferimento al ruolo collegato al servizio. Tuttavia, puoi modificare la descrizione del ruolo collegato al servizio utilizzando IAM.
### Modifica della descrizione di un ruolo collegato ai servizi (console IAM)
È possibile utilizzare la console IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (console)**
1. Nel pannello di navigazione della console IAM seleziona **Roles (Ruoli)**.
1. Scegliere il nome del ruolo da modificare.
1. Nella parte destra di **Role description** (Descrizione ruolo), scegli **Edit** (Modifica).
1. Digita una nuova descrizione nella casella e scegli **Save changes (Salva modifiche)**.
### Modifica della descrizione di un ruolo collegato ai servizi (CLI IAM)
Puoi utilizzare i comandi IAM di AWS Command Line Interface per modificare la descrizione di un ruolo collegato al servizio.
**Per modificare la descrizione di un ruolo collegato ai servizi (CLI)**
1. (Facoltativo) Per visualizzare la descrizione attuale di un ruolo, utilizza i seguenti comandi:
```
$ aws iam get-role --role-name role-name
```
Per fare riferimento ai ruoli con i comandi della CLI utilizza il nome del ruolo, non l'ARN. Ad esempio, per fare riferimento a un ruolo il cui ARN è `arn:aws:iam::123456789012:role/myrole`, puoi usare **myrole**.
1. Per aggiornare la descrizione di un ruolo collegato ai servizi, utilizza uno dei seguenti comandi:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Modifica della descrizione di un ruolo collegato ai servizi (API IAM)
È possibile utilizzare l'API IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (API)**
1. (Facoltativo) Per visualizzare la descrizione attuale di un ruolo, utilizza il seguente comando:
API IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Per aggiornare la descrizione di un ruolo, utilizza il seguente comando:
API IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Eliminazione di un ruolo collegato ai servizi per Amazon EMR
Se non hai più bisogno di utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare quel ruolo collegato al servizio. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare.
### Pulizia di un ruolo collegato ai servizi
Prima di poter utilizzare IAM per eliminare un ruolo collegato al servizio, devi prima confermare che il ruolo collegato al servizio non abbia sessioni attive e rimuovere tutte le risorse utilizzate dal ruolo collegato al servizio.
**Per verificare se il ruolo collegato ai servizi dispone di una sessione attiva nella console IAM**
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**. Seleziona il nome (non la casella di controllo) del ruolo collegato al servizio. AWSService RoleFor EMRCleanup
1. **Nella pagina di **riepilogo** per il ruolo collegato al servizio selezionato, scegli Access Advisor.**
1. Nella scheda **Access Advisor (Consulente accessi)** esaminare l'attività recente per il ruolo collegato ai servizi.
**Nota**
Se non sei sicuro che Amazon EMR stia utilizzando AWSService RoleFor EMRCleanup il ruolo collegato al servizio, puoi provare a eliminare il ruolo collegato al servizio. Se il servizio utilizza il ruolo collegato al servizio, l'eliminazione non riesce e puoi visualizzare le regioni in cui viene utilizzato il ruolo collegato al servizio. Se viene utilizzato il ruolo collegato al servizio, è necessario attendere il termine della sessione prima di poter eliminare il ruolo collegato al servizio. Non puoi revocare la sessione per un ruolo collegato al servizio.
**Per rimuovere le risorse Amazon EMR utilizzate da AWSService RoleFor EMRCleanup**
+ Chiudi tutti i cluster del tuo account. Per ulteriori informazioni, consulta [Termina un cluster Amazon EMR nello stato di avvio, in esecuzione o in attesa](UsingEMR_TerminateJobFlow.md).
### Eliminazione di un ruolo collegato ai servizi (console IAM)
È possibile utilizzare la console IAM per eliminare un ruolo collegato ai servizi.
**Per eliminare un ruolo collegato ai servizi (console)**
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**. Seleziona la casella di controllo accanto a AWSService RoleForEMRCleanup, non il nome o la riga stessa.
1. In operazioni **Role (Ruolo)** nella parte superiore della pagina, seleziona **Delete (Elimina)** ruolo.
1. Nella finestra di dialogo di conferma, esamina i dati dell'ultimo accesso al servizio, che mostrano l'ultima volta che ciascuno dei ruoli selezionati ha effettuato l'ultimo accesso a un AWS servizio. In questo modo potrai verificare se il ruolo è attualmente attivo. Per procedere, seleziona **Yes, Delete** (Sì, elimina).
1. Controlla le notifiche della console IAM per monitorare lo stato dell'eliminazione del ruolo collegato ai servizi. Poiché l'eliminazione del ruolo collegato al servizio IAM è asincrona, dopo aver inviato il ruolo collegato al servizio per l'eliminazione, l'operazione di eliminazione può avere esito positivo o negativo. Se il task non viene eseguito correttamente, puoi scegliere **View details (Visualizza dettagli)** o **View Resources (Visualizza risorse)** dalle notifiche per capire perché l'eliminazione non è stata effettuata. Se l'eliminazione non viene eseguita perché vi sono risorse nel servizio che sono usate dal ruolo, il motivo dell'errore include un elenco di risorse.
### Eliminazione di un ruolo collegato ai servizi (CLI IAM)
Puoi utilizzare i comandi IAM di per eliminare un ruolo collegato al servizio. AWS Command Line Interface Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata.
**Per eliminare un ruolo collegato ai servizi (CLI)**
1. Per controllare lo stato dell'attività di eliminazione, devi acquisire il `deletion-task-id` dalla risposta. Per inviare una richiesta di eliminazione per un ruolo collegato ai servizi, digita il seguente comando:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRCleanup
```
1. Digita il seguente comando per verificare lo stato del task di eliminazione:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
### Eliminazione di un ruolo collegato ai servizi (API IAM)
È possibile utilizzare l'API IAM per eliminare un ruolo collegato ai servizi. Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata.
**Per eliminare un ruolo collegato ai servizi (API)**
1. Per inviare una richiesta di eliminazione per un ruolo collegato al servizio, chiama. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Nella richiesta, specifica il nome del AWSService RoleFor EMRCleanup ruolo.
Per controllare lo stato dell'attività di eliminazione, devi acquisire il `DeletionTaskId` dalla risposta.
1. Chiamare [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) per controllare lo stato dell'eliminazione. Nella richiesta, specificare il `DeletionTaskId`.
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
## Regioni supportate per AWSService RoleFor EMRCleanup
Amazon EMR supporta l'utilizzo del ruolo AWSService RoleFor EMRCleanup collegato ai servizi nelle seguenti regioni.
****
| Nome della Regione | Identità della Regione | Supporto in Amazon EMR |
| --- | --- | --- |
| Stati Uniti orientali (Virginia settentrionale) | us-east-1 | Sì |
| Stati Uniti orientali (Ohio) | us-east-2 | Sì |
| Stati Uniti occidentali (California settentrionale) | us-west-1 | Sì |
| Stati Uniti occidentali (Oregon) | us-west-2 | Sì |
| Asia Pacifico (Mumbai) | ap-south-1 | Sì |
| Asia Pacifico (Osaka) | ap-northeast-3 | Sì |
| Asia Pacifico (Seoul) | ap-northeast-2 | Sì |
| Asia Pacifico (Singapore) | ap-southeast-1 | Sì |
| Asia Pacifico (Sydney) | ap-southeast-2 | Sì |
| Asia Pacifico (Tokyo) | ap-northeast-1 | Sì |
| Canada (Centrale) | ca-central-1 | Sì |
| Europa (Francoforte) | eu-central-1 | Sì |
| Europa (Irlanda) | eu-west-1 | Sì |
| Europa (Londra) | eu-west-2 | Sì |
| Europa (Parigi) | eu-west-3 | Sì |
| Sud America (San Paolo) | sa-east-1 | Sì |
# Utilizzo di ruoli collegati ai servizi con Amazon EMR per la registrazione write-ahead
Amazon EMR utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EMR. I ruoli collegati ai servizi sono predefiniti da Amazon EMR e includono tutte le autorizzazioni richieste dal servizio per chiamare altri servizi per tuo conto. AWS
I ruoli collegati ai servizi interagiscono con il ruolo di servizio Amazon EMR e il profilo dell'istanza Amazon EC2 per Amazon EMR. Per ulteriori informazioni sul ruolo del servizio e il profilo dell'istanza, consulta [Configura i ruoli di servizio IAM per le autorizzazioni Amazon EMR su servizi e risorse AWS](emr-iam-roles.md).
Un ruolo collegato al servizio semplifica la configurazione di Amazon EMR perché non è necessario aggiungere manualmente le autorizzazioni necessarie. Amazon EMR definisce le autorizzazioni dei suoi ruoli collegati ai servizi e, se non diversamente definito, solo Amazon EMR può assumerne i ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un'altra entità IAM.
Puoi eliminare questo ruolo collegato al servizio per Amazon EMR solo dopo aver eliminato le relative risorse e aver terminato tutti i cluster EMR nell'account. Ciò protegge le tue risorse Amazon EMR in modo da non poter rimuovere inavvertitamente l'autorizzazione ad accedere alle risorse.
## Autorizzazioni di ruolo collegate al servizio per il write-ahead logging (WAL)
Amazon EMR utilizza il ruolo collegato al servizio **AWSServiceRoleForEMRWAL** per recuperare lo stato di un cluster.
Il ruolo collegato al servizio AWSService RoleFor EMRWAL si affida ai seguenti servizi per assumere il ruolo:
+ `emrwal.amazonaws.com`
La politica di [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md)autorizzazione per il ruolo collegato al servizio consente ad Amazon EMR di completare le seguenti azioni sulle risorse specificate:
+ Operazione: `DescribeCluster` su `*`
È necessario configurare le autorizzazioni per consentire a un'entità IAM (in questo caso, Amazon EMR WAL) di creare, modificare o eliminare un ruolo collegato al servizio. Aggiungi le seguenti istruzioni, se necessario, alla politica di autorizzazione per il tuo profilo di istanza:
## CreateServiceLinkedRole
**Per consentire a un'entità IAM di creare il ruolo collegato al servizio AWSService RoleFor EMRWAL**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve creare il ruolo collegato ai servizi:
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## UpdateRoleDescription
**Per consentire a un'entità IAM di modificare la descrizione del ruolo collegato al servizio EMRWAL AWSService RoleFor**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve modificare la descrizione di un ruolo collegato ai servizi:
```
{
"Effect": "Allow",
"Action": [
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## DeleteServiceLinkedRole
**Per consentire a un'entità IAM di eliminare il ruolo collegato al servizio EMRWAL AWSService RoleFor**
Aggiungi la seguente istruzione alla policy delle autorizzazioni per l'entità IAM che deve eliminare un ruolo collegato ai servizi:
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## Creazione di un ruolo collegato ai servizi per Amazon EMR
Non è necessario creare manualmente il ruolo EMRWAL. AWSService RoleFor Amazon EMR crea automaticamente questo ruolo collegato al servizio quando crei uno spazio di lavoro WAL con l'EMRWAL CLI o AWS CloudFormation da, HBase oppure creerà il ruolo collegato al servizio quando configuri uno spazio di lavoro per Amazon EMR WAL e il ruolo collegato al servizio non esiste ancora. È necessario disporre delle autorizzazioni per creare un ruolo collegato al servizio. Per esempio le istruzioni che aggiungono questa funzionalità alla politica di autorizzazione di un'entità IAM (come un utente, un gruppo o un ruolo), consulta la sezione precedente,. [Autorizzazioni di ruolo collegate al servizio per il write-ahead logging (WAL)](#using-service-linked-roles-permissions-wal)
## Modifica di un ruolo collegato ai servizi per Amazon EMR
Amazon EMR non consente di modificare il ruolo collegato al servizio AWSService RoleFor EMRWAL. Dopo aver creato un ruolo collegato al servizio, non puoi modificare il nome del ruolo collegato al servizio perché varie entità potrebbero fare riferimento al ruolo collegato al servizio. Tuttavia, puoi modificare la descrizione del ruolo collegato al servizio utilizzando IAM.
### Modifica della descrizione di un ruolo collegato ai servizi (console IAM)
È possibile utilizzare la console IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (console)**
1. Nel pannello di navigazione della console IAM seleziona **Roles (Ruoli)**.
1. Scegliere il nome del ruolo da modificare.
1. Nella parte destra di **Role description** (Descrizione ruolo), scegli **Edit** (Modifica).
1. Digita una nuova descrizione nella casella e scegli **Save changes (Salva modifiche)**.
### Modifica della descrizione di un ruolo collegato ai servizi (CLI IAM)
Puoi utilizzare i comandi IAM di AWS Command Line Interface per modificare la descrizione di un ruolo collegato al servizio.
**Per modificare la descrizione di un ruolo collegato ai servizi (CLI)**
1. (Facoltativo) Per visualizzare la descrizione attuale di un ruolo, utilizza i seguenti comandi:
```
$ aws iam get-role --role-name role-name
```
Per fare riferimento ai ruoli con i comandi della CLI utilizza il nome del ruolo, non l'ARN. Ad esempio, per fare riferimento a un ruolo il cui ARN è `arn:aws:iam::123456789012:role/myrole`, puoi usare **myrole**.
1. Per aggiornare la descrizione di un ruolo collegato ai servizi, utilizza uno dei seguenti comandi:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Modifica della descrizione di un ruolo collegato ai servizi (API IAM)
È possibile utilizzare l'API IAM per modificare la descrizione di un ruolo collegato ai servizi.
**Per modificare la descrizione di un ruolo collegato ai servizi (API)**
1. (Facoltativo) Per visualizzare la descrizione attuale di un ruolo, utilizza il seguente comando:
API IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Per aggiornare la descrizione di un ruolo, utilizza il seguente comando:
API IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Eliminazione di un ruolo collegato ai servizi per Amazon EMR
Se non hai più bisogno di utilizzare una funzionalità o un servizio che richiede un ruolo collegato al servizio, ti consigliamo di eliminare quel ruolo collegato al servizio. In questo modo non sarà più presente un'entità non utilizzata che non viene monitorata e gestita attivamente. Tuttavia, è necessario effettuare la pulizia delle risorse associate al ruolo collegato ai servizi prima di poterlo eliminare.
**Nota**
L'operazione di registrazione write-ahead non viene influenzata dall'eliminazione del AWSService RoleFor ruolo EMRWAL, ma Amazon EMR non eliminerà automaticamente i log che ha creato una volta terminato il cluster EMR. Pertanto, dovrai eliminare manualmente i log WAL di Amazon EMR se elimini il ruolo collegato al servizio.
### Pulizia di un ruolo collegato ai servizi
Prima di utilizzare IAM per eliminare un ruolo collegato ai servizi, devi innanzitutto verificare che il ruolo non abbia sessioni attive ed eliminare tutte le risorse utilizzate dal ruolo.
**Per verificare se il ruolo collegato ai servizi dispone di una sessione attiva nella console IAM**
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**. Seleziona il nome (non la casella di controllo) del ruolo EMRWAL. AWSService RoleFor
1. Nella pagina **Summary (Riepilogo)** per il ruolo selezionato, scegli **Access Advisor (Consulente accessi)**.
1. Nella scheda **Access Advisor (Consulente accessi)** esaminare l'attività recente per il ruolo collegato ai servizi.
**Nota**
Se non sei sicuro che Amazon EMR stia utilizzando AWSService RoleFor il ruolo EMRWAL, puoi provare a eliminare il ruolo collegato al servizio. Se il servizio utilizza il ruolo, l'eliminazione non riesce e puoi visualizzare le regioni in cui viene utilizzato il ruolo collegato al servizio. Se viene utilizzato il ruolo collegato al servizio, è necessario attendere il termine della sessione prima di poter eliminare il ruolo collegato al servizio. Non puoi revocare la sessione per un ruolo collegato al servizio.
**Per rimuovere le risorse Amazon EMR utilizzate dall'EMRWAL AWSService RoleFor**
+ Chiudi tutti i cluster del tuo account. Per ulteriori informazioni, consulta [Termina un cluster Amazon EMR nello stato di avvio, in esecuzione o in attesa](UsingEMR_TerminateJobFlow.md).
### Eliminazione di un ruolo collegato ai servizi (console IAM)
È possibile utilizzare la console IAM per eliminare un ruolo collegato ai servizi.
**Per eliminare un ruolo collegato ai servizi (console)**
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**. Seleziona la casella di controllo accanto a AWSService RoleFor EMRWAL, non il nome o la riga stessa.
1. In operazioni **Role (Ruolo)** nella parte superiore della pagina, seleziona **Delete (Elimina)** ruolo.
1. Nella finestra di dialogo di conferma, esamina i dati dell'ultimo accesso al servizio, che mostrano l'ultima volta che ciascuno dei ruoli selezionati ha effettuato l'ultimo accesso a un AWS servizio. In questo modo potrai verificare se il ruolo è attualmente attivo. Per procedere, seleziona **Yes, Delete** (Sì, elimina).
1. Controlla le notifiche della console IAM per monitorare lo stato dell'eliminazione del ruolo collegato ai servizi. Poiché l'eliminazione del ruolo collegato ai servizi IAM è asincrona, una volta richiesta l'eliminazione del ruolo, il task di eliminazione può essere eseguito correttamente o meno. Se il task non viene eseguito correttamente, puoi scegliere **View details (Visualizza dettagli)** o **View Resources (Visualizza risorse)** dalle notifiche per capire perché l'eliminazione non è stata effettuata. Se l'eliminazione non viene eseguita perché vi sono risorse nel servizio che sono usate dal ruolo, il motivo dell'errore include un elenco di risorse.
### Eliminazione di un ruolo collegato ai servizi (CLI IAM)
Puoi utilizzare i comandi IAM di AWS Command Line Interface per eliminare un ruolo collegato al servizio. Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata.
**Per eliminare un ruolo collegato ai servizi (CLI)**
1. Per controllare lo stato dell'attività di eliminazione, devi acquisire il `deletion-task-id` dalla risposta. Per inviare una richiesta di eliminazione per un ruolo collegato ai servizi, digita il seguente comando:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRWAL
```
1. Digita il seguente comando per verificare lo stato del task di eliminazione:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
### Eliminazione di un ruolo collegato ai servizi (API IAM)
È possibile utilizzare l'API IAM per eliminare un ruolo collegato ai servizi. Poiché un ruolo collegato ai servizi non può essere eliminato se è in uso o se a esso sono associate delle risorse, occorre inviare una richiesta di eliminazione. Se queste condizioni non sono soddisfatte, la richiesta può essere rifiutata.
**Per eliminare un ruolo collegato ai servizi (API)**
1. Per inviare una richiesta di eliminazione per un ruolo collegato al servizio, chiama. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Nella richiesta, specificare il nome del ruolo AWSService RoleFor EMRWAL.
Per controllare lo stato dell'attività di eliminazione, devi acquisire il `DeletionTaskId` dalla risposta.
1. Chiamare [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) per controllare lo stato dell'eliminazione. Nella richiesta, specificare il `DeletionTaskId`.
Lo stato di un task di eliminazione può essere `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`o `FAILED`. Se l'eliminazione non viene eseguita correttamente, la chiamata restituisce il motivo dell'errore per consentire all'utente di risolvere il problema.
## Regioni supportate per EMRWAL AWSService RoleFor
Amazon EMR supporta l'utilizzo del ruolo collegato AWSService RoleFor al servizio EMRWAL nelle seguenti regioni.
****
| Nome della Regione | Identità della Regione | Supporto in Amazon EMR |
| --- | --- | --- |
| Stati Uniti orientali (Virginia settentrionale) | us-east-1 | Sì |
| Stati Uniti orientali (Ohio) | us-east-2 | Sì |
| Stati Uniti occidentali (California settentrionale) | us-west-1 | Sì |
| Stati Uniti occidentali (Oregon) | us-west-2 | Sì |
| Asia Pacifico (Mumbai) | ap-south-1 | Sì |
| Asia Pacifico (Singapore) | ap-southeast-1 | Sì |
| Asia Pacifico (Sydney) | ap-southeast-2 | Sì |
| Asia Pacifico (Tokyo) | ap-northeast-1 | Sì |
| Europa (Francoforte) | eu-central-1 | Sì |
| Europa (Irlanda) | eu-west-1 | Sì |
# Personalizza i ruoli IAM con Amazon EMR
È possibile personalizzare il ruolo del servizio IAM e le autorizzazioni per limitare i privilegi in base ai requisiti di sicurezza. Per personalizzare le autorizzazioni, si consiglia di creare nuovi ruoli e policy. Iniziare con le autorizzazioni nelle policy gestite per i ruoli predefiniti (ad esempio, `AmazonElasticMapReduceforEC2Role` e `AmazonElasticMapReduceRole`). Quindi, copiare e incollare il contenuto in nuove istruzione della policy, modificare le autorizzazioni come appropriato e collegare le policy di autorizzazione modificate ai ruoli creati. È necessario disporre delle autorizzazioni IAM appropriate per lavorare con i ruoli e le policy. Per ulteriori informazioni, consulta [Consentire a utenti e gruppi di creare e modificare i ruoli](emr-iam-roles-create-permissions.md).
Se crei un ruolo EMR personalizzato per EC2, segui il flusso di lavoro di base che crea automaticamente un profilo di istanza con lo stesso nome. Amazon EC2 consente di creare profili di istanza e ruoli con nomi diversi, ma Amazon EMR non supporta questa configurazione e genera l'errore "invalid instance profile (profilo di istanza non valido)" quando crei il cluster.
**Importante**
Le policy in linea non vengono aggiornate automaticamente quando i requisiti di servizio cambiano. Se si creano e si collegano policy in linea, occorre tenere presente che potrebbero verificarsi aggiornamenti del servizio responsabili di errori di autorizzazione imprevisti. Per ulteriori informazioni, consulta la sezione relativa a [Policy gestite e policy inline](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_managed-vs-inline.html) nella *Guida per l'utente IAM* e [Specifica dei ruoli IAM personalizzati durante la creazione di un cluster](#emr-iam-roles-launch-jobflow).
Per ulteriori informazioni sull'utilizzo dei ruoli IAM, consulta i seguenti argomenti nella *Guida per l'utente IAM*:
+ [Creazione di un ruolo per delegare le autorizzazioni a un servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)
+ [Modifica di un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/modifying-role.html)
+ [Eliminazione di un ruolo](https://docs.aws.amazon.com/IAM/latest/UserGuide/deleting-roles.html)
## Specifica dei ruoli IAM personalizzati durante la creazione di un cluster
Quando crei un cluster, devi specificare il ruolo di servizio per Amazon EMR e il ruolo per il profilo dell'istanza Amazon EC2. L'utente che crea i cluster ha bisogno delle autorizzazione per recuperare e assegnare i ruoli ad Amazon EMR e alle istanze EC2. In caso contrario, viene visualizzato un errore **Account utente non autorizzato a effettuare la chiamata EC2**. Per ulteriori informazioni, consulta [Consentire a utenti e gruppi di creare e modificare i ruoli](emr-iam-roles-create-permissions.md).
### Utilizzo della console per specificare i ruoli personalizzati
Quando si crea un cluster, è possibile specificare un ruolo di servizio personalizzato per Amazon EMR, un ruolo personalizzato per il profilo dell'istanza EC2 e un ruolo Auto Scaling personalizzato utilizzando **Advanced options (Opzioni avanzate)**. Quando si utilizzano le **Quick options (Opzioni rapide)**, il ruolo di servizio e il ruolo predefinito per il profilo di istanza EC2 sono specificati. Per ulteriori informazioni, consulta [Ruoli di servizio IAM utilizzati da Amazon EMR](emr-iam-service-roles.md).
------
#### [ Console ]
**Per specificare ruoli IAM personalizzati con la console**
Quando crei un cluster con la console, devi specificare un ruolo di servizio personalizzato per Amazon EMR e un ruolo personalizzato per il profilo dell'istanza EC2. Per ulteriori informazioni, consulta [Ruoli di servizio IAM utilizzati da Amazon EMR](emr-iam-service-roles.md).
1. [Accedi a e apri Console di gestione AWS la console Amazon EMR su https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. In **EMR on EC2** (EMR su EC2), nel riquadro di navigazione a sinistra, scegli **Clusters** (Cluster) e seleziona **Create cluster** (Crea cluster).
1. In **Security configuration and permissions** (Configurazione e autorizzazioni di sicurezza), cerca i campi **IAM role for instance profile** (Ruolo IAM per il profilo dell'istanza) e **Service role for Amazon EMR** (Ruolo di servizio per i campi Amazon EMR). Per ogni tipo di ruolo, selezionare un ruolo dall'elenco. Vengono elencati solo i ruoli all'interno dell'account che dispongono della policy di affidabilità appropriata per quel tipo di ruolo.
1. Scegli qualsiasi altra opzione applicabile al cluster.
1. Per avviare il cluster, scegli **Create cluster** (Crea cluster).
------
### Usa il per specificare AWS CLI ruoli personalizzati
È possibile specificare un ruolo di servizio per Amazon EMR e un ruolo di servizio per le istanze EC2 del cluster esplicitamente utilizzando le opzioni con il comando `create-cluster` da AWS CLI. L'opzione `--service-role` consente di specificare il ruolo di servizio. Utilizzare l'argomento `InstanceProfile` dell'opzione `--ec2-attributes` per specificare il ruolo del profilo dell'istanza EC2.
Il ruolo Auto Scaling viene specificato mediante un'opzione distinta, `--auto-scaling-role`. Per ulteriori informazioni, consulta [Utilizzo del ridimensionamento automatico con una politica personalizzata, ad esempio gruppi in Amazon EMR](emr-automatic-scaling.md).
**Per specificare ruoli IAM personalizzati utilizzando il AWS CLI**
+ Il comando seguente specifica il ruolo del servizio personalizzato, *MyCustomServiceRoleForEMR*, e un ruolo personalizzato per il profilo dell'istanza EC2, *MyCustomServiceRoleForClusterEC2Instances*, quando si avvia un cluster. Questo esempio utilizza il ruolo Amazon EMR predefinito.
**Nota**
I caratteri di continuazione della riga Linux (\$1) sono inclusi per la leggibilità. Possono essere rimossi o utilizzati nei comandi Linux. Per Windows, rimuoverli o sostituirli con un accento circonflesso (^).
```
aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 \
--applications Name=Hive Name=Pig --service-role MyCustomServiceRoleForEMR \
--ec2-attributes InstanceProfile=MyCustomServiceRoleForClusterEC2Instances,\
KeyName=myKey --instance-type m5.xlarge --instance-count 3
```
È possibile utilizzare queste opzioni per specificare esplicitamente i ruoli predefiniti anziché utilizzare l'opzione `--use-default-roles`. L'opzione `--use-default-roles` specifica il ruolo del servizio e il ruolo per il profilo dell'istanza EC2 definito nel file `config` per l' AWS CLI.
L'esempio seguente mostra il contenuto di un `config` file per AWS CLI i ruoli personalizzati specificati per Amazon EMR. Con questo file di configurazione, quando viene specificata l'opzione `--use-default-roles`, il cluster viene creato utilizzando *MyCustomServiceRoleForEMR* e *MyCustomServiceRoleForClusterEC2Instances*. Per impostazione predefinita, il file `config` specifica l'impostazione predefinita `service_role` come `AmazonElasticMapReduceRole` e l'impostazione predefinita `instance_profile` come `EMR_EC2_DefaultRole`.
```
[default]
output = json
region = us-west-1
aws_access_key_id = myAccessKeyID
aws_secret_access_key = mySecretAccessKey
emr =
service_role = MyCustomServiceRoleForEMR
instance_profile = MyCustomServiceRoleForClusterEC2Instances
```
# Configurazione di ruoli IAM per le richieste EMRFS ad Amazon S3
**Nota**
La funzionalità di mappatura dei ruoli EMRFS descritta in questa pagina è stata migliorata con l'introduzione di Amazon S3 Access Grants in Amazon EMR 6.15.0. Per una soluzione scalabile di controllo degli accessi per i tuoi dati in Amazon S3, ti consigliamo di [utilizzare S3 Access Grants con Amazon EMR](emr-access-grants.md).
Quando un'applicazione in esecuzione su un cluster fa riferimento ai dati utilizzando il formato `s3://mydata`, Amazon EMR utilizza EMRFS per effettuare la richiesta. Per interagire con Amazon S3, EMRFS assume le policy di autorizzazione associate al [Profilo dell'istanza Amazon EC2](emr-iam-role-for-ec2.md). Lo stesso profilo dell'istanza Amazon EC2 viene utilizzato indipendentemente dall'utente o dal gruppo che esegue l'applicazione o dalla posizione dei dati in Amazon S3.
Se si dispone di un cluster con più utenti che necessitano di diversi livelli di accesso ai dati in Amazon S3 tramite EMRFS, è possibile impostare una configurazione della sicurezza con i ruoli IAM per EMRFS. EMRFS può assumere un ruolo di servizio per le istanze EC2 del cluster differente in base all'utente o al gruppo da cui proviene la richiesta o in base alla posizione di dati in Amazon S3. Ogni ruolo IAM può avere differenti autorizzazioni per l'accesso ai dati in Amazon S3. Per ulteriori informazioni sull'utilizzo dei ruoli di servizio per le istanze EC2, del cluster, consulta [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md).
L'utilizzo di ruoli IAM personalizzati per EMRFS è supportato in Amazon EMR versioni 5.10.0 e successive. Se si utilizza una versione precedente o si dispone di requisiti che i ruoli IAM per EMRFS non possono soddisfare, è possibile creare un provider di credenziali personalizzato. Per ulteriori informazioni, consulta [Autorizzazione dell'accesso ai dati EMRFS in Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider).
Quando utilizzi una configurazione di sicurezza per specificare ruoli IAM per EMRFS, configuri mappature di ruoli. Ogni mappatura di ruoli specifica un ruolo IAM che corrisponde a identificatori. Questi identificatori determinano la base per l'accesso ad Amazon S3 tramite EMRFS. Gli identificatori possono essere utenti, gruppi o prefissi Amazon S3 che indicano un percorso di dati. Quando EMRFS invia una richiesta ad Amazon S3, se la richiesta corrisponde alla base per l'accesso, EMRFS dispone delle istanze EC2 del cluster che assumono il ruolo IAM corrispondente per la richiesta. Si applicano le autorizzazioni IAM associate a tale ruolo invece delle autorizzazioni IAM collegate al ruolo di servizio per le istanze EC2 del cluster.
Gli utenti e i gruppi in una mappatura di ruoli sono utenti e gruppi Hadoop definiti nel cluster. Gli utenti e i gruppi sono passati a EMRFS nel contesto dell'applicazione che lo utilizza (ad esempio, la rappresentazione di utente YARN). Il prefisso Amazon S3 può essere un identificatore bucket di qualsiasi profondità (ad esempio, `s3://amzn-s3-demo-bucket` o `s3://amzn-s3-demo-bucket/myproject/mydata`). Puoi specificare più identificatori in una singola mappatura di ruoli, ma devono essere tutti dello stesso tipo.
**Importante**
I ruoli IAM per EMRFS forniscono l'isolamento a livello di applicazione tra gli utenti dell'applicazione. Non offrono l'isolamento a livello di host tra gli utenti sull'host. Qualsiasi utente con accesso al cluster può ignorare l'isolamento per assumere uno qualsiasi dei ruoli.
Quando un'applicazione cluster invia una richiesta ad Amazon S3 tramite EMRFS, EMRFS valuta le mappature di ruoli nell'ordine decrescente in cui sono visualizzate nella configurazione di sicurezza. Se una richiesta inviata tramite EMRFS non corrisponde ad alcun identificatore, EMRFS utilizza nuovamente il ruolo di servizio per le istanze EC2 del cluster. Per questo motivo, è consigliabile che le policy associate a questo ruolo limitino le autorizzazioni per Amazon S3. Per ulteriori informazioni, consulta [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md).
## Configurazione dei ruoli
Prima di impostare una configurazione di sicurezza con ruoli IAM per EMRFS, pianifica e crea i ruoli e le policy di autorizzazione da associare ai ruoli. Per ulteriori informazioni, consulta [Funzionamento dei ruoli per le istanze EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) nella *Guida per l'utente IAM*. Durante la creazione di policy di autorizzazione, ti consigliamo di iniziare con la policy gestita associata al ruolo Amazon EMR di default per EC2, per poi modificarla in seguito in base alle tue esigenze. Il nome del ruolo predefinito è `EMR_EC2_DefaultRole` e la policy gestita predefinita da modificare è `AmazonElasticMapReduceforEC2Role`. Per ulteriori informazioni, consulta [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md).
### Aggiornamento delle policy di affidabilità per le autorizzazioni del ruolo Assume
Ogni ruolo utilizzato da EMRFS deve avere una policy di attendibilità che consente al ruolo di Amazon EMR del cluster per EC2 di assumerlo. Analogamente, il ruolo Amazon EMR del cluster per EC2 deve avere una policy di attendibilità che consente ai ruoli EMRFS di assumerlo.
L'esempio di policy di trust riportata di seguito è collegata ai ruoli per EMRFS. L'istruzione consente al ruolo Amazon EMR predefinito per EC2 di assumere quel ruolo. Se ad esempio si dispone di due ruoli fittizi EMRFS, `EMRFSRole_First` ed `EMRFSRole_Second`, questa istruzione di policy viene aggiunta alla policy di trust per ognuno di essi.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Inoltre, la seguente istruzione per policy di trust di esempio viene aggiunta al ruolo `EMR_EC2_DefaultRole` per consentire ai due ruoli EMRFS fittizi di assumerlo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/EMRFSRole_First",
"arn:aws:iam::123456789012:role/EMRFSRole_Second"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
**Aggiornamento della policy di affidabilità di un ruolo IAM**
Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Scegliere **Roles (Ruoli)**, immettere il nome del ruolo in **Search (Cerca)**, quindi selezionare il relativo **Role name (Nome ruolo)**.
1. Scegliere **Trust relationships (Relazioni di trust)**, quindi **Edit trust relationship (Modifica relazione di trust)**.
1. Aggiungi un'istruzione di attendibilità in base a quanto riportato nel **Policy Document** (Documento di policy) secondo le linee guida in alto, quindi scegli **Update Trust Policy** (Aggiorna policy di attendibilità).
### Indicazione di un ruolo come utente chiave
Se un ruolo autorizza l'accesso a una posizione in Amazon S3 crittografata mediante una AWS KMS key, assicurati che il ruolo sia specificato come utente di chiavi. Ciò concede al ruolo l'autorizzazione a utilizzare la chiave KMS. Per ulteriori informazioni, consulta [Policy delle chiavi in AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) nella *Guida per gli sviluppatori di AWS Key Management Service *.
## Impostazione di una configurazione di sicurezza con ruoli IAM per EMRFS
**Importante**
Se nessuno dei ruoli IAM per EMRFS che specifichi è applicabile, EMRFS utilizza il ruolo Amazon EMR per EC2. Valuta la possibilità di personalizzare questo ruolo per limitare le autorizzazioni per Amazon S3 come appropriato per la tua applicazione e di specificare questo ruolo personalizzato anziché `EMR_EC2_DefaultRole` quando crei un cluster. Per ulteriori informazioni, consultare [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md) e [Specifica dei ruoli IAM personalizzati durante la creazione di un cluster](emr-iam-roles-custom.md#emr-iam-roles-launch-jobflow).
**Specifica dei ruoli IAM per le richieste EMRFS ad Amazon S3 mediante la console**
1. Creare una configurazione di sicurezza che specifichi mappature di ruoli:
1. Nella console di Amazon EMR, seleziona **Security configurations (Configurazioni di sicurezza)** e **Create (Crea)**.
1. Digitare un nome in **Name (Nome)** per la configurazione di sicurezza. Questo nome è utilizzato per specificare la configurazione di sicurezza al momento della creazione di un cluster.
1. Scegli **Use IAM roles for EMRFS requests to Amazon S3 (Utilizza i ruoli IAM per le richieste EMRFS ad Amazon S3)**.
1. Seleziona un **IAM role** (Ruolo IAM) da applicare e in **Basis for access** (Base per accesso) seleziona un tipo di identificatore (**Users** [Utenti], **Groups** [Gruppi) o **S3 prefixes** [Prefissi S3]) dall'elenco e immetti gli identificatori corrispondenti. Se si utilizzano più identificatori, separarli con una virgola e senza inserire spazi. Per ulteriori informazioni su ogni tipo di identificatore, vedi [JSON configuration reference](#emrfs-seccfg-json) qui sotto.
1. Scegliere **Add role (Aggiungi ruolo)** per configurare ulteriori mappature di ruoli come descritto nella fase precedente.
1. Configurare altre opzioni per la configurazione di sicurezza come appropriato e scegliere **Create (Crea)**. Per ulteriori informazioni, consulta [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
1. Specificare la configurazione di sicurezza creata precedentemente alla creazione di un cluster. Per ulteriori informazioni, consulta [Specificare una configurazione di sicurezza per un cluster Amazon EMR](emr-specify-security-configuration.md).
**Per specificare i ruoli IAM per le richieste EMRFS ad Amazon S3 utilizzando AWS CLI**
1. Utilizzare il comando `aws emr create-security-configuration`, specificando un nome per la configurazione di sicurezza, e i dettagli relativi a tale configurazione in formato JSON.
L'esempio di comando riportato di seguito crea una configurazione di sicurezza con il nome `EMRFS_Roles_Security_Configuration`. Questa è basata su una struttura JSON nel file `MyEmrfsSecConfig.json`, che viene salvato nella stessa directory in cui viene eseguito il comando.
```
aws emr create-security-configuration --name EMRFS_Roles_Security_Configuration --security-configuration file://MyEmrFsSecConfig.json.
```
Utilizza le linee guida seguenti per la struttura del file `MyEmrFsSecConfig.json`. È possibile specificare questa struttura insieme alle strutture per altre opzioni della configurazione di sicurezza. Per ulteriori informazioni, consulta [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
Di seguito è riportato un esempio di frammento JSON per specificare ruoli IAM personalizzati per EMRFS all'interno di una configurazione di sicurezza. Vengono illustrate le mappature dei ruoli per i tre diversi tipi di identificatori, seguite da un riferimento ai parametri.
```
{
"AuthorizationConfiguration": {
"EmrFsConfiguration": {
"RoleMappings": [{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_user1",
"IdentifierType": "User",
"Identifiers": [ "user1" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_to_demo_s3_buckets",
"IdentifierType": "Prefix",
"Identifiers": [ "s3://amzn-s3-demo-bucket1/","s3://amzn-s3-demo-bucket2/" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_AdminGroup",
"IdentifierType": "Group",
"Identifiers": [ "AdminGroup" ]
}]
}
}
}
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html)
1. Utilizzare il comando `aws emr create-cluster` per creare un cluster e specificare la configurazione di sicurezza creata nella fase precedente.
L'esempio seguente crea un cluster con le principali applicazioni Hadoop di default installate. Il cluster utilizza la configurazione di sicurezza creata in precedenza come `EMRFS_Roles_Security_Configuration` e un ruolo Amazon EMR personalizzato per EC2, `EC2_Role_EMR_Restrict_S3`, specificato utilizzando l'argomento `InstanceProfile` del parametro `--ec2-attributes`.
**Nota**
I caratteri di continuazione della riga Linux (\$1) sono inclusi per questioni di leggibilità. Possono essere rimossi o utilizzati nei comandi Linux. Per Windows, rimuovili o sostituiscili con un accento circonflesso (^).
```
aws emr create-cluster --name MyEmrFsS3RolesCluster \
--release-label emr-7.12.0 --ec2-attributes InstanceProfile=EC2_Role_EMR_Restrict_S3,KeyName=MyKey \
--instance-type m5.xlarge --instance-count 3 \
--security-configuration EMRFS_Roles_Security_Configuration
```
# Utilizza politiche basate sulle risorse per l'accesso di Amazon EMR a Glue Data Catalog AWS
Se utilizzi AWS Glue insieme a Hive, Spark o Presto in Amazon EMR, AWS Glue supporta politiche basate sulle risorse per controllare l'accesso alle risorse del Data Catalog. Queste risorse includono tabelle, database, connessioni e funzioni definite dall'utente. Per ulteriori informazioni, consulta [Policy sulle risorse AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/glue-resource-policies.html) nella *Guida per gli sviluppatori di AWS Glue*.
Quando si utilizzano policy basate sulle risorse per limitare l'accesso a AWS Glue dall'interno di Amazon EMR, il principio specificato nella politica delle autorizzazioni deve essere il ruolo ARN associato al profilo dell'istanza EC2 specificato al momento della creazione di un cluster. Ad esempio, per una politica basata sulle risorse allegata a un catalogo, puoi specificare il ruolo ARN per il ruolo di servizio predefinito per le istanze EC2 del cluster, *EMR\$1EC2\$1DefaultRole* come`Principal`, utilizzando il formato mostrato nell'esempio seguente:
```
arn:aws:iam::acct-id:role/EMR_EC2_DefaultRole
```
*acct-id*Può essere diverso dall'ID dell'account AWS Glue. Ciò consente l'accesso da cluster EMR in account diversi. Puoi specificare più entità principali, ognuna da un account diverso.
# Usa i ruoli IAM con applicazioni che chiamano direttamente AWS i servizi
Le applicazioni in esecuzione sulle istanze EC2 di un cluster possono utilizzare il profilo dell'istanza EC2 per ottenere credenziali di sicurezza temporanee quando chiamano i servizi. AWS
Le versioni di Hadoop disponibili con Amazon EMR versione 2.3.0 e successive sono già state aggiornate per l'utilizzo di ruoli IAM. Se l'applicazione viene eseguita esclusivamente sull'architettura Hadoop e non richiama direttamente alcun servizio, dovrebbe funzionare con i ruoli AWS IAM senza alcuna modifica.
Se l'applicazione richiama AWS direttamente i servizi, è necessario aggiornarla per sfruttare i ruoli IAM. Ciò significa che invece di ottenere le credenziali dell'account da `/etc/hadoop/conf/core-site.xml` sulle istanze EC2 nel cluster, l'applicazione utilizza un SDK per accedere alle risorse utilizzando ruoli IAM o richiama i metadati dell'istanza EC2 per ottenere le credenziali temporanee.
**Per accedere alle AWS risorse con ruoli IAM utilizzando un SDK**
+ I seguenti argomenti mostrano come utilizzare diversi di essi per accedere AWS SDKs a credenziali temporanee utilizzando i ruoli IAM. Ogni argomento inizia con una versione di un'applicazione che non utilizza ruoli IAM e poi guida attraverso il processo di conversione di quell'applicazione per utilizzare ruoli IAM.
+ [Utilizzo dei ruoli IAM per le istanze Amazon EC2 con SDK per Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) nella *Guida per gli sviluppatori di AWS SDK per Java *
+ [Utilizzo dei ruoli IAM per le istanze Amazon EC2 con SDK per .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-roles.html) nella *Guida per gli sviluppatori di AWS SDK per .NET *
+ [Utilizzo dei ruoli IAM per le istanze Amazon EC2 con SDK per PHP](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/php-dg-roles.html) nella *Guida per gli sviluppatori di AWS SDK per PHP *
+ [Utilizzo dei ruoli IAM per le istanze Amazon EC2 con SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ruby-dg-roles.html) nella *Guida per gli sviluppatori di AWS SDK per Ruby *
**Per ottenere le credenziali provvisorie dai metadati dell'istanza EC2**
+ Richiama il seguente URL da un'istanza EC2 in esecuzione con il ruolo IAM specificato, che restituisce le credenziali di sicurezza temporanee associate (AccessKeyId SecretAccessKey SessionToken, e Scadenza). L'esempio seguente utilizza il profilo istanza predefinito per Amazon EMR, `EMR_EC2_DefaultRole`.
```
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/EMR_EC2_DefaultRole
```
Per ulteriori informazioni sulla scrittura di applicazioni che utilizzano ruoli IAM, consulta [Garantire l'accesso alle risorse alle applicazioni eseguite su istanze Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html). AWS
Per ulteriori informazioni sulle credenziali di sicurezza temporanee, consulta [Utilizzo delle credenziali di sicurezza temporanee](https://docs.aws.amazon.com/STS/latest/UsingSTS/using-temp-creds.html) nella *Guida all'utilizzo di credenziali di sicurezza temporanee*.
# Consentire a utenti e gruppi di creare e modificare i ruoli
Le entità principali (utenti e gruppi) IAM che creano, modificano e specificano i ruoli per un cluster, inclusi i ruoli predefiniti, devono essere autorizzate a eseguire le seguenti operazioni. Per ulteriori informazioni su ciascuna operazione, consulta [Actions (Operazioni)](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) nella *Guida di riferimento alle API di IAM*.
+ `iam:CreateRole`
+ `iam:PutRolePolicy`
+ `iam:CreateInstanceProfile`
+ `iam:AddRoleToInstanceProfile`
+ `iam:ListRoles`
+ `iam:GetPolicy`
+ `iam:GetInstanceProfile`
+ `iam:GetPolicyVersion`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
L'autorizzazione `iam:PassRole` consente la creazione del cluster. Le restanti autorizzazioni consentono la creazione di ruoli predefiniti.
Per ulteriori informazioni sull'assegnazione di autorizzazioni a un utente IAM, consulta [Modifica delle autorizzazioni per un utente](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) nella *Guida per l'utente IAM*.
# Esempi di policy basate su identità per Amazon EMR
Per impostazione predefinita, gli utenti e i ruoli non dispongono dell'autorizzazione per creare o modificare risorse Amazon EMR. Inoltre, non possono eseguire attività utilizzando l'API Console di gestione AWS, AWS CLI, o. AWS Un amministratore IAM deve creare policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore deve quindi collegare queste policy a utenti o gruppi che richiedono tali autorizzazioni.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consultare [Creazione di policy nella scheda JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) nella *Guida per l'utente IAM*.
**Topics**
+ [Best practice delle policy per Amazon EMR](security_iam_service-with-iam-policy-best-practices.md)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Policy gestite da Amazon EMR](emr-managed-iam-policies.md)
+ [Policy IAM per l'accesso basato su tag ai cluster e a EMR Notebooks](emr-fine-grained-cluster-access.md)
+ [Negare l' ModifyInstanceGroup azione in Amazon EMR](emr-cluster-deny-modifyinstancegroup.md)
+ [Risoluzione dei problemi relativi all'identità e all'accesso di Amazon EMR](security_iam_troubleshoot.md)
# Best practice delle policy per Amazon EMR
Le policy basate su identità sono molto efficaci. Determinano se qualcuno può creare, accedere o eliminare risorse Amazon EMR nell'account. Queste azioni possono comportare costi per il tuo AWS account. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia a usare le policy AWS gestite**: per iniziare a usare Amazon EMR rapidamente, utilizza policy AWS gestite per concedere ai dipendenti le autorizzazioni di cui hanno bisogno. Queste policy sono già disponibili nell'account e sono gestite e aggiornate da AWS. Per ulteriori informazioni, consulta [Introduzione all'utilizzo delle autorizzazioni con policy AWS gestite](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) nella Guida per l'*utente IAM* e. [Policy gestite da Amazon EMR](emr-managed-iam-policies.md)
+ **Assegnare il privilegio minimo**: quando si creano policy personalizzate, concedere solo le autorizzazioni richieste per eseguire un'attività. Inizia con un set di autorizzazioni minimo e concedi autorizzazioni aggiuntive quando necessario. Questo è più sicuro che iniziare con autorizzazioni che siano troppo permissive e cercare di limitarle in un secondo momento. Per ulteriori informazioni, consulta [Assegnare il privilegio minimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) nella *Guida per l'utente IAM*.
+ **Abilitare MFA per operazioni sensibili**: per una maggiore sicurezza, richiedere agli utenti di utilizzare l'autenticazione a più fattori (MFA) per accedere a risorse sensibili o operazioni API. Per ulteriori informazioni, consulta [Utilizzo dell'autenticazione a più fattori (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) nella *Guida per l'utente IAM*.
+ **Utilizzare le condizioni della policy per ulteriore sicurezza** – Per quanto possibile, definire le condizioni in cui le policy basate su identità consentono l'accesso a una risorsa. Ad esempio, è possibile scrivere condizioni per specificare un intervallo di indirizzi IP consentiti dai quali deve provenire una richiesta. È anche possibile scrivere condizioni per consentire solo le richieste all'interno di un intervallo di date o ore specificato oppure per richiedere l'utilizzo di SSL o MFA. Per ulteriori informazioni, consulta [Elementi delle policy JSON di IAM: Condizioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l'utente IAM*.
# Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa policy include le autorizzazioni per completare questa azione sulla console o utilizzando l'API or a livello di codice. AWS CLI AWS
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListUserPolicies"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListUsers"
],
"Resource": [
"*"
]
}
]
}
```
------
# Policy gestite da Amazon EMR
Il modo più semplice di concedere accesso completo o in sola lettura alle operazioni di Amazon EMR necessarie è utilizzare le policy gestite da IAM per Amazon EMR. Le policy gestite offrono il vantaggio di essere aggiornate automaticamente nel momento in cui i requisiti di autorizzazione cambiano. Se utilizzi policy inline, è possibile che si verifichino degli errori di autorizzazione in caso di modifiche al servizio.
Amazon EMR renderà obsolete le policy gestite esistenti (policy v1), a favore di nuove policy gestite (policy v2). Le nuove politiche gestite sono state ridotte per allinearle alle migliori pratiche. AWS Dopo che le policy gestite v1 renderà obsolete, non sarà possibile allegare queste policy a nuovi ruoli o utenti IAM. I ruoli e gli utenti esistenti che utilizzano policy obsolete possono continuare a utilizzarli. Le policy gestite v2 limitano l'accesso utilizzando i tag. Consentono solo operazioni Amazon EMR specifiche e richiedono risorse cluster contrassegnate con una chiave specifica per EMR. Si consiglia di esaminare attentamente la documentazione prima di utilizzare le nuove policy v2.
Le policy v1 verranno contrassegnate come obsolete con un'icona di avviso accanto a esse nell'elenco **Policies (Policy)** della console IAM. Le policy obsolete avranno le seguenti caratteristiche:
+ Continuano a funzionare per tutti gli utenti, gruppi e ruoli attualmente collegati. Nessuna interruzione.
+ Non possono essere collegate a nuovi utenti, gruppi o ruoli. Se una delle policy viene scollegata da un'entità corrente, non è possibile collegarla nuovamente.
+ Dopo aver scollegato una policy v1 da tutte le entità correnti, la policy non sarà più visibile e non potrà essere utilizzata.
Nella tabella seguente sono riepilogate le modifiche tra le policy correnti (v1) e le policy v2.
**Modifiche alle policy gestite da Amazon EMR**
| Tipo di policy | Nomi delle policy | Scopo della policy | Modifiche alla policy v2 |
| --- | --- | --- | --- |
| Ruolo di servizio EMR predefinito e policy gestita collegata | Nome del ruolo: **EMR\$1 DefaultRole** Criterio V1 (da rendere obsoleto): (ruolo del servizio **AmazonElasticMapReduceRole**EMR) Nome della policy v2 (con ambito): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Consente ad Amazon EMR di chiamare altri AWS servizi per tuo conto durante il provisioning di risorse e l'esecuzione di azioni a livello di servizio. Questo ruolo è obbligatorio per tutti i cluster. | La policy aggiunge la nuova autorizzazione. `"ec2:DescribeInstanceTypeOfferings"` Questa operazione API restituisce un elenco di tipi di istanze supportati da un elenco di determinate zone di disponibilità. |
| Policy gestita da IAM per l'accesso completo ad Amazon EMR per utente, ruolo o gruppo collegato | Nome della policy V2 (con ambito): [`AmazonEMRServicePolicy_v2`](emr-managed-policy-fullaccess-v2.md) | Consente agli utenti autorizzazioni complete per le operazioni EMR. Include iam: PassRole autorizzazioni per le risorse. | La policy aggiunge il prerequisito secondo cui gli utenti devono aggiungere tag utente alle risorse prima di poter utilizzare questa policy. Per informazioni, consulta [Assegnazione di tag alle risorse per l'utilizzo delle policy gestite](#manually-tagged-resources). iam: PassRole l'azione richiede iam: PassedToService condizione impostata sul servizio specificato. L'accesso ad Amazon EC2, Amazon S3 e ad altri servizi non è consentito per impostazione predefinita. Consulta [Policy IAM gestita per l'accesso completo (policy predefinita gestita v2)](emr-managed-policy-fullaccess-v2.md). |
| Policy IAM gestita per un accesso di sola lettura parte di utente, ruolo o gruppo collegato | Policy V1 (da essere resa obsoleta): [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) Nome della policy V2 (con ambito): [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) | Consente agli utenti autorizzazioni di sola lettura per le operazioni di Amazon EMR. | Le autorizzazioni si riferiscono esclusivamente alle operazioni elasticmapreduce di sola lettura specificate. Per impostazione predefinita, l'accesso ad Amazon S3 non è consentito. Consulta [Policy IAM gestita per l'accesso di sola lettura (policy predefinita gestita v2)](emr-managed-policy-readonly-v2.md). |
| Ruolo di servizio EMR predefinito e policy gestita collegata | Nome del ruolo: **EMR\$1 DefaultRole** Criterio V1 (da rendere obsoleto): (ruolo del servizio **AmazonElasticMapReduceRole**EMR) Nome della policy v2 (con ambito): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Consente ad Amazon EMR di chiamare altri AWS servizi per tuo conto durante il provisioning di risorse e l'esecuzione di azioni a livello di servizio. Questo ruolo è obbligatorio per tutti i cluster. | Il ruolo di servizio v2 e la policy predefinita v2 sostituiscono il ruolo e la policy obsoleti. La policy aggiunge il prerequisito secondo cui gli utenti devono aggiungere tag utente alle risorse prima di poter utilizzare questa policy. Per informazioni, consulta [Assegnazione di tag alle risorse per l'utilizzo delle policy gestite](#manually-tagged-resources). Per informazioni, consulta [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md). |
| Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2) | **Nome del ruolo: EMR\$1 \$1 EC2 DefaultRole** **Nome della politica obsoleto: Role AmazonElasticMapReducefor EC2** | Consente alle applicazioni in esecuzione su un cluster EMR di accedere ad altre risorse AWS , ad esempio Amazon S3. Ad esempio, se esegui i processi Apache Spark che elaborano i dati da Amazon S3, la policy deve consentire l'accesso a tali risorse. | Sia il ruolo predefinito che la policy predefinita diventeranno presto obsoleti. Non esiste un ruolo o una politica gestiti AWS predefiniti sostitutivi. È necessario fornire una policy basata su risorse o su identità. Ciò significa che, per impostazione predefinita, le applicazioni in esecuzione su un cluster EMR non hanno accesso ad Amazon S3 o ad altre risorse a meno che non vengano aggiunte manualmente alla policy. Per informazioni, consulta [Ruolo predefinito e policy gestita](emr-iam-role-for-ec2.md#emr-ec2-role-default). |
| Altre policy del ruolo di servizio EC2 | Nomi delle politiche attuali: **AmazonElasticMapReduceforAutoScalingRole, AmazonElasticMapReduceEditorsRole, Amazon EMRCleanup Policy** | Fornisce le autorizzazioni necessarie ad Amazon EMR per accedere ad AWS altre risorse ed eseguire azioni se si utilizza la scalabilità automatica, i notebook o per ripulire le risorse EC2. | Nessuna modifica per v2. |
## Proteggere lo scopo: PassRole
Le policy gestite predefinite con autorizzazioni complete di Amazon EMR incorporano configurazioni di sicurezza `iam:PassRole`, tra cui:
+ Autorizzazioni `iam:PassRole` solo per specifici ruoli Amazon EMR predefiniti.
+ `iam:PassedToService`condizioni che consentono di utilizzare la politica solo con AWS servizi specifici, come `elasticmapreduce.amazonaws.com` e`ec2.amazonaws.com`.
Puoi visualizzare la versione JSON delle policy Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) nella console IAM. Ti consigliamo di creare i nuovi cluster con le policy gestite v2.
Per creare policy personalizzate, ti consigliamo di iniziare con le policy gestite e di modificarle in base alle tue esigenze.
Per informazioni su come collegare policy a utenti (entità principali), consulta [Utilizzo di policy gestite mediante la Console di gestione AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#policies_using-managed-console) nella *Guida per l'utente IAM*.
## Assegnazione di tag alle risorse per l'utilizzo delle policy gestite
**Amazon EMRService Policy\$1v2** e **EMRFullAccessPolicyAmazon** \$1v2 dipendono dall'accesso limitato alle risorse fornite o utilizzate da Amazon EMR. L'ambito inferiore si ottiene limitando l'accesso solo a quelle risorse a cui è associato un tag utente predefinito. Quando si utilizza una di queste due policy, è necessario passare il tag utente predefinito `for-use-with-amazon-emr-managed-policies = true` durante il provisioning del cluster. Amazon EMR propaga automaticamente tale tag. Inoltre, è necessario aggiungere un tag utente alle risorse elencate nella sezione seguente. Se utilizzi la console Amazon EMR per avviare il cluster, consulta la sezione [Considerazioni sull'utilizzo della console Amazon EMR per avviare cluster con policy gestite v2](#emr-cluster-v2policy-awsconsole-launch).
Per utilizzare le policy gestite, passa il tag utente `for-use-with-amazon-emr-managed-policies = true` durante il provisioning di un cluster con la CLI, l'SDK o un altro metodo.
Quando si passa il tag, Amazon EMR propaga il tag all'ENI della sottorete privata, all'istanza EC2 e ai volumi EBS creati. Amazon EMR assegna automaticamente tag anche ai gruppi di sicurezza creati. Tuttavia, se desideri che Amazon EMR venga avviato con un determinato gruppo di sicurezza, devi taggarlo. Per le risorse che non sono state create da Amazon EMR, è necessario aggiungere i tag a tali risorse. Ad esempio, devi etichettare le sottoreti Amazon EC2, i gruppi di sicurezza EC2 (se non creati da Amazon EMR) e (se VPCs desideri che Amazon EMR crei gruppi di sicurezza). Per avviare cluster con policy gestite v2 VPCs, devi etichettarli con il tag utente predefinito. VPCs Per informazioni, consultare [Considerazioni sull'utilizzo della console Amazon EMR per avviare cluster con policy gestite v2](#emr-cluster-v2policy-awsconsole-launch).
**Assegnazione di tag propagata specificata dall'utente**
Amazon EMR contrassegna le risorse create utilizzando i tag Amazon EMR specificati durante la creazione di un cluster. Amazon EMR applica tag alle risorse create durante il ciclo di vita del cluster.
Amazon EMR propaga i tag utente per le seguenti risorse:
+ ENI della sottorete privata (interfacce di rete elastiche di accesso ai servizi)
+ Istanze EC2
+ Volumi EBS
+ Modello di avvio di EC2
**Gruppi di sicurezza con tag automatici**
Amazon EMR tagga i gruppi di sicurezza EC2 creati con il tag richiesto per le policy gestite v2 per Amazon EMR, `for-use-with-amazon-emr-managed-policies`, indipendentemente dai tag specificati nel comando di creazione del cluster. Per un gruppo di sicurezza creato prima dell'introduzione delle policy gestite v2, Amazon EMR non tagga automaticamente il gruppo di sicurezza. Se si desidera utilizzare policy gestite v2 con i gruppi di sicurezza predefiniti già esistenti nell'account, è necessario taggare manualmente i gruppi di sicurezza con `for-use-with-amazon-emr-managed-policies = true`.
**Risorse cluster con tag manuali**
Occorre taggare manualmente alcune risorse del cluster in modo che possano essere accessibili dai ruoli predefiniti di Amazon EMR.
+ Occorre taggare manualmente i gruppi di sicurezza EC2 e le sottoreti EC2 con il tag `for-use-with-amazon-emr-managed-policies` della policy gestita da Amazon EMR.
+ Occorre taggare manualmente un VPC se vuoi che Amazon EMR crei gruppi di sicurezza predefiniti. EMR tenterà di creare un gruppo di sicurezza con il tag specifico se il gruppo di sicurezza predefinito non esiste già.
Amazon EMR tagga automaticamente le seguenti risorse:
+ Gruppi di sicurezza EC2 creati da EMR
È necessario aggiungere i tag manualmente alle risorse seguenti:
+ Sottorete EC2
+ Gruppo di sicurezza EC2
È necessario taggare manualmente le risorse seguenti:
+ VPC: solo quando si desidera che Amazon EMR crei gruppi di sicurezza
## Considerazioni sull'utilizzo della console Amazon EMR per avviare cluster con policy gestite v2
Puoi eseguire il provisioning di cluster con policy gestite v2 utilizzando la console Amazon EMR. Di seguito sono riportate alcune considerazioni quando utilizzi la console per avviare cluster Amazon EMR.
+ Non è necessario passare il tag predefinito. Amazon EMR aggiunge automaticamente il tag e lo propaga ai componenti appropriati.
+ Per i componenti che devono essere taggati manualmente, la vecchia console Amazon EMR tenta di applicare automaticamente i tag se disponi delle autorizzazioni necessarie per taggare le risorse. Se non disponi delle autorizzazioni per etichettare le risorse o se desideri utilizzare la console, chiedi all'amministratore di taggare tali risorse.
+ Non è possibile avviare cluster con policy gestite v2 a meno che non siano soddisfatti tutti i prerequisiti.
+ La vecchia console Amazon EMR mostra quali risorse (VPC/sottorete) devono essere taggate.
# Policy gestita da IAM per l'accesso completo (policy predefinita gestita v2) per Amazon EMR
Le policy predefinite gestite da EMR con ambito v2 concedono privilegi di accesso specifici agli utenti. Richiedono un tag di risorsa Amazon EMR predefinito e chiavi di condizione `iam:PassRole` per le risorse utilizzate da Amazon EMR, quali `Subnet` e `SecurityGroup` utilizzate per avviare il cluster.
Per concedere le operazioni necessarie per Amazon EMR, collega la policy `AmazonEMRFullAccessPolicy_v2` gestita. Questa policy gestita predefinita aggiornata sostituisce la policy gestita [`AmazonElasticMapReduceFullAccess`](emr-managed-policy-fullaccess.md).
`AmazonEMRFullAccessPolicy_v2` dipende dall'accesso ridotto alle risorse che Amazon EMR fornisce o utilizza. Quando si utilizza questa policy, è necessario passare il tag utente `for-use-with-amazon-emr-managed-policies = true` durante il provisioning del cluster. Amazon EMR propaga automaticamente tale tag. Inoltre, potrebbe essere necessario aggiungere manualmente un tag utente a tipi specifici di risorse, ad esempio gruppi di sicurezza EC2 che non sono stati creati da Amazon EMR. Per ulteriori informazioni, consulta [Assegnazione di tag alle risorse per l'utilizzo delle policy gestite](emr-managed-iam-policies.md#manually-tagged-resources).
La policy [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) protegge le risorse eseguendo le operazioni elencate di seguito:
+ Richiede il tag delle risorse con il tag `for-use-with-amazon-emr-managed-policies` predefinito delle policy gestite da Amazon EMR per la creazione del cluster e l'accesso ad Amazon EMR.
+ Limita l'operazione `iam:PassRole` a ruoli predefiniti specifici e l'accesso `iam:PassedToService` a servizi specifici.
+ Non fornisce più l'accesso ad Amazon EC2, Amazon S3 e ad altri servizi per impostazione predefinita.
Il contenuto di questa policy è mostrato di seguito.
**Nota**
Puoi anche utilizzare il link alla console [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) per visualizzare la policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithEMRManagedTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddInstanceFleet",
"elasticmapreduce:AddInstanceGroups",
"elasticmapreduce:AddJobFlowSteps",
"elasticmapreduce:AddTags",
"elasticmapreduce:CancelSteps",
"elasticmapreduce:CreateEditor",
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:CreateSecurityConfiguration",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:DeleteSecurityConfiguration",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribePersistentAppUI",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetPersistentAppUIPresignedURL",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ModifyCluster",
"elasticmapreduce:ModifyInstanceFleet",
"elasticmapreduce:ModifyInstanceGroups",
"elasticmapreduce:OpenEditorInConsole",
"elasticmapreduce:PutAutoScalingPolicy",
"elasticmapreduce:PutBlockPublicAccessConfiguration",
"elasticmapreduce:PutManagedScalingPolicy",
"elasticmapreduce:RemoveAutoScalingPolicy",
"elasticmapreduce:RemoveManagedScalingPolicy",
"elasticmapreduce:RemoveTags",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_DefaultRole",
"arn:aws:iam::*:role/EMR_DefaultRole_V2"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
},
{
"Sid": "ConsoleUIActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeNatGateways",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeVpcEndpoints",
"s3:ListAllMyBuckets",
"iam:ListRoles"
],
"Resource": [
"*"
]
}
]
}
```
------
# Policy IAM gestite per l'accesso completo (presto obsolete)
Le policy gestite `AmazonElasticMapReduceFullAccess` e `AmazonEMRFullAccessPolicy_v2` AWS Identity and Access Management (IAM) garantiscono tutte le azioni richieste per Amazon EMR e altri servizi.
**Importante**
La policy gestita `AmazonElasticMapReduceFullAccess` diventerà presto obsoleta, pertanto ti consigliamo di non utilizzarla con Amazon EMR. Utilizza invece [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md). Quando il servizio IAM imposterà come obsoleta la policy v1, non sarà possibile collegarla a un ruolo. Tuttavia, puoi collegare un ruolo esistente a un cluster anche se tale ruolo utilizza la policy obsoleta.
Le policy gestite predefinite con autorizzazioni complete di Amazon EMR incorporano configurazioni di sicurezza `iam:PassRole`, tra cui:
+ Autorizzazioni `iam:PassRole` solo per specifici ruoli Amazon EMR predefiniti.
+ `iam:PassedToService`condizioni che consentono di utilizzare la politica solo con AWS servizi specifici, come `elasticmapreduce.amazonaws.com` e`ec2.amazonaws.com`.
Puoi visualizzare la versione JSON delle policy Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) nella console IAM. Ti consigliamo di creare i nuovi cluster con le policy gestite v2.
Puoi visualizzare il contenuto della policy v1 obsoleta all'indirizzo. Console di gestione AWS [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess) L'operazione `ec2:TerminateInstances` nella policy concede all'utente o al ruolo l'autorizzazione a terminare qualsiasi istanza Amazon EC2 associata all'account IAM. Sono incluse le istanze che non fanno parte di un cluster EMR.
# Policy gestita IAM per l'accesso in sola lettura (policy predefinita gestita v2) per Amazon EMR
**Per concedere privilegi di sola lettura ad Amazon EMR, collega la policy gestita Amazon \$1v2. EMRRead OnlyAccessPolicy** Questa policy gestita predefinita sostituisce la policy gestita [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md). Il contenuto di questa dichiarazione di policy è riportato nel frammento seguente. Rispetto alla policy `AmazonElasticMapReduceReadOnlyAccess`, la policy `AmazonEMRReadOnlyAccessPolicy_v2` non utilizza caratteri jolly per l'elemento `elasticmapreduce`. Al contrario, gli ambiti delle policy v2 predefiniti specificano le operazioni `elasticmapreduce` consentite.
**Nota**
Puoi anche utilizzare il link per visualizzare la policy. Console di gestione AWS [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
}
]
}
```
------
# Policy IAM gestite per l'accesso di sola lettura (presto obsolete)
La policy gestita `AmazonElasticMapReduceReadOnlyAccess` diventerà presto obsoleta. Non è possibile allegare questa policy durante l'avvio di nuovi cluster. `AmazonElasticMapReduceReadOnlyAccess` è stato sostituito con [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) come policy gestita predefinita di Amazon EMR. Il contenuto di questa dichiarazione di policy è riportato nel frammento seguente. I caratteri jolly per l'elemento `elasticmapreduce` specificano che solo le operazioni che iniziano con le stringhe specificate sono consentite. Tieni presente che poiché questa policy non nega esplicitamente le operazioni, un'altra dichiarazione di policy può essere utilizzata per concedere l'accesso alle operazioni specificate.
**Nota**
Puoi anche utilizzare il Console di gestione AWS per visualizzare la politica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:Describe*",
"elasticmapreduce:List*",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"sdb:Select",
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribe"
}
]
}
```
------
# AWS politica gestita: EMRDescribe ClusterPolicyFor EMRWAL
Non è possibile collegare `EMRDescribeClusterPolicyForEMRWAL`alle entità IAM. Questa policy è associata a un ruolo collegato al servizio che consente ad Amazon EMR di eseguire azioni per tuo conto. Per ulteriori informazioni su questo ruolo collegato al servizio, consulta. [Utilizzo di ruoli collegati ai servizi con Amazon EMR per la registrazione write-ahead](using-service-linked-roles-wal.md)
Questa politica concede autorizzazioni di sola lettura che consentono al servizio WAL per Amazon EMR di trovare e restituire lo stato di un cluster. Per ulteriori informazioni su Amazon EMR WAL, consulta [Write-ahead logs (](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html)WAL) per Amazon EMR.
**Dettagli delle autorizzazioni**
Questa policy include le seguenti autorizzazioni:
+ `emr`— Consente ai responsabili di descrivere lo stato del cluster da Amazon EMR. Ciò è necessario affinché Amazon EMR possa confermare la chiusura di un cluster e quindi, dopo trenta giorni, ripulire tutti i log WAL lasciati dal cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribecluster"
}
]
}
```
------
## AWS politiche gestite per Amazon EMR
Una politica AWS gestita è una politica autonoma creata e amministrata da. AWS AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
# Aggiornamenti di Amazon EMR alle AWS politiche gestite
Visualizza i dettagli sugli aggiornamenti delle politiche AWS gestite per Amazon EMR da quando questo servizio ha iniziato a tracciare queste modifiche.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): aggiornamento a una policy esistente | Aggiunto ec2:CreateVpcEndpoint e ec2:CreateTags richiesto per un'esperienza ottimale, a partire dalla release 7.5.0 di Amazon EMR. ec2:ModifyVpcEndpoint | 4 marzo 2025 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): aggiornamento di una policy esistente | Aggiunto elasticmapreduce:CreatePersistentAppUIelasticmapreduce:DescribePersistentAppUI, e. elasticmapreduce:GetPersistentAppUIPresignedURL | 28 febbraio 2025 |
| [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md): nuova policy | È stata aggiunta una nuova policy in modo che Amazon EMR possa determinare lo stato del cluster per la pulizia WAL trenta giorni dopo la chiusura del cluster. | 10 agosto 2023 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) e [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md): aggiornamento a una policy esistente | Aggiunto elasticmapreduce:DescribeReleaseLabel e elasticmapreduce:GetAutoTerminationPolicy. | 21 aprile 2022 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): aggiornamento di una policy esistente | Aggiunta di ec2:DescribeImages per [Utilizzo di un'AMI personalizzata per fornire maggiore flessibilità per la configurazione del cluster Amazon EMR](emr-custom-ami.md). | 15 febbraio 2022 |
| [**Policy gestite da Amazon EMR**](emr-managed-iam-policies.md) | Aggiornato per chiarire l'uso di tag utente predefiniti. È stata aggiunta una sezione sull'utilizzo della AWS console per avviare cluster con politiche gestite v2. | 29 settembre 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): aggiornamento di una policy esistente | Modifica delle operazioni PassRoleForAutoScaling e PassRoleForEC2 per utilizzare l'operatore di condizione StringLike in modo che corrispondano a "iam:PassedToService":"application-autoscaling.amazonaws.com\$1" e "iam:PassedToService":"ec2.amazonaws.com\$1" rispettivamente. | 20 maggio 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): aggiornamento di una policy esistente | Rimozione dell'operazione `s3:ListBuckets` non valida e sostituzione con l'operazione `s3:ListAllMyBuckets`. Aggiornamento della creazione del ruolo collegato al servizio (SLR) in modo esplicito fino all'unico SLR di Amazon EMR con principi di servizio espliciti. I file SLRs che possono essere creati sono esattamente gli stessi di prima di questa modifica. | 23 marzo 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): nuova policy | Amazon EMR ha aggiunto nuove autorizzazioni per l'ambito dell'accesso alle risorse e per aggiungere il prerequisito secondo cui gli utenti devono aggiungere un tag utente predefinito alle risorse prima di poter utilizzare le policy gestite da Amazon EMR. L'operazione `iam:PassRole` richiede che la condizione `iam:PassedToService` sia impostata sul servizio specificato. L'accesso ad Amazon EC2, Amazon S3 e ad altri servizi non è consentito per impostazione predefinita. | 11 marzo 2021 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): nuova policy | Aggiunge il prerequisito secondo cui gli utenti devono aggiungere tag utente alle risorse prima di poter utilizzare questa policy. | 11 marzo 2021 |
| [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md): nuova policy | Le autorizzazioni si riferiscono esclusivamente alle operazioni elasticmapreduce di sola lettura specificate. Per impostazione predefinita, l'accesso ad Amazon S3 non è consentito. | 11 marzo 2021 |
| Amazon EMR ha iniziato a monitorare le modifiche | Amazon EMR ha iniziato a tracciare le modifiche per le sue politiche AWS gestite. | 11 marzo 2021 |
# Policy IAM per l'accesso basato su tag ai cluster e a EMR Notebooks
Puoi utilizzare le condizioni nella policy basata su identità per controllare l'accesso ai cluster e ai EMR Notebooks basati su tag.
Per ulteriori informazioni sull'aggiunta di tag ai cluster, consulta [Tagging dei cluster EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html).
I seguenti esempi illustrano differenti scenari e modi per utilizzare gli operatori di condizione con chiavi di condizione Amazon EMR. Queste dichiarazioni di policy IAM sono concepite unicamente per scopi dimostrativi e non devono essere utilizzate negli ambienti di produzione. Esistono vari modi di combinare dichiarazioni di policy per concedere o negare autorizzazioni in base alle tue esigenze. Per ulteriori informazioni sulla pianificazione e sul test di policy IAM, consulta la [Guida per l'utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**Importante**
Negare esplicitamente l'autorizzazione per operazioni di assegnazione di tag è una possibilità da tenere in debita considerazione. Ciò impedisce agli utenti di concedersi personalmente autorizzazioni tramite tag di una risorsa che non avevi intenzione di accordare. Se non neghi le operazioni di assegnazione di tag per una risorsa, un utente può modificare i tag e aggirare l'intenzione delle policy basate su tag.
## Dichiarazioni di policy basate su identità di esempio per cluster
Gli esempi di seguito dimostrano le policy di autorizzazioni basate su identità che vengono utilizzate per controllare le operazioni che sono consentite con cluster EMR.
**Importante**
L'operazione `ModifyInstanceGroup` in Amazon EMR non richiede che si specifichi un ID cluster. Per questo motivo, negare questa azione basata su tag del cluster richiede un'ulteriore considerazione. Per ulteriori informazioni, consulta [Negare l' ModifyInstanceGroup azione in Amazon EMR](emr-cluster-deny-modifyinstancegroup.md).
**Topics**
+ [Autorizzazione di operazioni solo su cluster con specifici valori di tag](#emr-cluster-access-example-tagvalue)
+ [Richiesta dell'assegnazione di tag a un cluster appena creato](#emr-cluster-access-example-require-tagging)
+ [Autorizzazione di operazioni su cluster con uno specifico tag indipendentemente dal valore di tag](#emr-cluster-access-example-tag)
### Autorizzazione di operazioni solo su cluster con specifici valori di tag
Gli esempi che seguono mostrano una policy che autorizza un utente a eseguire operazioni in base al tag di cluster `department` con il valore `dev` e un altro utente a contrassegnare cluster con quello stesso tag. L'esempio di policy finale mostra come negare privilegi per taggare cluster EMR con qualsiasi tag tranne quel tag.
Nell'esempio di policy seguente, l'operatore di condizione `StringEquals` cerca di far corrispondere `dev` con il valore del tag `department`. Se il tag `department` non è stato aggiunto al cluster, oppure non contiene il valore `dev`, la policy non viene applicata e le operazioni non sono consentite da questa policy. Se nessun'altra dichiarazione di policy consente le operazioni, l'utente può utilizzare solo i cluster che hanno questo tag con tale valore.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt12345678901234",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:DescribeStep"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
}
]
}
```
------
Puoi anche specificare più valori di tag utilizzando un operatore di condizione. Ad esempio, per consentire tutte le operazioni su cluster in cui il tag `department` contiene il valore `dev` o `test`, puoi sostituire il blocco di condizione nell'esempio precedente con quanto segue.
```
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department":["dev", "test"]
}
}
```
### Richiesta dell'assegnazione di tag a un cluster appena creato
Come nell'esempio precedente, l'esempio seguente di policy cerca lo stesso tag corrispondente: il valore `dev` per il tag `department`. In questo esempio, però, la chiave di condizione `RequestTag` specifica che la policy si applica durante la creazione del tag. Quindi è necessario creare un cluster con un tag che corrisponda al valore specificato.
Per creare un cluster con un tag, devi anche disporre dell'autorizzazione per l'azione `elasticmapredue:AddTags`. Per questa dichiarazione, la chiave di condizione `elasticmapreduce:ResourceTag` garantisce che IAM conceda l'accesso solo alle risorse dei tag con il valore `dev` sul tag `department`. L'elemento `Resource` viene utilizzato per limitare questa autorizzazione alle risorse del cluster.
Per le `PassRole` risorse, devi fornire l'ID o l'alias dell' AWS account, il nome del ruolo di servizio nell'`PassRoleForEMR`istruzione e il nome del profilo dell'istanza nell'`PassRoleForEC2`istruzione. Per ulteriori informazioni sul formato IAM ARN, consulta [IAM ARNs nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *User* Guide.
Per ulteriori informazioni sulla corrispondenza delle chiavi di tag, consulta [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) nella *Guida per l'utente IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/department": "dev"
}
}
},
{
"Sid": "AddTagsForDevClusters",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
},
{
"Sid": "PassRoleForEMR",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
### Autorizzazione di operazioni su cluster con uno specifico tag indipendentemente dal valore di tag
Puoi anche consentire operazioni solo su cluster con un determinato tag, indipendentemente dal valore di tag. A questo proposito, puoi utilizzare l'operatore `Null`. Per ulteriori informazioni, consulta [Operatore di condizione per verificare la presenza di chiavi di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) nella *Guida per l'utente IAM*. Ad esempio, per consentire operazioni solo su cluster EMR con il tag `department`, indipendentemente dal valore che lo stesso contiene, puoi sostituire i blocchi di condizione nell'esempio precedente con quello illustrato di seguito. L'operatore `Null` cerca il tag `department` su un cluster EMR. Se il tag esiste, l'istruzione `Null` restituisce il valore false, corrispondente alla condizione specificata nella dichiarazione di policy, e le operazioni appropriate sono consentite.
```
1. "Condition": {
2. "Null": {
3. "elasticmapreduce:ResourceTag/department":"false"
4. }
5. }
```
La dichiarazione di policy seguente consente a un utente di creare un cluster EMR solo se il cluster avrà un tag `department`, indipendentemente dal valore dello stesso. Per la `PassRole` risorsa, devi fornire l'ID o l'alias AWS dell'account e il nome del ruolo del servizio. Per ulteriori informazioni sul formato IAM ARN, consulta [IAM ARNs nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *User* Guide.
Per ulteriori informazioni su come specificare l'operatore di condizione null ("falso"), consulta [Operatore di condizione per verificare la presenza di chiavi di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null) nella *Guida per l'utente IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateClusterTagNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/department": "false"
}
}
},
{
"Sid": "AddTagsNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"Null": {
"elasticmapreduce:ResourceTag/department": "false"
}
}
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
## Dichiarazioni di policy basate su identità di esempio per EMR Notebooks
Le dichiarazioni di policy IAM di esempio in questa sezione illustrano scenari comuni per l'utilizzo di chiavi per limitare le operazioni consentite mediante EMR Notebooks. Finché nessun'altra policy associata al principale (utente) consente le operazioni, le chiavi di contesto della condizione limitano le operazioni consentite come indicato.
**Example : consente l'accesso solo ai EMR Notebooks creati da un utente in base all'assegnazione di tag**
L'esempio seguente di istruzione di policy, quando collegata a un ruolo o a un utente, consente all'utente di utilizzare solo i notebook che ha creato. Questa istruzione di policy usa il tag predefinito applicato durante la creazione di un notebook.
In questo esempio, l'operatore di condizione `StringEquals` cerca di mettere in corrispondenza una variabile che rappresenta l'ID dell'utente attuale (`{aws:userId}`) con il valore del tag `creatorUserID`. Se il tag `creatorUserID` non è stato aggiunto al notebook, oppure non contiene il valore dell'ID dell'utente corrente, la policy non viene applicata e le operazioni non sono consentite da questa policy. Se nessun'altra istruzione di policy consente le operazioni, l'utente può utilizzare solo i notebook che hanno questo tag con tale valore.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/creatorUserId": "${aws:userId}"
}
},
"Sid": "AllowELASTICMAPREDUCEDescribeeditor"
}
]
}
```
**Example -Richiedere l'assegnazione di tag al notebook durante la creazione**
In questo esempio viene utilizzata la chiave di contesto `RequestTag`. L'operazione `CreateEditor` è consentita solo se l'utente non modifica o elimina il tag `creatorUserID` aggiunto per impostazione predefinita. La variabile \$1\$1aws:userId\$1, specifica l'ID dell'utente attualmente attivo, che è il valore predefinito del tag.
L'istruzione della policy può essere utilizzata per garantire che gli utenti non rimuovano il tag `createUserId` o ne modifichino il valore.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
Questo esempio richiede che l'utente crei il cluster con un tag con la stringa di chiave `dept` e un valore impostato per uno dei seguenti: `datascience`, `analytics`, `operations`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/dept": [
"datascience",
"analytics",
"operations"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example -Limitare la creazione di notebook ai cluster con tag e richiedere i tag del notebook**
Questo esempio consente la creazione di notebook solo se il notebook viene creato con un tag che abbia la stringa di chiave `owner` impostata su uno dei valori specificati. Inoltre, è possibile creare il notebook solo se il cluster dispone di un tag con la stringa di chiave `department` impostata su uno dei valori specificati.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/owner": [
"owner1",
"owner2",
"owner3"
],
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example -Limitare la possibilità di avviare un notebook basato su tag**
Questo esempio limita la possibilità di avviare solo i notebook che dispongono di un tag con la stringa di chiave `owner` impostata su uno dei valori specificati. Poiché l'elemento `Resource` è utilizzato per specificare solo `editor`, la condizione non è valida per il cluster e non è necessario aggiungere tag al cluster.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"owner1",
"owner2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
Questo esempio è simile a uno precedente. Tuttavia, il limite si applica solo ai cluster a cui sono applicati tag, non ai notebook.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
In questo esempio viene utilizzato un altro set di tag di notebook e cluster. Consente di avviare un notebook solo se:
+ Il notebook dispone di un tag con la stringa di chiave `owner` impostata su uno dei valori specificati
-e-
+ Il cluster dispone di un tag con la stringa di chiave `department` impostata su uno dei valori specificati
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByOwner"
},
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByDepartment"
}
]
}
```
**Example -Limitare la possibilità di aprire l'editor del notebook basato su tag**
Questo esempio consente di aprire l'editor del notebook solo se:
+ Il notebook dispone di un tag con la stringa di chiave `owner` impostata su uno dei valori specificati.
-e-
+ Il cluster dispone di un tag con la stringa di chiave `department` impostata su uno dei valori specificati.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByOwner"
},
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByDepartment"
}
]
}
```
# Negare l' ModifyInstanceGroup azione in Amazon EMR
L'[ModifyInstanceGroups](https://docs.aws.amazon.com/emr/latest/APIReference/API_ModifyInstanceGroups.html)azione in Amazon EMR non richiede che tu fornisca un ID cluster con l'azione. È invece possibile specificare solo un ID del gruppo di istanze. Per questo motivo, una policy di negazione apparentemente semplice per questa operazione basata sull'ID cluster o su un tag cluster potrebbe non avere l'effetto desiderato. Esaminiamo l'esempio di policy seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroups"
}
]
}
```
------
Se un utente con questa policy associata esegue un'operazione `ModifyInstanceGroup` e specifica solo l'ID del gruppo di istanze, la policy non viene applicata. Poiché l'operazione è consentita su tutte le altre risorse, avrà esito positivo.
Una soluzione a questo problema consiste nell'allegare una dichiarazione politica all'identità che utilizza un [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html)elemento per negare qualsiasi `ModifyInstanceGroup` azione eseguita senza un ID cluster. La seguente policy di esempio aggiunge tale dichiarazione di negazione in modo che qualsiasi richiesta `ModifyInstanceGroups` abbia esito negativo a meno che non venga specificato un ID cluster. Poiché un'identità deve specificare un ID cluster con l'operazione, le istruzioni negate basate sull'ID cluster sono efficaci.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsSpecificCluster"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"NotResource": "arn:*:elasticmapreduce:*:*:cluster/*",
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNonCluster"
}
]
}
```
------
Un problema simile si verifica quando si desidera negare l'operazione `ModifyInstanceGroups` in base al valore associato a un tag cluster. La soluzione è simile. Oltre a un'istruzione di negazione che specifica il valore del tag, è possibile aggiungere un'istruzione della policy che neghi l'operazione `ModifyInstanceGroup` se il tag specificato non è presente, indipendentemente dal valore.
Nell'esempio seguente viene illustrata una policy che, se collegata a un'identità, nega all'identità l'operazione `ModifyInstanceGroups` per qualsiasi cluster con il tag `department` impostato su `dev`. Questa istruzione è efficace solo a causa dell'istruzione di negazione che utilizza la condizione `StringNotLike` per negare l'operazione a meno che il tag `department` non sia presente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsDevDepartment"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/department": "?*"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNoDepartmentTag"
}
]
}
```
------
# Risoluzione dei problemi relativi all'identità e all'accesso di Amazon EMR
Utilizza le informazioni seguenti per eseguire la diagnosi e risolvere i problemi comuni che possono verificarsi durante l'utilizzo di Amazon EMR e IAM.
**Topics**
+ [Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon EMR](#security_iam_troubleshoot-no-permissions)
+ [Non sono autorizzato a eseguire iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Voglio consentire a persone esterne al mio AWS account di accedere alle mie risorse Amazon EMR](#security_iam_troubleshoot-cross-account-access)
## Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon EMR
Se ti Console di gestione AWS dice che non sei autorizzato a eseguire un'azione, devi contattare l'amministratore per ricevere assistenza. L'amministratore è la persona da cui si sono ricevuti il nome utente e la password.
Il seguente esempio di errore si verifica quando l'utente `mateojackson` prova a utilizzare la console per visualizzare i dettagli relativi a una risorsa `my-example-widget` fittizia, ma non dispone di autorizzazioni `EMR:GetWidget` fittizie.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: EMR:GetWidget on resource: my-example-widget
```
In questo caso, Mateo richiede al suo amministratore di aggiornare le policy per poter accedere alla risorsa `my-example-widget` utilizzando l'operazione `EMR:GetWidget`.
## Non sono autorizzato a eseguire iam: PassRole
Se ricevi un errore che indica che non disponi dell'autorizzazione per eseguire l'operazione `iam:PassRole`, per poter passare un ruolo ad Amazon EMR dovrai aggiornare le policy.
Alcuni Servizi AWS consentono di passare un ruolo esistente a quel servizio invece di creare un nuovo ruolo di servizio o un ruolo collegato al servizio. Per eseguire questa operazione, è necessario disporre delle autorizzazioni per trasmettere il ruolo al servizio.
Il seguente esempio di errore si verifica quando un utente IAM denominato `marymajor` cerca di utilizzare la console per eseguire un'operazione in Amazon EMR. Tuttavia, l’azione richiede che il servizio disponga delle autorizzazioni concesse da un ruolo di servizio. Mary non dispone delle autorizzazioni per trasmettere il ruolo al servizio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In questo caso, le policy di Mary devono essere aggiornate per poter eseguire l’operazione `iam:PassRole`.
Se hai bisogno di aiuto, contatta il tuo AWS amministratore. L’amministratore è la persona che ti ha fornito le credenziali di accesso.
## Voglio consentire a persone esterne al mio AWS account di accedere alle mie risorse Amazon EMR
È possibile creare un ruolo con il quale utenti in altri account o persone esterne all’organizzazione possono accedere alle tue risorse. È possibile specificare chi è attendibile per l’assunzione del ruolo. Per i servizi che supportano politiche basate sulle risorse o liste di controllo degli accessi (ACLs), puoi utilizzare tali politiche per consentire alle persone di accedere alle tue risorse.
Per maggiori informazioni, consulta gli argomenti seguenti:
+ Per sapere se Amazon EMR supporta queste funzionalità, consulta [Funzionamento di Amazon EMR con IAM](security_iam_service-with-iam.md).
+ Per scoprire come fornire l'accesso alle tue risorse attraverso Account AWS le risorse di tua proprietà, consulta [Fornire l'accesso a un utente IAM in un altro Account AWS di tua proprietà](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) nella *IAM* User Guide.
+ Per scoprire come fornire l'accesso alle tue risorse a terze parti Account AWS, consulta [Fornire l'accesso a soggetti Account AWS di proprietà di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) nella *Guida per l'utente IAM*.
+ Per informazioni su come fornire l'accesso tramite la federazione delle identità, consulta [Fornire l'accesso a utenti autenticati esternamente (federazione delle identità)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) nella *Guida per l'utente IAM*.
+ Per informazioni sulle differenze di utilizzo tra ruoli e policy basate su risorse per l’accesso multi-account, consulta [Accesso a risorse multi-account in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) nella *Guida per l’utente di IAM*.
# Utilizzo di Amazon S3 Access Grants con Amazon EMR
## Panoramica di S3 Access Grants per Amazon EMR
Con le versioni 6.15.0 e successive di Amazon EMR, Amazon S3 Access Grants fornisce una soluzione di controllo degli accessi scalabile che puoi utilizzare per aumentare l'accesso ai tuoi dati Amazon S3 da Amazon EMR. Se hai una configurazione di autorizzazioni complessa o di grandi dimensioni per i dati S3, puoi utilizzare Access Grants per dimensionare le autorizzazioni relative ai dati S3 per utenti, ruoli e applicazioni sul cluster.
Utilizza S3 Access Grants per aumentare l'accesso ai dati di Amazon S3 oltre alle autorizzazioni concesse dal ruolo di runtime o dai ruoli IAM collegati alle identità con accesso al tuo cluster EMR. Per ulteriori informazioni, consulta [Gestione degli accessi con S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) nella *Guida per l'utente di Amazon S3*.
Per conoscere i passaggi per utilizzare S3 Access Grants con altre implementazioni Amazon EMR, consulta la seguente documentazione:
+ [Utilizzo di S3 Access Grants con Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Utilizzo di S3 Access Grants con Amazon EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
## Come funziona Amazon EMR con S3 Access Grants
I rilasci di Amazon EMR versione 6.15.0 e successive forniscono un'integrazione nativa con S3 Access Grants. Puoi abilitare S3 Access Grants su Amazon EMR ed eseguire processi Spark. Quando il processo Spark effettua una richiesta di dati S3, Amazon S3 fornisce credenziali temporanee che rientrano nell'ambito del bucket, del prefisso o dell'oggetto specifico.
Di seguito è riportata una panoramica generale sul modo in cui Amazon EMR ottiene l'accesso ai dati protetti da S3 Access Grants.
![\[Come funziona Amazon EMR con S3 Access Grants\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/access-grants-overview.png)
1. Un utente invia un processo Spark di Amazon EMR che utilizza dati archiviati in Amazon S3.
1. Amazon EMR elabora una richiesta a S3 Access Grants per consentire l'accesso al bucket, al prefisso o all'oggetto per conto di quell'utente.
1. Amazon S3 restituisce credenziali temporanee sotto forma di token AWS Security Token Service (STS) per l'utente. Il token ha accesso al bucket, al prefisso o all'oggetto S3.
1. Amazon EMR utilizza il token STS per recuperare dati da S3.
1. Amazon EMR riceve i dati da S3 e restituisce i risultati all'utente.
## Considerazioni su S3 Access Grants con Amazon EMR
Prendi nota dei seguenti comportamenti e limitazioni quando usi S3 Access Grants con Amazon EMR.
### Supporto funzionalità
+ S3 Access Grants è supportato con Amazon EMR versioni 6.15.0 e successive.
+ Spark è l'unico motore di query supportato quando utilizzi S3 Access Grants con Amazon EMR.
+ Delta Lake e Hudi sono gli unici formati a tabella aperta supportati quando utilizzi S3 Access Grants con Amazon EMR.
+ Le seguenti funzionalità di Amazon EMR non sono supportate per l'utilizzo con S3 Access Grants:
+ Tabelle Apache Iceberg
+ Autenticazione LDAP nativa
+ Autenticazione nativa di Apache Ranger
+ AWS CLI richieste ad Amazon S3 che utilizzano ruoli IAM
+ Accesso a S3 tramite il protocollo S3A open source
+ L'opzione `fallbackToIAM` non è supportata per i cluster EMR che utilizzano la propagazione affidabile delle identità con il Centro identità IAM.
+ [S3 Access Grants con AWS Lake Formation](#emr-access-grants-lf) è supportato solo con i cluster Amazon EMR eseguiti su Amazon EC2.
### Considerazioni comportamentali
+ L'integrazione nativa di Apache Ranger con Amazon EMR include funzionalità congruenti con S3 Access Grants come parte del plug-in EMRFS S3 Apache Ranger. Se utilizzi Apache Ranger per il controllo granulare degli accessi (FGAC), ti consigliamo di utilizzare quel plug-in anziché S3 Access Grants.
+ Amazon EMR fornisce una cache delle credenziali in EMRFS per garantire che un utente non debba effettuare richieste ripetute per le stesse credenziali all'interno di un processo Spark. Pertanto, Amazon EMR richiede sempre il privilegio di livello predefinito quando richiede le credenziali. Per ulteriori informazioni, consulta [Richiedi l'accesso ai dati di S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants-credentials.html) nella *Guida per l'utente di Amazon S3*.
+ Nel caso in cui un utente esegua un'azione che S3 Access Grants non supporta, Amazon EMR è impostato per utilizzare il ruolo IAM specificato per l'esecuzione dei processi. Per ulteriori informazioni, consulta [Torna ai ruoli IAM](#emr-access-grants-fallback).
## Avvio di un cluster Amazon EMR con S3 Access Grants
Questa sezione descrive come avviare un cluster EMR eseguito su Amazon EC2 e utilizza S3 Access Grants per gestire l'accesso ai dati in Amazon S3. Per conoscere i passaggi per utilizzare S3 Access Grants con altre implementazioni Amazon EMR, consulta la seguente documentazione:
+ [Utilizzo di S3 Access Grants con Amazon EMR su EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Utilizzo di S3 Access Grants con EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
Utilizza i seguenti passaggi per avviare un cluster EMR eseguito su Amazon EC2 e utilizza S3 Access Grants per gestire l'accesso ai dati in Amazon S3.
1. Configura un ruolo di esecuzione dei processi per il cluster EMR. Includi le autorizzazioni IAM necessarie per eseguire i processi Spark, `s3:GetDataAccess` e `s3:GetAccessGrantsInstanceForPrefix`:
```
{
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": [ //LIST ALL INSTANCE ARNS THAT THE ROLE IS ALLOWED TO QUERY
"arn:aws_partition:s3:Region:account-id1:access-grants/default",
"arn:aws_partition:s3:Region:account-id2:access-grants/default"
]
}
```
**Nota**
Con Amazon EMR, S3 Access Grants aumenta le autorizzazioni impostate nei ruoli IAM. Se i ruoli IAM specificati per l'esecuzione dei processi dispongono di autorizzazioni per accedere direttamente a S3, gli utenti potrebbero essere in grado di accedere a più dati rispetto a quelli definiti in S3 Access Grants.
1. Quindi, usa AWS CLI per creare un cluster con Amazon EMR 6.15 o versione successiva e la `emrfs-site` classificazione per abilitare S3 Access Grants, in modo simile al seguente esempio:
```
aws emr create-cluster
--release-label emr-6.15.0 \
--instance-count 3 \
--instance-type m5.xlarge \
--configurations '[{"Classification":"emrfs-site", "Properties":{"fs.s3.s3AccessGrants.enabled":"true", "fs.s3.s3AccessGrants.fallbackToIAM":"false"}}]'
```
## S3 Access Grants con AWS Lake Formation
Se utilizzi Amazon EMR con [l'integrazione AWS Lake Formation](emr-lake-formation.md), puoi utilizzare Amazon S3 Access Grants per l'accesso diretto o tabulare ai dati in Amazon S3.
**Nota**
S3 Access Grants with AWS Lake Formation è supportato solo con i cluster Amazon EMR eseguiti su Amazon EC2.
**Accesso diretto**
L'accesso diretto include tutte le chiamate per accedere ai dati S3 che non richiamano l'API per il servizio AWS Glue che Lake Formation utilizza come metastore con Amazon EMR, ad esempio per chiamare: `spark.read`
```
spark.read.csv("s3://...")
```
Quando utilizzi S3 Access Grants con AWS Lake Formation Amazon EMR, tutti i modelli di accesso diretto passano attraverso S3 Access Grants per ottenere credenziali S3 temporanee.
**Accesso tabulare**
L'accesso tabulare si verifica quando Lake Formation richiama l'API del metastore per accedere alla posizione di S3, ad esempio per eseguire query sui dati della tabella:
```
spark.sql("select * from test_tbl")
```
Quando utilizzi S3 Access Grants con AWS Lake Formation Amazon EMR, tutti i modelli di accesso tabulari passano attraverso Lake Formation.
## Torna ai ruoli IAM
Se un utente tenta di eseguire un'operazione che S3 Access Grants non supporta, Amazon EMR è impostato per utilizzare il ruolo IAM specificato per l'esecuzione dei processi quando la configurazione `fallbackToIAM` è `true`. Ciò consente agli utenti di tornare al proprio ruolo di esecuzione dei processi per fornire le credenziali per l'accesso a S3 in scenari non coperti da S3 Access Grants.
Se `fallbackToIAM` è abilitato, gli utenti possono accedere ai dati consentiti dall'Access Grant. Se non esiste un token S3 Access Grants per i dati di destinazione, Amazon EMR verifica l'autorizzazione per il ruolo di esecuzione dei processi.
**Nota**
Ti consigliamo di testare le tue autorizzazioni di accesso con la configurazione `fallbackToIAM` abilitata anche se prevedi di disabilitare l'opzione per i carichi di lavoro di produzione. Con i processi Spark, ci sono altri modi in cui gli utenti potrebbero accedere a tutti i set di autorizzazioni con le proprie credenziali IAM. Se abilitate sui cluster EMR, le autorizzazioni di S3 consentono ai processi Spark di accedere alle posizioni S3. Assicurti di proteggere queste posizioni S3 dall'accesso esterno a EMRFS. Ad esempio, devi proteggere le posizioni S3 dall'accesso da parte dei client S3 utilizzati nei notebook o dalle applicazioni che non sono supportate da S3 Access Grants come Hive o Presto.
# Autenticazione nei nodi cluster Amazon EMR
I client SSH possono utilizzare una coppia di chiavi Amazon EC2 per l'autenticazione in istanze cluster. In alternativa, con Amazon EMR rilasci 5.10.0 e successivi, puoi configurare Kerberos per autenticare utenti e connessioni SSH sul nodo primario. E con i rilasci 5.12.0 e successivi di Amazon EMR, puoi autenticarti con LDAP.
**Topics**
+ [Usa una coppia di chiavi EC2 per le credenziali SSH per Amazon EMR](emr-plan-access-ssh.md)
+ [Utilizzo di Kerberos per l'autenticazione con Amazon EMR](emr-kerberos.md)
+ [Utilizzo di server Active Directory o LDAP per l'autenticazione con Amazon EMR](ldap.md)
# Usa una coppia di chiavi EC2 per le credenziali SSH per Amazon EMR
I nodi cluster Amazon EMR vengono eseguiti su istanze Amazon EC2. Puoi connetterti a nodi cluster nello stesso modo in cui puoi connetterti alle istanze Amazon EC2. Puoi utilizzare Amazon EC2 per creare una coppia di chiavi oppure per importare una coppia di chiavi. Quando crei un cluster, puoi specificare la coppia di chiavi Amazon EC2 che verrà utilizzata per le connessioni SSH a tutte le istanze cluster. Puoi anche creare un cluster senza una coppia di chiavi. Questa operazione viene di solito effettuata con cluster transitori che si avviano, eseguono fasi e quindi terminano in automatico.
Il client SSH che utilizzi per connetterti al cluster deve utilizzare il file della chiave privata associato a tale coppia di chiavi. Questo è un file .pem per client SSH che utilizzano Linux, Unix e macOS. Devi impostare le autorizzazioni in modo che solo il proprietario della chiave disponga dell'autorizzazione per accedere al file. Si tratta di un file .ppk per i client SSH che utilizzano Windows ed è in genere creato a partire dal file .pem.
+ Per ulteriori informazioni sulla creazione di una coppia di chiavi Amazon EC2, consulta le coppie di chiavi [Amazon EC2 nella Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) User *Guide*.
+ *Per istruzioni sull'uso di Pu TTYgen per creare un file.ppk da un file.pem, consulta [Conversione della chiave privata utilizzando Pu nella Guida per l'utente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) di TTYgen Amazon EC2.*
+ Per ulteriori informazioni sull'impostazione delle autorizzazioni per i file.pem e su come connettersi al nodo primario di un cluster EMR utilizzando metodi diversi, ad esempio da `ssh` Linux o macOS, PuTTY da Windows o da qualsiasi sistema operativo supportato, vedere. AWS CLI [Connect al nodo primario del cluster Amazon EMR tramite SSH](emr-connect-master-node-ssh.md)
# Utilizzo di Kerberos per l'autenticazione con Amazon EMR
Amazon EMR rilascio 5.10.0 e successivi supporta Kerberos. Kerberos è un protocollo di autenticazione di rete che utilizza la crittografia con chiave segreta per fornire un'autenticazione efficace affinché le password o altre credenziali non siano inviate in rete in un formato non crittografato.
In Kerberos, i servizi e gli utenti che devono effettuare l'autenticazione sono denominati *principali*. I principali si trovano in un *realm* Kerberos. Nel realm, un server Kerberos, denominato *Key Distribution Center (KDC)*, fornisce ai principali i mezzi per eseguire l'autenticazione. A questo proposito, il KDC emette dei *ticket* per l'autenticazione. Il KDC gestisce un database dei principali nel realm, le relative password e altre informazioni amministrative su ogni principale. Un KDC può anche accettare credenziali di autenticazione da principali in altri realm; questa condizione è nota come *trust tra realm*. Inoltre, un cluster EMR può utilizzare un server KDC esterno per autenticare i principali.
La definizione di un trust tra realm o l'uso di un server KDC esterno è di uso comune nell'autenticazione degli utenti da un dominio di Active Directory. Questo consente agli utenti di accedere a un cluster EMR con il proprio account di dominio se si connettono a un cluster o lavorano con applicazioni Big Data utilizzando SSH.
Quando si utilizza l'autenticazione Kerberos, Amazon EMR configura Kerberos per le applicazioni, i componenti e i sottosistemi che installa sul cluster di modo che si autentichino a vicenda.
**Importante**
Amazon EMR non supporta AWS Directory Service for Microsoft Active Directory un trust cross-realm o come KDC esterno.
Prima di configurare Kerberos utilizzando Amazon EMR, ti consigliamo di acquisire familiarità con i concetti di Kerberos, i servizi eseguiti su un KDC e gli strumenti di amministrazione dei servizi Kerberos. Per ulteriori informazioni, consulta la [Documentazione di MIT Kerberos](http://web.mit.edu/kerberos/krb5-latest/doc/), pubblicata dal [Kerberos Consortium](http://kerberos.org/).
**Topics**
+ [Applicazioni supportate con Amazon EMR](emr-kerberos-principals.md)
+ [Opzioni di architettura Kerberos con Amazon EMR](emr-kerberos-options.md)
+ [Configurazione di Kerberos su Amazon EMR](emr-kerberos-configure.md)
+ [Utilizzo di SSH per connettersi a cluster kerberizzati con Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: configura un KDC dedicato al cluster con Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory](emr-kerberos-cross-realm.md)
# Applicazioni supportate con Amazon EMR
In un cluster EMR, i principali Kerberos sono i sottosistemi e i servizi di applicazioni di Big Data eseguiti su tutti i nodi di cluster. Amazon EMR può configurare le applicazioni e i componenti elencati di seguito per utilizzare Kerberos. Ogni applicazione ha un principale utente Kerberos a cui è associato.
Amazon EMR non supporta relazioni di fiducia tra realm con AWS Directory Service for Microsoft Active Directory.
Amazon EMR configura solo le caratteristiche di autenticazione Kerberos open source per le applicazioni e i componenti elencati di seguito. Qualsiasi altra applicazione installata non utilizza Kerberos e ciò può comportare un'incapacità a comunicare con i componenti che utilizzano Kerberos e causare errori nelle applicazioni. Per le applicazioni e i componenti che non utilizzano Kerberos, l'autenticazione non è abilitata. Le applicazioni e i componenti supportati possono variare a seconda dei rilasci di Amazon EMR.
L'interfaccia utente di Livy è l'unica interfaccia utente Web ospitata sul cluster che è Kerberizzato.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ Non abilitare Hive con l'autenticazione LDAP. Questa operazione può causare problemi di comunicazione con l'applicazione YARN che utilizza Kerberos.
+ **Hue**
+ L'autenticazione utente Hue non è impostata automaticamente e può essere configurata utilizzando l'API di configurazione.
+ Il server Hue utilizza Kerberos. Il front-end Hue (interfaccia utente) non è configurato per l'autenticazione. L'autenticazione LDAP può essere configurata per l'interfaccia utente Hue.
+ **Livy**
+ La rappresentazione di Livy con cluster che utilizzano Kerberos è supportata in Amazon EMR 5.22.0 e rilasci successivi.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto supporta l'autenticazione Kerberos nei rilasci di Amazon EMR 6.9.0 e successivi.
+ Per utilizzare l'autenticazione Kerberos per Presto, devi abilitare la [crittografia in transito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino supporta l'autenticazione Kerberos in Amazon EMR rilasci 6.11.0 e successivi.
+ Per utilizzare l'autenticazione Kerberos per Trino, devi abilitare la [crittografia in transito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ Zeppelin è configurato solo per l'utilizzo di Kerberos con l'interprete Spark. Non è configurato per altri interpreti.
+ La rappresentazione dell'utente non è supportata per gli interpreti Zeppelin che utilizzano Kerberos diversi da Spark.
+ **Zookeeper**
+ Il client Zookeeper non è supportato.
# Opzioni di architettura Kerberos con Amazon EMR
Utilizzando Kerberos con Amazon EMR, è possibile scegliere tra le architetture elencate in questa sezione. Indipendentemente dall'architettura scelta, Kerberos può essere configurato con la stessa procedura. Si crea una configurazione di sicurezza, si specifica la configurazione di sicurezza e le opzioni compatibili di Kerberos specifiche per il cluster quando si crea il cluster stesso, infine si creano directory HDFS per utenti Linux sul cluster corrispondenti ai principali per l'utente nel server KDC. Per una spiegazione delle opzioni di configurazione ed esempi di configurazione per ogni architettura, consulta [Configurazione di Kerberos su Amazon EMR](emr-kerberos-configure.md).
## KDC dedicato del cluster (KDC su nodo primario)
Questa configurazione è disponibile con Amazon EMR 5.10.0 e rilasci successivi.
![\[Amazon EMRcluster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Vantaggi**
+ Amazon EMR ha la piena proprietà del server KDC.
+ Il server KDC nel cluster EMR è indipendente dalle implementazioni KDC centralizzate, ad esempio Microsoft Active Directory o AWS Managed Microsoft AD.
+ L'impatto sulle prestazioni è minimo perché il server KDC gestisce l'autenticazione solo per i nodi locali all'interno del cluster.
+ Altri cluster con Kerberos possono facoltativamente fare riferimento al server KDC come KDC esterno. Per ulteriori informazioni, consulta [KDC esterno - Nodo primario su un altro cluster](#emr-kerberos-extkdc-cluster-summary).
**Considerazioni e limitazioni**
+ I cluster con Kerberos non possono eseguire l'autenticazione tra di loro, quindi le applicazioni non possono interagire. Se le applicazioni del cluster devono interagire, è necessario stabilire un trust tra realm tra i cluster o impostare un cluster come server KDC esterno per altri cluster. Se viene stabilita una relazione di fiducia tra più aree, KDCs deve avere aree Kerberos diverse.
+ È necessario creare utenti Linux sull'istanza EC2 del nodo primario corrispondenti ai principali per l'utente KDC, nonché directory HDFS per ogni utente.
+ I principali per l'utente devono utilizzare un file di chiave privata EC2 e credenziali `kinit` per connettersi al cluster tramite SSH.
## Fiducia tra realm
In questa configurazione, i principali (di solito gli utenti) di un altro realm Kerberos eseguono l'autenticazione per i componenti applicativi su un cluster EMR con Kerberos, che ha il proprio server KDC. *Il KDC sul nodo primario stabilisce una relazione di trust con un altro KDC utilizzando un principio cross-realm esistente in entrambi.* KDCs Il nome e la password del principale corrispondono in modo preciso in ciascun KDC. I trust tra realm sono più comuni nelle implementazioni con Active Directory, come illustrato nel seguente diagramma. Sono supportati anche trust tra realm con un server KDC MIT esterno o un KDC su un altro cluster Amazon EMR.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Vantaggi**
+ Il cluster EMR su cui è installato il server KDC ne mantiene la piena proprietà.
+ Con Active Directory, Amazon EMR crea automaticamente utenti Linux corrispondenti alle entità principali per l'utente dal server KDC. È comunque necessario creare directory HDFS per ogni utente. Inoltre, i principali per l'utente nel dominio Active Directory possono accedere ai cluster con Kerberos utilizzando credenziali `kinit`, senza il file di chiave privata EC2. In questo modo viene meno la necessità di condividere il file di chiave privata tra gli utenti del cluster.
+ Poiché ogni KDC del cluster gestisce l'autenticazione per i nodi del cluster, sono ridotti al minimo gli effetti della latenza di rete e il sovraccarico di elaborazione per un numero elevato di nodi tra i cluster.
**Considerazioni e limitazioni**
+ Se si sta creando un trust con un realm Active Directory, è necessario fornire un nome utente e una password di Active Directory con le autorizzazioni per l'aggiunta di principali al dominio in cui si crea il cluster.
+ Non è possibile stabilire trust tra realm Kerberos con lo stesso nome.
+ I trust tra realm devono essere stabiliti in modo esplicito. Ad esempio, se il Cluster A e il Cluster B stabiliscono entrambi un trust tra realm con un server KDC, non hanno intrinsecamente una reciproca relazione di trust e le loro applicazioni non possono autenticarsi l'una con l'altra per interagire.
+ KDCs deve essere mantenuto in modo indipendente e coordinato in modo che le credenziali dei principali utenti corrispondano esattamente.
## KDC esterno
Le configurazioni con un server KDC esterno sono supportate con Amazon EMR 5.20.0 e versioni successive.
+ [KDC esterno-KDC MIT](#emr-kerberos-extkdc-mit-summary)
+ [KDC esterno - Nodo primario su un altro cluster](#emr-kerberos-extkdc-cluster-summary)
+ [KDC esterno: KDC del cluster su un cluster diverso con la relazione di fiducia tra realm Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC esterno-KDC MIT
Questa configurazione consente a uno o più cluster EMR di utilizzare principali definiti e gestiti in un server KDC MIT.
![\[Amazon EMRcluster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Vantaggi**
+ La gestione dei principali è consolidata in un unico KDC.
+ Più cluster possono utilizzare lo stesso KDC nello stesso realm di Kerberos. Per ulteriori informazioni, consulta [Requisiti per l'utilizzo di più cluster con lo stesso KDC](#emr-kerberos-multi-kdc).
+ La gestione del KDC non comporta rallentamenti nelle prestazioni per un nodo primario su un cluster con Kerberos.
**Considerazioni e limitazioni**
+ È necessario creare, sull'istanza EC2 di ogni nodo primario del cluster con Kerberos, utenti Linux corrispondenti ai principali per l'utente KDC, nonché directory HDFS per ogni utente.
+ I principali per l'utente devono utilizzare un file di chiave privata EC2 e credenziali `kinit` per connettersi ai cluster con Kerberos tramite SSH.
+ Ogni nodo nei cluster EMR con Kerberos deve avere un instradamento di rete al server KDC.
+ L'autenticazione di ogni nodo nei cluster con Kerberos comporta un peso per il server KDC esterno, perciò la configurazione del KDC influisce sulle prestazioni del cluster. Quando si configura l'hardware del server KDC, è opportuno considerare il numero massimo di nodi Amazon EMR da supportare contemporaneamente.
+ Le prestazioni del cluster dipendono dalla latenza di rete tra nodi nei cluster con Kerberos e il server KDC.
+ La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
### KDC esterno - Nodo primario su un altro cluster
Questa configurazione è quasi identica all'implementazione KDC MIT esterno qui sopra, l'unica differenza è che il KDC è attivo nel nodo primario di un cluster EMR. Per ulteriori informazioni, consultare [KDC dedicato del cluster (KDC su nodo primario)](#emr-kerberos-localkdc-summary) e [Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory](emr-kerberos-cross-realm.md).
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Vantaggi**
+ La gestione dei principali è consolidata in un unico KDC.
+ Più cluster possono utilizzare lo stesso KDC nello stesso realm di Kerberos. Per ulteriori informazioni, consulta [Requisiti per l'utilizzo di più cluster con lo stesso KDC](#emr-kerberos-multi-kdc).
**Considerazioni e limitazioni**
+ È necessario creare, sull'istanza EC2 di ogni nodo primario del cluster con Kerberos, utenti Linux corrispondenti ai principali per l'utente KDC, nonché directory HDFS per ogni utente.
+ I principali per l'utente devono utilizzare un file di chiave privata EC2 e credenziali `kinit` per connettersi ai cluster con Kerberos tramite SSH.
+ Ogni nodo in ciascun cluster EMR deve avere un instradamento di rete al server KDC.
+ L'autenticazione di ogni nodo Amazon EMR nei cluster con Kerberos comporta un peso per il server KDC esterno, perciò la configurazione del KDC influisce sulle prestazioni del cluster. Quando si configura l'hardware del server KDC, è opportuno considerare il numero massimo di nodi Amazon EMR da supportare contemporaneamente.
+ Le prestazioni del cluster dipendono dalla latenza di rete tra nodi nei cluster e il server KDC.
+ La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
### KDC esterno: KDC del cluster su un cluster diverso con la relazione di fiducia tra realm Active Directory
In questa configurazione, si crea prima un cluster con un server KDC dedicato che dispone di un trust tra realm monodirezionale con Active Directory. Per un tutorial dettagliato, consulta [Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory](emr-kerberos-cross-realm.md). È quindi possibile avviare ulteriori cluster facendo riferimento al KDC del cluster con il trust come KDC esterno. Per vedere un esempio, consulta [KDC esterno del cluster con trust tra realm Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). In questo modo ogni cluster Amazon EMR che utilizza il KDC esterno può autenticare le entità principali definite e gestite in un dominio Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Vantaggi**
+ La gestione dei principali è consolidata nel dominio Active Directory.
+ Amazon EMR entra nel realm di Active Directory; si elimina così la necessità di creare utenti Linux corrispondenti agli utenti di Active Directory. È comunque necessario creare directory HDFS per ogni utente.
+ Più cluster possono utilizzare lo stesso KDC nello stesso realm di Kerberos. Per ulteriori informazioni, consulta [Requisiti per l'utilizzo di più cluster con lo stesso KDC](#emr-kerberos-multi-kdc).
+ I principali per l'utente nel dominio Active Directory possono accedere ai cluster con Kerberos utilizzando credenziali `kinit`, senza il file di chiave privata EC2. In questo modo viene meno la necessità di condividere il file di chiave privata tra gli utenti del cluster.
+ Spetta a un solo un nodo primario Amazon EMR l'onere della manutenzione del KDC e solo quel cluster deve essere creato con credenziali di Active Directory per il trust tra realm tra il KDC e Active Directory.
**Considerazioni e limitazioni**
+ Ogni nodo in ogni cluster EMR deve avere un instradamento di rete al server KDC e al controller di dominio di Active Directory.
+ L'autenticazione di ogni nodo Amazon EMR comporta un peso per il server KDC esterno, perciò la configurazione del KDC influisce sulle prestazioni del cluster. Quando si configura l'hardware del server KDC, è opportuno considerare il numero massimo di nodi Amazon EMR da supportare contemporaneamente.
+ Le prestazioni del cluster dipendono dalla latenza di rete tra nodi nei cluster e il server KDC.
+ La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
## Requisiti per l'utilizzo di più cluster con lo stesso KDC
Più cluster possono utilizzare lo stesso KDC nello stesso realm di Kerberos. Tuttavia, se i cluster vengono eseguiti contemporaneamente, potrebbero fallire se utilizzano nomi Kerberos in conflitto. ServicePrincipal
Se disponi di più cluster simultanei con lo stesso KDC esterno, assicurati che i cluster utilizzino realm Kerberos diversi. Se i cluster devono utilizzare lo stesso realm Kerberos, assicurati che si trovino in sottoreti diverse e che i relativi intervalli CIDR non si sovrappongano.
# Configurazione di Kerberos su Amazon EMR
Questa sezione fornisce dettagli ed esempi di configurazione per configurare Kerberos con architetture comuni. Indipendentemente dall'architettura scelta, i passaggi di base delle configurazione sono gli stessi e vengono effettuati in tre fasi. Se si utilizza un KDC esterno o si imposta un trust tra realm, è necessario accertarsi che ogni nodo in un cluster disponga di un instradamento di rete al KDC esterno, compresa la configurazione dei gruppi di sicurezza applicabili per consentire il traffico Kerberos in entrata e in uscita.
## Fase 1: creazione di una configurazione di sicurezza con le proprietà di Kerberos
La configurazione di sicurezza specifica i dettagli del server KDC Kerberos e consente il riutilizzo della configurazione di Kerberos a ogni creazione di un cluster. Puoi creare una configurazione di sicurezza utilizzando la console Amazon EMR AWS CLI, o l'API EMR. La configurazione di sicurezza può inoltre contenere altre opzioni di sicurezza, ad esempio la crittografia. Per ulteriori informazioni sulla creazione di configurazioni di sicurezza e la specifica di una configurazione di sicurezza al momento della creazione di un cluster, consulta [Usa le configurazioni di sicurezza per configurare la sicurezza dei cluster Amazon EMR](emr-security-configurations.md). Per informazioni sulle proprietà di Kerberos in una configurazione di sicurezza, consulta [Impostazioni Kerberos per configurazioni di sicurezza](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Fase 2: creazione di un cluster e specifica di attributi Kerberos appositi per il cluster
Quando crei un cluster, specifichi una configurazione di sicurezza Kerberos insieme alle opzioni di Kerberos specifiche del cluster stesso. Quando utilizzi la console di Amazon EMR, sono disponibili solo le opzioni di Kerberos compatibili con la configurazione di sicurezza specificata. Quando utilizzi l'API AWS CLI o Amazon EMR, assicurati di specificare opzioni Kerberos compatibili con la configurazione di sicurezza specificata. Ad esempio, se quando crei un cluster con la CLI specifichi una password principale per un trust tra più realm ma la configurazione di sicurezza specificata non include parametri per questa situazione, si verifica un errore. Per ulteriori informazioni, consulta [Impostazioni Kerberos per i cluster](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Fase 3: configurazione del nodo primario del cluster
In base ai requisiti dell'architettura e dell'implementazione, può essere necessaria una configurazione aggiuntiva sul cluster. È possibile farlo dopo la sua creazione o utilizzando operazioni di bootstrap o fasi durante il processo di creazione.
Per ogni utente autenticato Kerberos che si connette al cluster tramite SSH, è necessario accertarsi che vengano creati account Linux corrispondenti agli utenti di Kerberos. Se le entità principali dell'utente vengono fornite da un controller di dominio Active Directory, sia come KDC esterno che attraverso un trust tra realm, Amazon EMR crea automaticamente account Linux. Se Active Directory non viene utilizzato, è necessario creare principali per ciascun utente corrispondenti al rispettivo utente Linux. Per ulteriori informazioni, consulta [Configurazione di un cluster Amazon EMR per utenti HDFS autenticati da Kerberos e connessioni SSH](emr-kerberos-configuration-users.md).
Ogni utente deve inoltre disporre di una directory HDFS di proprietà, che è necessario creare. Inoltre, SSH deve essere configurato con GSSAPI abilitato per consentire le connessioni dagli utenti autenticati con Kerberos. GSSAPI deve essere abilitato sul nodo primario e l'applicazione client SSH deve essere configurata per l'utilizzo di GSSAPI. Per ulteriori informazioni, consulta [Configurazione di un cluster Amazon EMR per utenti HDFS autenticati da Kerberos e connessioni SSH](emr-kerberos-configuration-users.md).
# Configurazione di sicurezza e impostazioni del cluster per Kerberos su Amazon EMR
Quando crei un cluster che utilizza Kerberos, specifichi la configurazione di sicurezza con attributi Kerberos specifici del cluster. Non puoi specificare un set senza l'altro, altrimenti si verifica un errore.
Questo argomento fornisce una panoramica dei parametri di configurazione disponibili per Kerberos al momento della creazione di una configurazione di sicurezza e di un cluster. Inoltre, sono riportati esempi di CLI per la creazione di configurazioni di sicurezza e cluster compatibili per architetture comuni.
## Impostazioni Kerberos per configurazioni di sicurezza
Puoi creare una configurazione di sicurezza che specifichi gli attributi Kerberos utilizzando la console Amazon EMR, AWS CLI o l'API EMR. La configurazione di sicurezza può inoltre contenere altre opzioni di sicurezza, ad esempio la crittografia. Per ulteriori informazioni, consulta [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
Utilizza i seguenti riferimenti per comprendere le impostazioni di configurazione di sicurezza disponibili per l'architettura Kerberos scelta. Vengono visualizzate le impostazioni della console di Amazon EMR. Per le corrispondenti opzioni con la CLI, consulta [Specificare le impostazioni Kerberos utilizzando il AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) o [Esempi di configurazione](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Impostazioni Kerberos per i cluster
Puoi specificare le impostazioni Kerberos quando crei un cluster utilizzando la console Amazon EMR, AWS CLI o l'API EMR.
Utilizza i seguenti riferimenti per comprendere le impostazioni di configurazione di cluster disponibili per l'architettura Kerberos scelta. Vengono visualizzate le impostazioni della console di Amazon EMR. Per le corrispondenti opzioni con la CLI, consulta [Esempi di configurazione](emr-kerberos-config-examples.md).
| Parametro | Description |
| --- | --- |
| Realm (Dominio) | Il nome di realm Kerberos per il cluster. La convenzione Kerberos consiste a impostare un nome identico al nome di dominio, ma in maiuscolo. Ad esempio, per il dominio `ec2.internal`, utilizza `EC2.INTERNAL` come nome di realm. |
| Password amministratore KDC | La password utilizzata nel cluster per `kadmin` o `kadmin.local`. Queste sono interfacce a riga di comando per il sistema di amministrazione Kerberos V5, che gestisce principali Kerberos, policy sulle password e keytab per il cluster. |
| Password del principale del trust tra realm (facoltativa) | Richiesta quando si stabilisce un trust tra realm. La password del principale inter-realm, che deve essere identica in tutti i realm. Utilizzare una password complessa. |
| Utente di aggiunta al dominio Active Directory (facoltativo) | Richiesto durante l'utilizzo di Active Directory in un trust tra realm. Questo è il nome di accesso utente per un account Active Directory con l'autorizzazione per aggiungere computer al dominio. Amazon EMR utilizza questa identità per aggiungere il cluster al dominio. Per ulteriori informazioni, consulta [Fase 3: aggiunta di account al dominio per il cluster EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Password di aggiunta al dominio Active Directory (facoltativa) | La password per l'utente di aggiunta al dominio Active Directory. Per ulteriori informazioni, consulta [Fase 3: aggiunta di account al dominio per il cluster EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Esempi di configurazione
Gli esempi seguenti illustrano le configurazioni di sicurezza e le configurazioni dei cluster per scenari comuni. AWS CLI i comandi sono mostrati per brevità.
## KDC locale
I seguenti comandi creano un cluster con un KDC dedicato in esecuzione sul nodo primario. È necessaria una configurazione aggiuntiva sul cluster. Per ulteriori informazioni, consulta [Configurazione di un cluster Amazon EMR per utenti HDFS autenticati da Kerberos e connessioni SSH](emr-kerberos-configuration-users.md).
**Crea una configurazione di sicurezza**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Crea cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## KDC dedicato del cluster con trust tra realm Active Directory
I seguenti comandi creano un cluster con un KDC dedicato in esecuzione sul nodo primario e un trust tra realm con un dominio di Active Directory. È necessaria una configurazione aggiuntiva sul cluster e in Active Directory. Per ulteriori informazioni, consulta [Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory](emr-kerberos-cross-realm.md).
**Crea una configurazione di sicurezza**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**Crea cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## KDC esterno su un altro cluster
I seguenti comandi creano un cluster che fa riferimento a un KDC dedicato sul nodo primario di un altro cluster per autenticare i principali. È necessaria una configurazione aggiuntiva sul cluster. Per ulteriori informazioni, consulta [Configurazione di un cluster Amazon EMR per utenti HDFS autenticati da Kerberos e connessioni SSH](emr-kerberos-configuration-users.md).
**Crea una configurazione di sicurezza**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Crea cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## KDC esterno del cluster con trust tra realm Active Directory
I seguenti comandi creano un cluster senza KDC. Il cluster fa riferimento a un KDC dedicato in esecuzione sul nodo primario di un altro cluster per autenticare i principali. Il server KDC ha un trust tra realm con controller di dominio Active Directory. È necessaria una configurazione aggiuntiva sul nodo primario con il KDC. Per ulteriori informazioni, consulta [Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory](emr-kerberos-cross-realm.md).
**Crea una configurazione di sicurezza**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**Crea cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Configurazione di un cluster Amazon EMR per utenti HDFS autenticati da Kerberos e connessioni SSH
Amazon EMR crea client utente autenticati in Kerberos per le applicazioni eseguite sul cluster, ad esempio, l'utente `hadoop`, l'utente `spark` e altri utenti. Puoi anche aggiungere utenti autenticati durante i processi del cluster mediante Kerberos. Gli utenti autenticati possono quindi connettersi al cluster con le relative credenziali Kerberos e lavorare con le applicazioni. Per consentire l'autenticazione dell'utente nel cluster, sono necessarie le seguenti configurazioni:
+ Nel cluster deve esistere un account Linux corrispondente all'entità principale di Kerberos nel KDC. Amazon EMR esegue questa operazione automaticamente nelle architetture che si integrano con Active Directory.
+ È necessario creare una directory utente HDFS nel nodo primario per ogni utente e assegnare all'utente le autorizzazioni per la directory.
+ È necessario configurare il servizio SSH in modo che GSSAPI sia abilitato per il nodo primario. Inoltre, gli utenti devono disporre di un client SSH con GSSAPI abilitato.
## Aggiunta di utenti Linux ed entità principali Kerberos al nodo primario
Se non utilizzi Active Directory, dovrai creare gli account Linux sul nodo primario del cluster e aggiungere i principali per tali utenti Linux al KDC. Questo include un principale nel KDC per il nodo primario. Oltre ai principali dell'utente, il KDC in esecuzione sul nodo primario necessita di un principale per l'host locale.
Se l'architettura include l'integrazione con Active Directory, i principali e gli utenti Linux sul server locale KDC, se applicabili, vengono creati automaticamente. Puoi ignorare questa fase. Per ulteriori informazioni, consultare [Fiducia tra realm](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) e [KDC esterno: KDC del cluster su un cluster diverso con la relazione di fiducia tra realm Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**Importante**
Il KDC, insieme al database dei principali, viene perso quando il nodo primario termina perché quest'ultimo utilizza l'archiviazione temporanea. Se si creano utenti per connessioni SSH, è consigliabile stabilire un trust tra realm con un KDC esterno configurato per la disponibilità elevata. In alternativa, se si creano utenti per connessioni SSH utilizzando account Linux, è possibile automatizzare il processo di creazione dell'account utilizzando operazioni di bootstrap e script in modo che possa essere ripetuto quando si crea un nuovo cluster.
Inviare una fase al cluster dopo averla creata oppure quando viene creato il cluster è il modo più semplice per aggiungere utenti e principali di KDC. In alternativa, è possibile connettersi al nodo primario utilizzando una coppia di chiavi EC2 come utente `hadoop` predefinito per l'esecuzione dei comandi. Per ulteriori informazioni, consulta [Connect al nodo primario del cluster Amazon EMR tramite SSH](emr-connect-master-node-ssh.md).
L'esempio seguente invia uno script Bash `configureCluster.sh` a un cluster già esistente, facendo riferimento al relativo ID di cluster. Lo script viene salvato in Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
L'esempio seguente mostra il contenuto dello script `configureCluster.sh`. Lo script gestisce anche la creazione di directory utente HDFS e l'abilitazione di GSSAPI per SSH, argomenti che saranno trattati nelle sezioni di seguito.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## Aggiunta di directory HDFS utente
Per consentire agli utenti di accedere al cluster ed eseguire processi Hadoop, è necessario aggiungere directory utente HDFS per i relativi account Linux e concedere a ciascun utente la proprietà della sua directory.
Inviare una fase al cluster dopo averla creata oppure quando viene creato il cluster è il modo più semplice per creare directory HDFS. In alternativa, è possibile connettersi al nodo primario utilizzando una coppia di chiavi EC2 come utente `hadoop` predefinito per l'esecuzione dei comandi. Per ulteriori informazioni, consulta [Connect al nodo primario del cluster Amazon EMR tramite SSH](emr-connect-master-node-ssh.md).
L'esempio seguente invia uno script Bash `AddHDFSUsers.sh` a un cluster già esistente, facendo riferimento al relativo ID di cluster. Lo script viene salvato in Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
L'esempio seguente mostra il contenuto dello script `AddHDFSUsers.sh`.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## Abilitazione di GSSAPI per SSH
Perché gli utenti autenticati in Kerberos possano connettersi al nodo primario tramite SSH, per il servizio SSH deve essere abilitato il metodo di autenticazione GSSAPI. A questo scopo, esegui i seguenti comandi dalla riga di comando del nodo primario oppure utilizza una fase per eseguirla come script. Dopo aver riconfigurato SSH, devi riavviare il servizio.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# Utilizzo di SSH per connettersi a cluster kerberizzati con Amazon EMR
Questa sezione mostra la procedura per la connessione di un utente autenticato su Kerberos al nodo primario di un cluster EMR.
Ogni computer usato per una connessione SSH deve avere installati un client SSH e applicazioni client Kerberos. Con ogni probabilità nei computer Linux sono inclusi per impostazione predefinita. Ad esempio, OpenSSH è installato nella maggior parte dei sistemi operativi Linux, Unix e macOS. È possibile verificare la presenza di un client SSH digitando **ssh** nella riga di comando. Se il computer non riconosce il comando, installa un client SSH per la connessione al nodo primario. Il progetto OpenSSH fornisce un'implementazione gratuita della suite completa di strumenti SSH. Per ulteriori informazioni, consulta il sito Web [OpenSSH](http://www.openssh.org/). Gli utenti di Windows possono utilizzare applicazioni come [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) come client SSH.
Per ulteriori informazioni sulle connessioni SSH, vedi [Connettiti a un cluster Amazon EMR](emr-connect-master-node.md).
SSH usa GSSAPI per autenticare i client Kerberos ed è necessario abilitare l'autenticazione GSSAPI per il servizio SSH nel nodo primario del cluster. Per ulteriori informazioni, consulta [Abilitazione di GSSAPI per SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Anche i client SSH devono utilizzare GSSAPI.
Negli esempi seguenti, per *MasterPublicDNS* utilizzare il valore visualizzato per **Master public DNS** nella scheda **Riepilogo del riquadro dei dettagli del cluster**, ad esempio. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Prerequisito per krb5.conf (non Active Directory)
Quando si utilizza una configurazione senza l'integrazione di Active Directory, oltre al client SSH e alle applicazioni client Kerberos, ogni computer client deve disporre di una copia del file `/etc/krb5.conf` corrispondente al file `/etc/krb5.conf` sul nodo primario del cluster.
**Per copiare il file krb5.conf**
1. Utilizza SSH per connetterti al nodo primario tramite una coppia di chiavi EC2 e l'utente `hadoop` predefinito, ad esempio `hadoop@MasterPublicDNS`. Per istruzioni dettagliate, vedi [Connettiti a un cluster Amazon EMR](emr-connect-master-node.md).
1. Dal nodo primario, copia i contenuti del file `/etc/krb5.conf`. Per ulteriori informazioni, consulta [Connettiti a un cluster Amazon EMR](emr-connect-master-node.md).
1. Su ogni computer client utilizzato per la connessione al cluster, creare un file `/etc/krb5.conf` identico basato sulla copia creata nella fase precedente.
## Utilizzo di Kinit e SSH
Ogni volta che si connette da un computer client con credenziali di Kerberos, l'utente deve prima rinnovare i ticket Kerberos per il proprio utente sul computer client. Inoltre, il client SSH deve essere configurato per utilizzare l'autenticazione GSSAPI.
**Per utilizzare SSH per la connessione a un cluster EMR con Kerberos**
1. Utilizzare `kinit` rinnovare i ticket Kerberos come nell'esempio seguente
```
kinit user1
```
1. Utilizzare un client `ssh` insieme al principale creato nel KDC dedicato al cluster o al nome utente di Active Directory. Assicurarsi che l'autenticazione GSSAPI sia abilitata come illustrato negli esempi seguenti.
**Esempio: utenti Linux**
L'opzione `-K ` specifica l'autenticazione GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Esempio: utenti Windows (PuTTY)**
Assicurarsi che l'opzione di autenticazione GSSAPI per la sessione sia abilitata come illustrato:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: configura un KDC dedicato al cluster con Amazon EMR
Questo argomento illustra come creare un cluster con un *key distribution center (KDC)* dedicato, aggiungendo manualmente account Linux a tutti i nodi cluster, aggiungendo entità principali Kerberos al KDC sul nodo primario e verificando che un client Kerberos sia installato nei computer client.
Per maggiori informazioni sul supporto di Amazon EMR per Kerberos e KDC, nonché sui collegamenti alla documentazione di MIT Kerberos, consulta [Utilizzo di Kerberos per l'autenticazione con Amazon EMR](emr-kerberos.md).
## Fase 1: Creazione del cluster che utilizza Kerberos
1. Creare una configurazione di sicurezza che attiva Kerberos. L'esempio seguente mostra un `create-security-configuration` comando che utilizza il AWS CLI che specifica la configurazione di sicurezza come struttura JSON in linea. È anche possibile fare riferimento a un file salvato in locale.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Creare un cluster che fa riferimento alla configurazione di sicurezza, stabilisce attributi Kerberos per il cluster e aggiunge account Linux utilizzando un'operazione di bootstrap. L'esempio seguente illustra l'utilizzo di un comando `create-cluster `con l' AWS CLI. Il comando fa riferimento alla configurazione di sicurezza creata precedentemente, `MyKerberosConfig`, nonché a uno script semplice, `createlinuxusers.sh`, come un'operazione di bootstrap, che deve essere creato e caricato in Amazon S3 prima di creare il cluster.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
Il codice seguente mostra il contenuto dello script `createlinuxusers.sh`, che aggiunge user1, user2 e user3 a ogni nodo nel cluster. Nella fase successiva, si aggiungeranno questi utenti come principali KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Fase 2: Aggiunta di entità principali al KDC, creazione di directory utente HDFS e configurazione di SSH
Il KDC in esecuzione sul nodo primario necessita di un principale aggiunto per l'host locale e per ciascun utente creato nel cluster. È anche possibile creare directory HDFS per ogni utente che deve connettersi al cluster ed eseguire processi Hadoop. Analogamente, configurare il servizio SSH per attivare l'autenticazione GSSAPI, necessaria per Kerberos. Dopo aver attivato GSSAPI, riavviare il servizio SSH.
Il modo più semplice di eseguire queste operazioni è di inviare una fase al cluster. L'esempio seguente invia uno script Bash `configurekdc.sh` al cluster creato nella fase precedente, facendo riferimento al relativo ID di cluster. Lo script viene salvato in Amazon S3. In alternativa, puoi connetterti al nodo primario utilizzando una coppia di chiavi EC2 per eseguire i comandi o inviare la fase durante la creazione del cluster.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
Il codice seguente mostra il contenuto dello script `configurekdc.sh`.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Gli utenti aggiunti ora dovrebbero essere in grado di connettersi al cluster tramite SSH. Per ulteriori informazioni, consulta [Utilizzo di SSH per connettersi a cluster kerberizzati con Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory
Quando configuri un trust tra realm, autorizzi i principali (di solito utenti) di un altro realm Kerberos a eseguire l'autenticazione a componenti dell'applicazione sul cluster EMR. *Il KDC *(Key Distribution Center) dedicato al cluster stabilisce una relazione di fiducia con un altro KDC* utilizzando un principio cross-realm esistente in entrambi.* KDCs Il nome e la password del principale corrispondono in modo preciso.
Un trust tra realm richiede che i KDC possano accedere l'uno all'altro sulla rete e risolvere i nomi di dominio mutualmente. Di seguito sono riportate le fasi per stabilire una relazione di trust tra realm con un controller di dominio Microsoft AD eseguito come istanza EC2, nonché un esempio di configurazione di rete che fornisce la connettività e la risoluzione dei nomi di dominio necessarie. Qualsiasi configurazione di rete che consenta il traffico di rete richiesto tra di loro è accettabile. KDCs
Facoltativamente, dopo aver stabilito un trust tra realm con Active Directory utilizzando un KDC su un cluster, è possibile creare un altro cluster utilizzando un'altra configurazione di sicurezza per fare riferimento al KDC del primo cluster come KDC esterno. Per un esempio di configurazione di sicurezza e di impostazione del cluster, consultare [KDC esterno del cluster con trust tra realm Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Per maggiori informazioni sul supporto di Amazon EMR per Kerberos e KDC, nonché sui collegamenti alla documentazione di MIT Kerberos, consulta [Utilizzo di Kerberos per l'autenticazione con Amazon EMR](emr-kerberos.md).
**Importante**
Amazon EMR non supporta trust cross-realm con. AWS Directory Service for Microsoft Active Directory
[Fase 1: Configurazione di VPC e sottorete](#emr-kerberos-ad-network)
[Fase 2: Avvio e installazione del controller di dominio Active Directory](#emr-kerberos-ad-dc)
[Fase 3: aggiunta di account al dominio per il cluster EMR](#emr-kerberos-ad-users)
[Fase 4: Configurazione di un trust in entrata sul controller di dominio Active Directory](#emr-kerberos-ad-configure-trust)
[Fase 5: Utilizzo di un set di opzioni DHCP per specificare il controller di dominio Active Directory come server DNS di VPC](#emr-kerberos-ad-DHCP)
[Fase 6: avvio di un cluster EMR che utilizza Kerberos](#emr-kerberos-ad-cluster)
[Fase 7: creazione di utenti HDFS e impostazione di autorizzazioni sul cluster per account Active Directory](#emr-kerberos-ad-hadoopuser)
## Fase 1: Configurazione di VPC e sottorete
Le fasi seguenti descrivono la creazione di un VPC e di una sottorete di modo che il KDC dedicato al cluster possa accedere al controller di dominio Active Directory e risolvere il relativo nome di dominio. In queste fasi, la risoluzione dei nomi di dominio viene fornita facendo riferimento al controller di dominio Active Directory come server dei nomi di dominio nel set di opzioni DHCP. Per ulteriori informazioni, consulta [Fase 5: Utilizzo di un set di opzioni DHCP per specificare il controller di dominio Active Directory come server DNS di VPC](#emr-kerberos-ad-DHCP).
Il KDC e il controller di dominio Active Directory devono essere in grado di risolvere uno il nome di dominio dell'altro. Ciò consente ad Amazon EMR di aggiungere computer al dominio e di configurare automaticamente gli account Linux e i parametri SSH corrispondenti sulle istanze del cluster.
Se Amazon EMR non è in grado di risolvere il nome di dominio, è possibile fare riferimento al trust utilizzando l'indirizzo IP del controller di dominio Active Directory. Tuttavia, è necessario aggiungere manualmente gli account Linux, aggiungere i principali corrispondenti al KDC dedicato al cluster e configurare SSH.
**Per configurare VPC e sottorete**
1. Creazione di un Amazon VPC con una singola sottorete pubblica Per ulteriori informazioni, consulta [Fase 1: Creazione del VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) nella *Guida alle nozioni di base su Amazon VPC*.
**Importante**
Quando utilizzi un controller di dominio Microsoft Active Directory, scegli un blocco CIDR per il cluster EMR in modo che IPv4 tutti gli indirizzi abbiano una lunghezza inferiore a nove caratteri (ad esempio, 10.0.0.0/16). Questo perché i nomi DNS dei computer del cluster vengono utilizzati quando i computer si uniscono alla directory di Active Directory. AWS assegna [nomi host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) in base IPv4 all'indirizzo in modo che indirizzi IP più lunghi possano dare come risultato nomi DNS più lunghi di 15 caratteri. Active Directory ha un limite di 15 caratteri per la registrazione di nomi di computer aggiunti e tronca i nomi più lunghi, condizione che può causare errori imprevedibili.
1. Rimuovere il set di opzioni DHCP di default assegnato al VPC. Per ulteriori informazioni, consulta [Modifica di un VPC per non utilizzare opzioni DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Successivamente, aggiungere un nuovo set che specifica il controller di dominio Active Directory come server DNS.
1. Confermare che il supporto DNS è attivato per il VPC, ovvero, che gli hostname DNS e la risoluzione DNS sono attivati (impostazione predefinita). Per ulteriori informazioni, consulta [Aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Confermare che il VPC dispone di un gateway Internet associato (impostazione predefinita). Per ulteriori informazioni, consulta l'argomento relativo alla [creazione e all'associazione di un gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**Nota**
Un gateway Internet è utilizzato in questo esempio in quanto si sta creando un nuovo controller di dominio per il VPC. È tuttavia possibile che un gateway Internet non sia necessario per l'applicazione. Il solo requisito è che il KDC dedicato al cluster possa accedere al controller di dominio Active Directory.
1. Creare una tabella di routing personalizzata, aggiungere un instradamento che porta al gateway Internet, quindi associarlo alla sottorete. Per ulteriori informazioni, consulta [Creazione di una tabella di routing personalizzata](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Quando avvii l'istanza EC2 per il controller di dominio, deve disporre di un IPv4 indirizzo pubblico statico per poterti connettere tramite RDP. Il modo più semplice per farlo è configurare la sottorete per l'assegnazione automatica di indirizzi pubblici. IPv4 che non è l'impostazione predefinita quando si crea una sottorete. Per ulteriori informazioni, vedere [Modifica dell'attributo di IPv4 indirizzamento pubblico della sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Eventualmente, è possibile assegnare l'indirizzo all'avvio dell'istanza. Per ulteriori informazioni, consulta [Assegnazione di un IPv4 indirizzo pubblico durante l'avvio dell'istanza](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Al termine, prendi nota del tuo VPC e della sottorete. IDs Questi ID saranno utilizzati in seguito quando si avvia il controller di dominio Active Directory e il cluster.
## Fase 2: Avvio e installazione del controller di dominio Active Directory
1. Avviare un'istanza EC2 basata sull'AMI di base di Microsoft Windows Server 2016. Consigliamo un tipo di istanza m4.xlarge o superiore. Per ulteriori informazioni, consulta [Launching an Marketplace AWS Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) nella *Amazon EC2* User Guide.
1. Prendere nota dell'ID del gruppo di sicurezza associato all'istanza EC2. Servirà per [Fase 6: avvio di un cluster EMR che utilizza Kerberos](#emr-kerberos-ad-cluster). Utilizziamo. *sg-012xrlmdomain345* In alternativa, è possibile specificare gruppi di sicurezza diversi per il cluster EMR e per questa istanza che consente il traffico tra di essi. Per ulteriori informazioni, consulta [Gruppi di sicurezza Amazon EC2 per le istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) nella *Guida per l'utente di Amazon EC2*.
1. Connettersi all'istanza EC2 utilizzando RDP. Per ulteriori informazioni, consulta [Connessione all'istanza Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) nella Guida per l'*utente di Amazon EC2*.
1. Avvia **Server Manager** per installare e configurare il ruolo dei servizi di dominio Active Directory sul server. Alzare il livello del server a controller di dominio e assegnare un nome di dominio (l'esempio utilizzato qui è `ad.domain.com`). Annotare il nome di dominio in quanto sarà necessario in un secondo momento quando si crea la configurazione di sicurezza EMR e il cluster. Per informazioni sulla configurazione di Active Directory, segui le istruzioni contenute in [Come configurare Active Directory (AD) in Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
L'istanza viene riavviata al termine della procedura.
## Fase 3: aggiunta di account al dominio per il cluster EMR
Esegui una connessione RDP al controller di dominio Active Directory per creare account in utenti e computer Active Directory per ogni utente del cluster. Per ulteriori informazioni, consulta [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) sul sito *Microsoft Learn*. Annotare **User logon name (Nome di accesso utente)** di ogni utente. Questi nomi saranno necessari in seguito per la configurazione del cluster.
Inoltre, crea un account con privilegi sufficienti per aggiungere computer al dominio. Questo account viene specificato quando si crea un cluster. Amazon EMR lo utilizza per aggiungere istanze di cluster al dominio. Questo account e la relativa password sono specificati in [Fase 6: avvio di un cluster EMR che utilizza Kerberos](#emr-kerberos-ad-cluster). Per delegare privilegi di aggiunta di computer all'account, è consigliabile creare un gruppo con privilegi di aggiunta e quindi assegnare l'utente al gruppo. Per istruzioni, consulta [Delega dei privilegi di aggiunta di directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) nella *Guida per l'amministrazione di AWS Directory Service *.
## Fase 4: Configurazione di un trust in entrata sul controller di dominio Active Directory
I comandi di esempio seguenti creano un trust in Active Directory, ovvero un trust tra realm unidirezionale, in entrata e non transitivo con il KDC dedicato al cluster. L'esempio che utilizziamo per il realm del cluster è `EC2.INTERNAL`. Sostituisci il nome *KDC-FQDN* con il nome **DNS pubblico** indicato per il nodo primario di Amazon EMR che ospita il KDC. Il parametro `passwordt` specifica la **cross-realm principal password (password del principale inter-realm)**, definita insieme al **realm** del cluster quando si crea un cluster. Il nome di realm è derivato dal nome di dominio di default in `us-east-1` per il cluster. `Domain` è il dominio di Active Directory in cui si crea il trust, che è minuscolo per convenzione. L'esempio utilizza `ad.domain.com`.
Aprire il prompt dei comandi di Windows con privilegi di amministratore e digitare i comandi seguenti per creare la relazione di trust sul controller di dominio Active Directory:
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## Fase 5: Utilizzo di un set di opzioni DHCP per specificare il controller di dominio Active Directory come server DNS di VPC
Ora che il controller di dominio Active Directory è configurato, è necessario configurare il VPC per utilizzarlo come server dei nomi di dominio per la risoluzione dei nomi in VPC. A questo proposito, associare un set di opzioni DHCP. Specifica il **Domain name (Nome di dominio)** come nome di dominio del cluster, ad esempio `ec2.internal` se il cluster si trova in us-east-1 o `region.compute.internal` per le altre Regioni. **Per **i server con nomi di dominio**, è necessario specificare l'indirizzo IP del controller di dominio Active Directory (che deve essere raggiungibile dal cluster) come prima voce, seguita da **AmazonProvidedDNS (ad esempio, DNS**). *xx.xx.xx.xx* AmazonProvided** Per ulteriori informazioni, consulta [Modifica dei set di opzioni DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Fase 6: avvio di un cluster EMR che utilizza Kerberos
1. In Amazon EMR, crea una configurazione di sicurezza che specifica il controller di dominio Active Directory creato nelle fasi precedenti. Un esempio di comando è riportato di seguito. Sostituire il dominio, `ad.domain.com`, con il nome del dominio specificato in [Fase 2: Avvio e installazione del controller di dominio Active Directory](#emr-kerberos-ad-dc).
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. Creare il cluster con gli attributi seguenti:
+ Utilizzare l'opzione `--security-configuration` per specificare la configurazione di sicurezza creata. *MyKerberosConfig*Nell'esempio utilizziamo.
+ Utilizzare la proprietà `SubnetId` di `--ec2-attributes option` per specificare la sottorete creata in [Fase 1: Configurazione di VPC e sottorete](#emr-kerberos-ad-network). Usiamo *step1-subnet* nell'esempio.
+ Utilizza `AdditionalMasterSecurityGroups` e `AdditionalSlaveSecurityGroups` dell'opzione `--ec2-attributes` per specificare che il gruppo di sicurezza associato al controller di dominio AD da [Fase 2: Avvio e installazione del controller di dominio Active Directory](#emr-kerberos-ad-dc) è associato al nodo primario del cluster, nonché ai nodi principali e attività. Usiamo *sg-012xrlmdomain345* nell'esempio.
Utilizzare `--kerberos-attributes` per specificare i seguenti attributi Kerberos specifici del cluster:
+ Il realm per il cluster specificato nella configurazione del controller di dominio Active Directory.
+ La password del principale del trust tra realm specificata come `passwordt` in [Fase 4: Configurazione di un trust in entrata sul controller di dominio Active Directory](#emr-kerberos-ad-configure-trust).
+ Una `KdcAdminPassword`, che può essere utilizzata per amministrare il KDC dedicato al cluster.
+ La password e il nome di accesso utente dell'account Active Directory con privilegi di aggiunta di computer creati in [Fase 3: aggiunta di account al dominio per il cluster EMR](#emr-kerberos-ad-users).
L'esempio seguente avvia un cluster che utilizza Kerberos.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## Fase 7: creazione di utenti HDFS e impostazione di autorizzazioni sul cluster per account Active Directory
Quando si configura una relazione di trust con Active Directory, Amazon EMR crea utenti Linux sul cluster per ogni account Active Directory. Ad esempio, il nome di accesso utente `LiJuan` in Active Directory dispone di un account Linux `lijuan`. I nomi utente Active Directory possono contenere lettere maiuscole, ma Linux non supporta la combinazione di maiuscole e minuscole di Active Directory.
Per consentire agli utenti di accedere al cluster ed eseguire processi Hadoop, è necessario aggiungere directory utente HDFS per i relativi account Linux e concedere a ciascun utente la proprietà della sua directory. A questo proposito, consigliamo di eseguire uno script salvato in Amazon S3 come fase di cluster. In alternativa, è possibile eseguire i comandi nello script illustrato di seguito dalla riga di comando sul nodo primario. Utilizza la coppia di chiavi EC2 specificata durante la creazione del cluster per eseguire la connessione al nodo primario tramite SSH come utente Hadoop. Per ulteriori informazioni, consulta [Usa una coppia di chiavi EC2 per le credenziali SSH per Amazon EMR](emr-plan-access-ssh.md).
Esegui il comando seguente per aggiungere un passaggio al cluster che esegue uno script,*AddHDFSUsers.sh*.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Il contenuto del file *AddHDFSUsers.sh* è il seguente.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Gruppi Active Directory mappati a gruppi Hadoop
Amazon EMR utilizza System Security Services Daemon (SSD) per mappare gruppi Active Directory a gruppi Hadoop. Per confermare le mappature dei gruppi, dopo aver eseguito l'accesso al nodo primario come descritto in [Utilizzo di SSH per connettersi a cluster kerberizzati con Amazon EMR](emr-kerberos-connect-ssh.md), puoi utilizzare il comando `hdfs groups` per confermare che i gruppi Active Directory a cui l'account Active Directory appartiene siano stati mappati a gruppi Hadoop per l'utente Hadoop corrispondente sul cluster. È inoltre possibile verificare le mappature di gruppi di altri utenti specificando uno o più nomi utente con il comando, ad esempio `hdfs groups lijuan`. Per ulteriori informazioni, consulta [groups](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) nella [Apache HDFS Commands Guide](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Utilizzo di server Active Directory o LDAP per l'autenticazione con Amazon EMR
Con i rilasci 6.12.0 e successivi di Amazon EMR, puoi utilizzare il protocollo LDAP over SSL (LDAPS) per avviare un cluster che si integra in modo nativo con il tuo server di identità aziendale. LDAP (Lightweight Directory Access Protocol) è un protocollo applicativo aperto e indipendente dal fornitore che accede e mantiene i dati. LDAP è comunemente usato per l'autenticazione degli utenti su server di identità aziendali ospitati su applicazioni come Active Directory (AD) e OpenLDAP. Con questa integrazione nativa, puoi utilizzare il tuo server LDAP per autenticare gli utenti su Amazon EMR.
I punti salienti dell'integrazione LDAP di Amazon EMR includono:
+ Amazon EMR configura le applicazioni supportate per l'autenticazione con LDAP per tuo conto.
+ Amazon EMR configura e mantiene la sicurezza per le applicazioni supportate con il protocollo Kerberos. Non è necessario immettere comandi o script.
+ Puoi ottenere il controllo granulare degli accessi (FGAC) attraverso l'autorizzazione di Apache Ranger per il database e le tabelle di Hive Metastore. Per ulteriori informazioni, consulta [Integrazione di Amazon EMR con Apache Ranger](emr-ranger.md).
+ Quando richiedi le credenziali LDAP per accedere a un cluster, ottieni un controllo granulare degli accessi (FGAC) su chi può accedere ai cluster EMR tramite SSH.
Le pagine seguenti forniscono una panoramica concettuale, i prerequisiti e le fasi per avviare un cluster EMR con l'integrazione LDAP di Amazon EMR.
**Topics**
+ [Panoramica di LDAP con Amazon EMR](ldap-overview.md)
+ [Componenti LDAP per Amazon EMR](ldap-components.md)
+ [Supporto e considerazioni sulle applicazioni con LDAP per Amazon EMR](ldap-considerations.md)
+ [Configurazione e avvio di un cluster EMR con LDAP](ldap-setup.md)
+ [Esempi di utilizzo di LDAP con Amazon EMR](ldap-examples.md)
# Panoramica di LDAP con Amazon EMR
Lightweight Directory Access Protocol (LDAP) è un protocollo software utilizzato dagli amministratori di rete per gestire e controllare l'accesso ai dati autenticando gli utenti all'interno di una rete aziendale. Il protocollo LDAP memorizza le informazioni in una struttura di directory gerarchica ad albero. *Per ulteriori informazioni, consulta [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/) su LDAP.com.*
All'interno della rete aziendale, molte applicazioni potrebbero utilizzare il protocollo LDAP per autenticare gli utenti. Con l'integrazione LDAP di Amazon EMR, i cluster EMR possono utilizzare in modo nativo lo stesso protocollo LDAP con una configurazione di sicurezza aggiuntiva.
Esistono due implementazioni principali del protocollo LDAP supportate da Amazon EMR: **Active Directory** e **OpenLDAP**. Sebbene siano possibili altre implementazioni, la maggior parte si adatta agli stessi protocolli di autenticazione di Active Directory o OpenLDAP.
## Active Directory (AD)
Active Directory (AD) è un servizio di directory di Microsoft per reti di dominio Windows. AD è incluso nella maggior parte dei sistemi operativi Windows Server e può comunicare con i client tramite i protocolli LDAP e LDAPS. Per l'autenticazione, Amazon EMR tenta di associare un utente alla tua istanza AD utilizzando lo User Principal Name (UPN) come nome distinto e password. L'UPN utilizza il formato standard `username@domain_name`.
## OpenLDAP
OpenLDAP è un'implementazione gratuita e open-source del protocollo LDAP. Per l'autenticazione, Amazon EMR tenta di associare un utente alla tua istanza OpenLDAP con il nome di dominio completo (FQDN) come nome distinto e password. L'FQDN utilizza il formato standard `username_attribute=username,LDAP_user_search_base`. In genere, il valore di `username_attribute` è `uid` e il valore `LDAP_user_search_base` contiene gli attributi della struttura ad albero che conduce all'utente. Ad esempio, `ou=People,dc=example,dc=com`.
Altre implementazioni gratuite e open-source del protocollo LDAP in genere seguono un FQDN simile a OpenLDAP per i nomi distinti dei loro utenti.
# Componenti LDAP per Amazon EMR
Puoi utilizzare il tuo server LDAP per autenticarti con Amazon EMR e qualsiasi applicazione che l'utente utilizza direttamente sul cluster EMR tramite i seguenti componenti.
**Agente segreto**
L'*agente segreto* è un processo in cluster che autentica tutte le richieste degli utenti. L'agente segreto crea l'associazione utente al server LDAP per conto delle applicazioni supportate sul cluster EMR. L'agente segreto viene eseguito come utente `emrsecretagent` e scrive log nella directory `/emr/secretagent/log`. Questi log forniscono dettagli sullo stato della richiesta di autenticazione di ciascun utente e sugli eventuali errori che potrebbero emergere durante l'autenticazione dell'utente.
**Daemon dei servizi di sicurezza del sistema (SSSD)**
*SSSD* è un daemon che viene eseguito su ogni nodo di un cluster EMR abilitato per LDAP. SSSD crea e gestisce un utente UNIX per sincronizzare l'identità aziendale remota su ciascun nodo. Le applicazioni basate su YARN come Hive e Spark richiedono l'esistenza di un utente UNIX locale su ogni nodo che esegue una query per un utente.
# Supporto e considerazioni sulle applicazioni con LDAP per Amazon EMR
Questo argomento elenca le applicazioni supportate, le funzionalità supportate e le funzionalità non supportate.
## Applicazioni supportate con LDAP per Amazon EMR
**Importante**
Le applicazioni elencate in questa pagina sono le uniche applicazioni supportate da Amazon EMR per LDAP. Per garantire la sicurezza dei cluster, è possibile includere solo applicazioni compatibili con LDAP quando si crea un cluster EMR con il protocollo LDAP abilitato. Se tenti di installare altre applicazioni non supportate, Amazon EMR rifiuta la richiesta di un nuovo cluster.
I rilasci 6.12 e successivi di Amazon EMR supportano l'integrazione LDAP con le seguenti applicazioni:
+ Apache Livy
+ Da Apache Hive a 2 () HiveServer HS2
+ Trino
+ Presto
+ Hue
Le seguenti applicazioni possono essere installate in un cluster EMR e possono essere configurate per soddisfare le esigenze di sicurezza:
+ Apache Spark
+ Apache Hadoop
## Funzionalità supportate con LDAP per Amazon EMR
Puoi utilizzare le seguenti funzionalità di Amazon EMR con l'integrazione LDAP:
**Nota**
Per proteggere le credenziali LDAP, devi utilizzare la crittografia in transito per proteggere il flusso di dati all'interno e all'esterno del cluster. Per maggiori informazioni sulla crittografia in transito, consulta [Crittografa i dati inattivi e in transito con Amazon EMR](emr-data-encryption.md).
+ Crittografia dei dati in transito (obbligatoria) e a riposo
+ Gruppi di istanze, parchi istanze e istanze Spot
+ Riconfigurazione delle applicazioni in un cluster in esecuzione
+ Server-Side Encryption (SSE) EMRFS
## Caratteristiche non supportate
Considera le seguenti limitazioni quando utilizzi l'integrazione LDAP di Amazon EMR:
+ Amazon EMR disabilita i passaggi per i cluster con LDAP abilitato.
+ Amazon EMR non supporta ruoli di runtime e AWS Lake Formation integrazioni per cluster con LDAP abilitato.
+ Amazon EMR non supporta LDAP con StartTLS.
+ Amazon EMR non supporta la modalità ad alta disponibilità (cluster con più nodi primari) per i cluster con LDAP abilitato.
+ Non puoi ruotare le credenziali o i certificati di associazione per i cluster con LDAP abilitato. Se uno di questi campi è stato ruotato, ti consigliamo di avviare un nuovo cluster con le credenziali o i certificati di associazione aggiornati.
+ È necessario utilizzare basi di ricerca esatte con LDAP. La base di ricerca LDAP per utenti e gruppi non supporta i filtri di ricerca LDAP.
# Configurazione e avvio di un cluster EMR con LDAP
Questa sezione spiega come configurare Amazon EMR per l'uso con l'autenticazione LDAP.
**Topics**
+ [Aggiungi Gestione dei segreti AWS autorizzazioni al ruolo dell'istanza Amazon EMR](ldap-setup-asm.md)
+ [Creazione della configurazione di sicurezza di Amazon EMR per l'integrazione LDAP](ldap-setup-security.md)
+ [Avvio di un cluster EMR che si autentica con LDAP](ldap-setup-launch.md)
# Aggiungi Gestione dei segreti AWS autorizzazioni al ruolo dell'istanza Amazon EMR
Amazon EMR utilizza un ruolo di servizio IAM per eseguire operazioni per tuo conto per il provisioning e la gestione dei cluster. Il ruolo di servizio per le istanze EC2 del cluster, detto anche *profilo dell'istanza EC2 per Amazon EMR*, è un tipo speciale di ruolo di servizio che Amazon EMR assegna a ogni istanza EC2 in un cluster all'avvio.
Per definire le autorizzazioni per fare in modo che un cluster EMR interagisca con i dati Amazon S3 e altri servizi AWS , definisci un profilo di istanza Amazon EC2 personalizzato da utilizzare al posto di `EMR_EC2_DefaultRole` quando avvii il cluster. Per ulteriori informazioni, consultare [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md) e [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md).
Aggiungi le seguenti istruzioni al profilo di istanza EC2 predefinito per consentire ad Amazon EMR di etichettare le sessioni e accedere ai Gestione dei segreti AWS certificati LDAP che archivia.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**Nota**
Le richieste dei cluster daranno esito negativo se dimentichi il carattere jolly `*` alla fine del nome segreto quando imposti le autorizzazioni di Secrets Manager. Il carattere jolly rappresenta le versioni segrete.
È inoltre necessario limitare l'ambito della Gestione dei segreti AWS policy ai soli certificati necessari al cluster per il provisioning delle istanze.
# Creazione della configurazione di sicurezza di Amazon EMR per l'integrazione LDAP
Prima di avviare un cluster EMR con integrazione LDAP, segui i passaggi riportati [Crea una configurazione di sicurezza con la console Amazon EMR o con AWS CLI](emr-create-security-configuration.md) per creare una configurazione di sicurezza Amazon EMR per il cluster. Completa le seguenti configurazioni nel blocco `LDAPConfiguration` in `AuthenticationConfiguration` o nei campi corrispondenti nella sezione **Configurazioni di sicurezza** della console Amazon EMR:
**`EnableLDAPAuthentication`**
Opzione console: **Protocollo di autenticazione: LDAP**
Per utilizzare l'integrazione LDAP, imposta questa opzione su `true` o selezionala come protocollo di autenticazione quando crei un cluster nella console. Per impostazione predefinita, `EnableLDAPAuthentication` è `true` quando crei una configurazione di sicurezza nella console Amazon EMR.
**`LDAPServerURL`**
Opzione console: **posizione del server LDAP**
La posizione del server LDAP, incluso il prefisso: `ldaps://location_of_server`.
**`BindCertificateARN`**
Opzione console: **certificato SSL LDAP**
L' Gestione dei segreti AWS ARN che contiene il certificato per firmare il certificato SSL utilizzato dal server LDAP. Se il server LDAP è firmato da un'autorità di certificazione (CA) pubblica, puoi fornire un Gestione dei segreti AWS ARN con un file vuoto. Per ulteriori informazioni su come archiviare il certificato in Secrets Manager, consulta [Archivia i certificati TLS in Gestione dei segreti AWS](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opzione console: **credenziali di associazione del server LDAP**
Un Gestione dei segreti AWS ARN che contiene le credenziali di associazione dell'utente amministratore LDAP. Le credenziali sono archiviate come oggetto JSON. Esiste una sola coppia chiave-valore in questo segreto; la chiave nella coppia è il nome utente e il valore è la password. Ad esempio, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Questo campo è facoltativo, a meno che non abiliti l'accesso SSH per il cluster EMR. In molte configurazioni, le istanze di Active Directory richiedono credenziali di associazione per consentire a SSSD di sincronizzare gli utenti.
**`LDAPAccessFilter`**
Opzione console: **filtro di accesso LDAP**
Specifica il sottoinsieme di oggetti all'interno del server LDAP che possono effettuare l'autenticazione. Ad esempio, se si desidera concedere l'accesso a tutti gli utenti con la classe di oggetti `posixAccount` nel server LDAP, il filtro di accesso viene definito come `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opzione console: **base di ricerca utenti LDAP**
La base di ricerca a cui appartengono gli utenti all'interno del server LDAP. Ad esempio, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Opzione console: **base di ricerca per gruppi LDAP**
La base di ricerca a cui appartengono i gruppi all'interno del server LDAP. Ad esempio, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Opzione console: **accesso SSH**
Specifica se consentire o meno l'autenticazione tramite password con credenziali LDAP. Ti consigliamo di abilitare questa opzione. Le coppie di chiavi rappresentano un percorso più sicuro per consentire l'accesso ai cluster EMR. Questo campo è facoltativo e, per impostazione predefinita, corrisponde a `false`.
**`LDAPServerType`**
Opzione console: **tipo di server LDAP**
Specifica il tipo di server LDAP a cui si connette Amazon EMR. Le opzioni supportate sono Active Directory e OpenLDAP. Altri tipi di server LDAP potrebbero funzionare, ma Amazon EMR non supporta ufficialmente altri tipi di server. Per ulteriori informazioni, consulta [Componenti LDAP per Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Un blocco secondario necessario per le configurazioni di sicurezza che utilizzano il tipo di server Active Directory.
**`ADDomain`**
Opzione console: **dominio Active Directory**
Il nome di dominio utilizzato per creare lo User Principal Name (UPN) per l'autenticazione degli utenti con configurazioni di sicurezza che utilizzano il tipo di server Active Directory.
## Considerazioni sulle configurazioni di sicurezza con LDAP e Amazon EMR
+ Per creare una configurazione di sicurezza con l'integrazione LDAP di Amazon EMR, devi utilizzare la crittografia in transito. Per informazioni sulla crittografia in transito, consulta [Crittografa i dati inattivi e in transito con Amazon EMR](emr-data-encryption.md).
+ Non è possibile definire la configurazione Kerberos nella stessa configurazione di sicurezza. Amazon EMR fornisce un KDC dedicato all'automazione e gestisce la password di amministratore per questo KDC. Gli utenti non possono accedere alla password di amministratore.
+ Non è possibile definire ruoli di runtime IAM AWS Lake Formation nella stessa configurazione di sicurezza.
+ Nel valore dell'`LDAPServerURL` deve essere compreso il protocollo `ldaps://`.
+ Il `LDAPAccessFilter` non può essere vuoto.
## Utilizzo di LDAP con l'integrazione di Apache Ranger per Amazon EMR
Con l'integrazione LDAP per Amazon EMR, puoi integrare ulteriormente con Apache Ranger. Quando trasferisci gli utenti LDAP in Ranger, puoi associare questi utenti a un server di policy Apache Ranger per eseguire l'integrazione con Amazon EMR e altre applicazioni. Per fare ciò, definisci il campo `RangerConfiguration` all'interno di `AuthorizationConfiguration` nella configurazione di sicurezza che usi con il cluster LDAP. Per ulteriori informazioni su come impostare la configurazione di sicurezza, consulta [Creazione di una configurazione di sicurezza EMR](emr-ranger-security-config.md).
Quando usi LDAP con Amazon EMR, non devi necessariamente fornire una `KerberosConfiguration` con l'integrazione Amazon EMR per Apache Ranger.
# Avvio di un cluster EMR che si autentica con LDAP
Utilizza i seguenti passaggi per avviare un cluster EMR con LDAP o Active Directory.
1. Configurazione dell'ambiente:
+ Assicurati che i nodi del tuo cluster EMR possano comunicare con Amazon S3 e. Gestione dei segreti AWS Per ulteriori informazioni su come modificare il ruolo del profilo dell'istanza EC2 per comunicare con questi servizi, consulta [Aggiungi Gestione dei segreti AWS autorizzazioni al ruolo dell'istanza Amazon EMR](ldap-setup-asm.md).
+ Se prevedi di eseguire il tuo cluster EMR in una sottorete privata, dovresti utilizzare uno degli endpoint AWS PrivateLink Amazon VPC o utilizzare la traduzione degli indirizzi di rete (NAT) per configurare il VPC per comunicare con S3 e Secrets Manager. Per ulteriori informazioni, consulta [Endpoint AWS PrivateLink e VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) e [Istanze NAT](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) nella *Guida alle operazioni di base di Amazon VPC*.
+ Assicurati che ci sia connettività di rete tra il tuo cluster Amazon EMR e il server LDAP. I cluster EMR devono accedere al server LDAP tramite la rete. I nodi primario, principale e attività per il cluster comunicano con il server LDAP per la sincronizzazione dei dati degli utenti. Se il tuo server LDAP viene eseguito su Amazon EC2, aggiorna il gruppo di sicurezza EC2 per accettare il traffico dal cluster EMR. Per ulteriori informazioni, consulta [Aggiungi Gestione dei segreti AWS autorizzazioni al ruolo dell'istanza Amazon EMR](ldap-setup-asm.md).
1. Crea una configurazione di sicurezza di Amazon EMR per l'integrazione LDAP. Per ulteriori informazioni, consulta [Creazione della configurazione di sicurezza di Amazon EMR per l'integrazione LDAP](ldap-setup-security.md).
1. Ora che hai eseguito la configurazione, segui i passaggi indicati in [Avvio di un cluster Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) per avviare il cluster con le seguenti impostazioni:
+ Seleziona il rilascio 6.12 o successivo di Amazon EMR. Consigliamo di utilizzare l'ultimo rilascio di Amazon EMR.
+ Specifica o seleziona solo le applicazioni per il cluster che supportano LDAP. Per un elenco di applicazioni supportate da LDAP con Amazon EMR, consulta [Supporto e considerazioni sulle applicazioni con LDAP per Amazon EMR](ldap-considerations.md).
+ Applica la configurazione di sicurezza che hai creato nel passaggio precedente.
# Esempi di utilizzo di LDAP con Amazon EMR
Dopo aver effettuato il [provisioning di un cluster EMR che utilizza l'integrazione LDAP](ldap-setup-launch.md), puoi fornire le credenziali LDAP a qualsiasi [applicazione supportata](ldap-considerations.md#ldap-considerations-apps) tramite il meccanismo di autenticazione integrato di nome utente e password. In questa pagina sono riportati alcuni esempi.
## Utilizzo dell'autenticazione LDAP con Apache Hive
**Example - Apache Hive**
Il seguente comando di esempio avvia una sessione di Apache Hive tramite 2 e Beeline: HiveServer
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Utilizzo dell'autenticazione LDAP con Apache Livy
**Example - Apache Livy**
Il comando di esempio seguente avvia una sessione Livy tramite cURL. Sostituisci `ENCODED-KEYPAIR` con una stringa codificata in Base64 per `username:password`.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Utilizzo dell'autenticazione LDAP con Presto
**Example - Presto**
Il seguente comando di esempio avvia una sessione Presto tramite la CLI Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Dopo aver eseguito questo comando, quando richiesto, inserisci la password LDAP.
## Utilizzo dell'autenticazione LDAP con Trino
**Example - Trino**
Il seguente comando di esempio avvia una sessione Trino tramite la CLI di Trino:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Dopo aver eseguito questo comando, quando richiesto, inserisci la password LDAP.
## Utilizzo dell'autenticazione LDAP con Hue
Puoi accedere all'interfaccia utente di Hue tramite un tunnel SSH creato sul cluster oppure puoi impostare un server proxy per trasmettere pubblicamente la connessione a Hue. Poiché Hue non funziona in modalità HTTPS per impostazione predefinita, ti consigliamo di utilizzare un livello di crittografia aggiuntivo per garantire che la comunicazione tra i client e l'interfaccia utente di Hue sia crittografata con HTTPS. In questo modo si riduce la possibilità di esporre accidentalmente le credenziali utente in formato di testo normale.
Per utilizzare l'interfaccia utente di Hue, apri l'interfaccia utente di Hue nel browser e inserisci nome utente e password LDAP per accedere. Se le credenziali sono corrette, Hue effettua l'accesso e utilizza la tua identità per eseguire l'autenticazione con tutte le applicazioni supportate.
## Utilizzo di SSH per l'autenticazione tramite password e ticket Kerberos per altre applicazioni
**Importante**
Non è consigliabile utilizzare l'autenticazione tramite password su SSH in un cluster EMR.
È possibile utilizzare le credenziali LDAP per accedere a un cluster EMR tramite SSH. A tale scopo, imposta la configurazione di `EnableSSHLogin` su `true` nella configurazione di sicurezza di Amazon EMR utilizzata per avviare il cluster. Quindi, usa il seguente comando per accedere al cluster tramite SSH una volta avviato:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Dopo aver eseguito questo comando, quando richiesto, inserisci la password LDAP.
Amazon EMR include uno script su cluster che consente agli utenti di generare un file keytab Kerberos e un ticket da utilizzare con le applicazioni supportate che non accettano direttamente le credenziali LDAP. Alcune di queste applicazioni includono Spark `spark-submit` SQL e. PySpark
Esegui `ldap-kinit` e segui le istruzioni. Se l'autenticazione ha esito positivo, il file keytab Kerberos viene visualizzato nella directory home con un ticket Kerberos valido. Utilizza il ticket Kerberos per eseguire le applicazioni come faresti in qualsiasi ambiente con Kerberos.
# Integra Amazon EMR con AWS IAM Identity Center
Con le versioni 6.15.0 e successive di Amazon EMR, puoi utilizzare identità da per AWS IAM Identity Center autenticarti con un cluster Amazon EMR. Le sezioni seguenti forniscono una panoramica concettuale, i prerequisiti e le fasi necessari per avviare un cluster EMR con l'integrazione del Centro identità.
**Topics**
+ [Panoramica di](#emr-idc-overview)
+ [Funzionalità e vantaggi](#emr-idc-features)
+ [Guida introduttiva AWS IAM Identity Center ad Amazon EMR](emr-idc-start.md)
+ [Sessioni in background degli utenti](user-background-sessions.md)
+ [Considerazioni e limitazioni per Amazon EMR con l'integrazione del Centro identità](emr-idc-considerations.md)
## Panoramica di
[Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) è l'approccio consigliato per l'autenticazione e l'autorizzazione della forza lavoro per organizzazioni di qualsiasi dimensione e tipo. AWS Con Identity Center, puoi creare e gestire identità utente o connettere la tua fonte di identità esistente AWS, tra cui Microsoft Active Directory, Okta, Ping Identity JumpCloud, Google Workspace e Microsoft Entra ID (precedentemente Azure AD).
[La propagazione affidabile delle identità](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) è una AWS IAM Identity Center funzionalità che gli amministratori di Connected Servizi AWS possono utilizzare per concedere e controllare l'accesso ai dati del servizio. L’accesso a questi dati si basa su attributi utente come le associazioni di gruppo. La configurazione di una propagazione affidabile delle identità richiede la collaborazione tra gli amministratori di connected Servizi AWS e gli amministratori di IAM Identity Center. Per ulteriori informazioni, consulta [Prerequisites and considerations](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
## Funzionalità e vantaggi
L'integrazione di Amazon EMR con il Centro identità IAM offre i seguenti vantaggi:
+ Amazon EMR fornisce le credenziali per inoltrare l'identità del tuo Centro identità a un cluster EMR.
+ Amazon EMR configura tutte le applicazioni supportate per l'autenticazione con le credenziali del cluster.
+ Amazon EMR configura e mantiene la sicurezza per le applicazioni supportate con il protocollo Kerberos senza la necessità di tuoi comandi o script.
+ La capacità di applicare l'autorizzazione a livello di prefisso di Amazon S3 con le identità del Centro identità sui prefissi S3 gestiti da S3 Access Grants.
+ La capacità di applicare l'autorizzazione a livello di tabella con le identità di Identity Center sulle tabelle Glue gestite AWS Lake Formation . AWS
# Guida introduttiva AWS IAM Identity Center ad Amazon EMR
Questa sezione ti aiuta a configurare Amazon EMR per l'integrazione con. AWS IAM Identity Center
**Topics**
+ [Crea un'istanza del Centro identità](#emr-idc-start-instance)
+ [Crea un ruolo IAM per il Centro identità](#emr-idc-start-role)
+ [Aggiungi le autorizzazioni per i servizi non integrati con IAM Identity Center](#emr-idc-start-securityconfig-nonidc)
+ [Crea una configurazione di sicurezza abilitata per il Centro identità](#emr-idc-start-securityconfig)
+ [Crea e avvia un cluster abilitato per il Centro identità](#emr-idc-cluster)
+ [Configura Lake Formation per un cluster EMR abilitato per il Centro identità IAM](emr-idc-lf.md)
+ [Utilizzo di S3 Access Grants su un cluster EMR abilitato per il Centro identità IAM](emr-idc-s3ag.md)
**Nota**
Per utilizzare Identity Center, è necessario abilitare l'integrazione con EMR, Lake Formation o S3 Access Grants. Puoi anche usarli entrambi. Se nessuno dei due è abilitato, l'integrazione con Identity Center non è supportata.
## Crea un'istanza del Centro identità
Se non ne hai ancora una, crea un'istanza del Centro identità nella Regione AWS in cui desideri avviare il cluster EMR. Un'istanza del Centro identità può esistere solo in una singola regione per un Account AWS.
Utilizzate il AWS CLI comando seguente per creare una nuova istanza denominata`MyInstance`:
```
aws sso-admin create-instance --name MyInstance
```
## Crea un ruolo IAM per il Centro identità
Con cui integrare Amazon EMR AWS IAM Identity Center, crea un ruolo IAM che si autentichi con Identity Center dal cluster EMR. Dietro le quinte, Amazon EMR utilizza le credenziali SigV4 per inoltrare l'identità del Centro identità a servizi downstream come AWS Lake Formation. Il tuo ruolo dovrebbe avere anche le autorizzazioni necessarie per richiamare i servizi downstream.
Quando crei il ruolo, utilizza la seguente policy di autorizzazione:
```
{
"Statement": [
{
"Sid": "IdCPermissions",
"Effect": "Allow",
"Action": [
"sso-oauth:*"
],
"Resource": "*"
},
{
"Sid": "GlueandLakePermissions",
"Effect": "Allow",
"Action": [
"glue:*",
"lakeformation:GetDataAccess"
],
"Resource": "*"
},
{
"Sid": "AccessGrantsPermissions",
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": "*"
}
]
}
```
La policy di attendibilità per questo ruolo consente al ruolo InstanceProfile di assumere quel ruolo.
```
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678912:role/EMR_EC2_DefaultRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
```
Se il ruolo non dispone di credenziali affidabili e accede a una tabella protetta da Lake Formation, Amazon EMR imposta `principalId` automaticamente il ruolo assunto su. `userID-untrusted` Di seguito è riportato un frammento di un evento che mostra il. CloudTrail `principalId`
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "ABCDEFGH1JKLMNO2PQR3TU:5000-untrusted",
"arn": "arn:aws:sts::123456789012:assumed-role/EMR_TIP/5000-untrusted",
"accountId": "123456789012",
"accessKeyId": "ABCDEFGH1IJKLMNOPQ7R3"
...
```
## Aggiungi le autorizzazioni per i servizi non integrati con IAM Identity Center
AWS credenziali che utilizzano Trusted Identity Propagation, le politiche IAM definite nel ruolo IAM per tutte le chiamate effettuate a servizi non integrati con IAM Identity Center. Ciò include, ad esempio, il. AWS Key Management Service Il tuo ruolo dovrebbe anche definire eventuali autorizzazioni IAM per tutti i servizi a cui tenteresti di accedere, ad esempio AWS Key Management Service. I servizi integrati IAM Identity Center attualmente supportati includono AWS Lake Formation Amazon S3 Access Grants.
Per ulteriori informazioni su Trusted Identity Propagation, consulta [Trusted Identity Propagation](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation.html) tra le applicazioni.
## Crea una configurazione di sicurezza abilitata per il Centro identità
Per avviare un cluster EMR con l'integrazione del Centro identità IAM, utilizza il seguente comando di esempio per creare una configurazione di sicurezza Amazon EMR con il Centro identità abilitato. Ogni configurazione è spiegata di seguito.
```
aws emr create-security-configuration --name "IdentityCenterConfiguration-with-lf-accessgrants" --region "us-west-2" --security-configuration '{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterApplicationAssigmentRequired":false,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789"
}
},
"AuthorizationConfiguration": {
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
},
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
}
},
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
+ **`EnableIdentityCenter`**: (obbligatorio) abilita l'integrazione del Centro identità.
+ **`IdentityCenterInstanceARN`**— (opzionale) L'ARN dell'istanza di Identity Center. Se questo non è incluso, l'ARN dell'istanza IAM Identity Center esistente viene cercato come parte della fase di configurazione.
+ **`IAMRoleForEMRIdentityCenterApplicationARN`**: (obbligatorio) il ruolo IAM che procura i token del Centro identità dal cluster.
+ **`IdentityCenterApplicationAssignmentRequired `**: (booleano) determina se sarà richiesta un'assegnazione per utilizzare l'applicazione del Centro identità. Questo campo è facoltativo. Se non viene fornito un valore, il valore predefinito è`false`.
+ **`AuthorizationConfiguration`/`LakeFormationConfiguration`**— Facoltativamente, configura l'autorizzazione:
+ **`IAMConfiguration`**— Consente l'utilizzo della funzionalità EMR Runtimes Roles in aggiunta all'identità TIP. Se abiliti questa configurazione, a te (o al AWS servizio chiamante) verrà richiesto di specificare un IAM Runtime Role in ogni chiamata a EMR Steps o EMR. `GetClusterSessionCredentials` APIs Se il cluster EMR viene utilizzato con SageMaker Unified Studio, questa opzione è necessaria se è abilitata anche la Trusted Identity Propagation.
+ **`EnableLakeFormation`**: abilita l'autorizzazione di Lake Formation sul cluster.
Per abilitare l'integrazione del Centro identità con Amazon EMR, devi specificare `EncryptionConfiguration` e. `IntransitEncryptionConfiguration`
## Crea e avvia un cluster abilitato per il Centro identità
Ora che hai configurato il ruolo IAM che esegue l'autenticazione con il Centro identità e hai creato una configurazione di sicurezza Amazon EMR con il Centro identità abilitato, puoi creare e avviare il tuo cluster con riconoscimento dell'identità. Per i passaggi per avviare il cluster con la configurazione di sicurezza richiesta, consulta [Specificare una configurazione di sicurezza per un cluster Amazon EMR](emr-specify-security-configuration.md).
Le seguenti sezioni descrivono come configurare un cluster abilitato per Identity Center con le opzioni di sicurezza supportate da Amazon EMR:
+ [Utilizzo di S3 Access Grants su un cluster EMR abilitato per il Centro identità IAM](emr-idc-s3ag.md)
+ [Configura Lake Formation per un cluster EMR abilitato per il Centro identità IAM](emr-idc-lf.md)
# Configura Lake Formation per un cluster EMR abilitato per il Centro identità IAM
Puoi integrarti [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/)con il tuo cluster EMR AWS IAM Identity Center abilitato.
Innanzitutto, assicurati di avere un'istanza del Centro identità configurata nella stessa regione del cluster. Per ulteriori informazioni, consulta [Crea un'istanza del Centro identità](emr-idc-start.md#emr-idc-start-instance). Puoi trovare l'ARN dell'istanza nella console del Centro identità IAM quando visualizzi i dettagli dell'istanza o utilizzare il seguente comando per visualizzare i dettagli di tutte le istanze dalla CLI:
```
aws sso-admin list-instances
```
Quindi usa l'ARN e l'ID del tuo AWS account con il seguente comando per configurare Lake Formation in modo che sia compatibile con IAM Identity Center:
```
aws lakeformation create-lake-formation-identity-center-configuration --cli-input-json file://create-lake-fromation-idc-config.json
json input:
{
"CatalogId": "account-id/org-account-id",
"InstanceArn": "identity-center-instance-arn"
}
```
Ora, chiama `put-data-lake-settings` e abilita `AllowFullTableExternalDataAccess` con Lake Formation:
```
aws lakeformation put-data-lake-settings --cli-input-json file://put-data-lake-settings.json
json input:
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "admin-ARN"
}
],
"CreateDatabaseDefaultPermissions": [...],
"CreateTableDefaultPermissions": [...],
"AllowExternalDataFiltering": true,
"AllowFullTableExternalDataAccess": true
}
}
```
Infine, concedi le autorizzazioni complete per la tabella all'ARN dell'identità per l'utente che accede al cluster EMR. L'ARN contiene l'ID utente del Centro identità. Vai al Centro identità nella console, seleziona **Utenti** e poi l'utente per visualizzarne le impostazioni delle **Informazioni generali**.
Copia l'ID utente e incollalo nel seguente ARN per `user-id`:
```
arn:aws:identitystore:::user/user-id
```
**Nota**
Le query sul cluster EMR funzionano solo se l'identità del Centro identità IAM ha accesso completo alla tabella protetta di Lake Formation. Se l'identità non ha accesso completo alla tabella, la query avrà esito negativo.
Per concedere all'utente l'accesso completo alla tabella, utilizza il seguente comando:
```
aws lakeformation grant-permissions --cli-input-json file://grantpermissions.json
json input:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:identitystore:::user/user-id"
},
"Resource": {
"Table": {
"DatabaseName": "tip_db",
"Name": "tip_table"
}
},
"Permissions": [
"ALL"
],
"PermissionsWithGrantOption": [
"ALL"
]
}
```
## Aggiungere l'applicazione ARN all'integrazione di IDC for Lake Formation
Per interrogare le risorse abilitate a Lake Formation, è necessario aggiungere l'ARN dell'applicazione IDC. A tale scopo, seguire queste fasi:
1. Sulla console, scegli **AWS Lake Formation**.
1. Seleziona l'integrazione con **IAM Identity Center e l'integrazione** **dell'applicazione Lake Formation** abbinando l'ARN dell'applicazione. L'ARN verrà visualizzato nell'elenco degli **ID dell'applicazione.**
# Utilizzo di S3 Access Grants su un cluster EMR abilitato per il Centro identità IAM
Puoi integrare [S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) con il tuo cluster AWS IAM Identity Center EMR abilitato.
Utilizza S3 Access Grants per autorizzare l'accesso ai tuoi set di dati dai cluster che utilizzano il Centro identità. Crea autorizzazioni per aumentare quelle impostate per utenti, gruppi, ruoli IAM o per una directory aziendale. Per ulteriori informazioni, consulta [Utilizzo di S3 Access Grants con Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-access-grants.html).
**Topics**
+ [Crea un'istanza e una posizione S3 Access Grants](#emr-idc-s3ag-instance)
+ [Crea autorizzazioni per le identità del Centro identità](#emr-idc-s3ag-identities)
## Crea un'istanza e una posizione S3 Access Grants
Se non ne hai ancora una, crea un'istanza S3 Access Grants nella Regione AWS in cui desideri avviare il cluster EMR.
Usa il seguente AWS CLI comando per creare una nuova istanza denominata: `MyInstance`
```
aws s3control-access-grants create-access-grants-instance \
--account-id 12345678912 \
--identity-center-arn "identity-center-instance-arn" \
```
Quindi, crea una posizione S3 Access Grants, sostituendo i valori rossi con:
```
aws s3control-access-grants create-access-grants-location \
--account-id 12345678912 \
--location-scope s3:// \
--iam-role-arn "access-grant-role-arn" \
--region aa-example-1
```
**Nota**
Definisci il parametro `iam-role-arn` come ARN `accessGrantRole`.
## Crea autorizzazioni per le identità del Centro identità
Infine, crea le autorizzazioni per le identità che hanno accesso al tuo cluster:
```
aws s3control-access-grants create-access-grant \
--account-id 12345678912 \
--access-grants-location-id "default" \
--access-grants-location-configuration S3SubPrefix="s3-bucket-prefix"
--permission READ \
--grantee GranteeType=DIRECTORY_USER,GranteeIdentifier="your-identity-center-user-id"
```
Output di esempio:
```
{
"CreatedAt": "2023-09-21T23:47:24.870000+00:00",
"AccessGrantId": "1234-12345-1234-1234567",
"AccessGrantArn": "arn:aws:s3:aa-example-1-1:123456789012:access-grants/default/grant/xxxx1234-1234-5678-1234-1234567890",
"Grantee": {
"GranteeType": "DIRECTORY_USER",
"GranteeIdentifier": "5678-56789-5678-567890"
},
"AccessGrantsLocationId": "default",
"AccessGrantsLocationConfiguration": {
"S3SubPrefix": "myprefix/*"
},
"Permission": "READ",
"GrantScope": "s3://myprefix/*"
}
```
# Sessioni in background degli utenti
Le sessioni utente in background consentono ai carichi di lavoro di analisi e machine learning di lunga durata di continuare anche dopo che l'utente si è disconnesso dall'interfaccia del notebook. A partire da EMR nella versione 7.11 di EC2, questa funzionalità è disponibile tramite la funzionalità di propagazione delle identità affidabile di EMR-EC2. Le sezioni seguenti spiegano le opzioni e i comportamenti di configurazione per le sessioni utente in background.
**Nota**
Le impostazioni delle sessioni utente in background influiscono solo sui carichi di lavoro Spark avviati tramite SageMaker Unified Studio. Le modifiche a questa impostazione si applicano alle nuove sessioni di Livy: le sessioni attive esistenti rimangono inalterate.
## Configura le sessioni utente in background
Le sessioni utente in background devono essere abilitate a due livelli per una corretta funzionalità:
1. **Livello di istanza IAM Identity Center** (configurato dagli amministratori iDC)
1. **Livello di cluster EMR** (configurato dagli amministratori del cluster EMR)
### Abilita sessioni utente in background per Amazon EMR
Per abilitare le sessioni utente in background, è necessario impostare il `userBackgroundSessionsEnabled` parametro su `true` nella configurazione di sicurezza EMR `identityCenterConfiguration` durante la creazione.
**Prerequisiti:**
+ Il ruolo IAM utilizzato per creare o aggiornare la configurazione di sicurezza EMR richiede l'`sso:PutApplicationSessionConfiguration`autorizzazione. Questa autorizzazione abilita sessioni utente in background per l'applicazione IAM Identity Center gestita da Amazon EMR.
+ Crea un ruolo IAM per IAM Identity Center
+ Per integrare Amazon EMR con IAM Identity Center, crea un ruolo IAM che si autentichi con IAM Identity Center dal cluster EMR. Amazon EMR utilizza le credenziali SigV4 per inoltrare l'identità di IAM Identity Center a servizi downstream come. AWS Lake Formation Il tuo ruolo dovrebbe inoltre disporre delle autorizzazioni necessarie per richiamare i servizi downstream.
+ [Configura Lake Formation per un cluster EMR abilitato per IAM Identity Center](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html). Per le autorizzazioni di ruolo richieste, consulta: [Creare un ruolo IAM per Identity Center](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-start.html#emr-idc-start-role).
+ Avvia il tuo cluster EMR con la versione 7.11 o successiva e abilita Trusted-Identity Propagation.
**Fase 1 - Creare una configurazione di sicurezza EMR UserBackgroundSession abilitata per Identity Center**
Gli utenti devono impostare il `EnableUserBackgroundSession` **flag su`true`, che consentirà al** servizio EMR di attivarsi a livello di applicazione UserBackgourndSession IDC gestita da EMR. Se questo flag è impostato `false` o meno, EMR disabiliterà IDC UserBackgroundSession per impostazione predefinita.
**Esempio di utilizzo di: AWS CLI**
```
aws emr create-security-configuration --name "idc-userBackgroundSession-enabled-secConfig" \
--region AWS_REGION \
--security-configuration ' \
{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789",
"IdentityCenterApplicationAssigmentRequired": false,
"EnableUserBackgroundSession": true,
"IAMRoleForEMRIdentityCenterApplicationARN": "arn:aws:iam::12345678912:role/YOUR_ROLE"
}
},\
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},\
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},\
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
**Fase 2 - Creare e avviare un cluster abilitato per Identity Center**
Ora che hai configurato il ruolo IAM che esegue l'autenticazione con il Centro identità e hai creato una configurazione di sicurezza Amazon EMR con il Centro identità abilitato, puoi creare e avviare il tuo cluster con riconoscimento dell'identità. Per i passaggi per avviare il cluster con la configurazione di sicurezza richiesta, consulta Specificare una configurazione di sicurezza per un cluster Amazon EMR.
### Matrice di configurazione
Il comportamento della sessione utente in background dipende sia dall'impostazione EMR-EC2 che dalle impostazioni a livello di istanza di IAM Identity Center:
**Matrice di configurazione della sessione utente in background**
| IAM Identity Center userBackgroundSession abilitato | Abilitato per Amazon EMR userBackgroundSessions | Comportamento |
| --- | --- | --- |
| Sì | TRUE | Sessione utente in background abilitata |
| Sì | FALSE | La sessione scade con il logout dell'utente |
| No | TRUE | La sessione scade con il logout dell'utente |
| No | FALSE | La sessione scade con il logout dell'utente |
### Durata predefinita della sessione in background dell’utente
Per impostazione predefinita, tutte le sessioni utente in background hanno un limite di durata di 7 giorni in IAM Identity Center. Gli amministratori possono modificare questa durata nella console del Centro identità IAM. Questa impostazione si applica a livello di istanza IAM Identity Center e interessa tutte le applicazioni IAM Identity Center supportate all'interno di quell'istanza.
+ La durata può essere impostata su qualsiasi valore da 15 minuti a 90 giorni.
+ Questa impostazione è configurata nella console IAM Identity Center in **Impostazioni** → **Autenticazione** → **Configura** (vedi la sezione Lavori non interattivi)
### Impatto della disabilitazione delle sessioni utente in background
Quando le sessioni utente in background sono disabilitate in IAM Identity Center:
Sessioni Livy esistenti
+ Continuano a funzionare senza interruzioni se sono state avviate con le sessioni utente in background abilitate. Queste sessioni continueranno a utilizzare i token di sessione in background esistenti fino a quando non termineranno naturalmente o non verranno interrotte esplicitamente.
Nuove sessioni Livy
+ Utilizzerà il flusso di propagazione delle identità affidabili standard e terminerà quando l'utente si disconnette o scade la sessione interattiva (ad esempio quando chiude un notebook Amazon SageMaker Unified Studio). JupyterLab
### Modifica della durata delle sessioni in background degli utenti
Quando l'impostazione della durata per le sessioni utente in background viene modificata in IAM Identity Center:
Sessioni Livy esistenti
+ Continuate a funzionare con la stessa durata della sessione in background con cui sono state avviate.
Nuove sessioni Livy
+ Utilizzerà la nuova durata della sessione per le sessioni in background.
### Considerazioni
#### Disponibilità delle funzionalità
Le sessioni utente in background per Amazon EMR sono disponibili per:
+ Solo motore Spark (il motore Hive non è supportato)
+ Solo sessioni interattive Livy (i lavori in batch e i lavori in streaming non sono supportati)
+ Etichette di rilascio Amazon EMR 7.11 e successive. Con la release 7.11 di EMR, è necessario installare uno script di azione bootstrap per abilitare le sessioni utente in background durante la creazione di un cluster. Contatta l' AWS assistenza per ulteriori dettagli.
**Nota**
Se utilizzi il cluster provisioned di SageMaker Unified Studio, non è necessario lo script di azione bootstrap per utilizzare questa funzionalità.
#### Implicazioni sui costi
+ I lavori continueranno a essere eseguiti fino al completamento anche dopo che gli utenti avranno terminato la JupyterLab sessione di Amazon SageMaker Unified Studio e verranno addebitati costi per l'intera durata dell'esecuzione completata.
+ Monitora le sessioni attive in background per evitare costi inutili derivanti da sessioni dimenticate o abbandonate.
#### Condizioni di interruzione della sessione Livy
Quando si utilizzano sessioni utente in background, una sessione Livy continuerà a funzionare fino a quando non si verificherà una delle seguenti condizioni:
+ La sessione utente in background scade (in base alla configurazione iDC, fino a 90 giorni).
+ La sessione utente in background viene revocata manualmente da un amministratore.
+ La sessione Livy raggiunge il timeout di inattività (impostazione predefinita: 8 ore dopo l'ultima istruzione eseguita).
+ L'utente interrompe o riavvia esplicitamente il kernel del notebook.
# Considerazioni e limitazioni per Amazon EMR con l'integrazione del Centro identità
Considera i seguenti punti quando utilizzi il Centro identità IAM con Amazon EMR:
+ La propagazione affidabile delle identità tramite Identity Center è supportata su Amazon EMR 6.15.0 e versioni successive e solo con Apache Spark. Inoltre, la Trusted Identity Propagation tramite Identity Center utilizzando la funzionalità EMR Runtime Roles è supportata su Amazon EMR 7.8.0 e versioni successive e solo con Apache Spark.
+ Per abilitare i cluster EMR con propagazione di identità affidabile, è necessario utilizzare AWS CLI per creare una configurazione di sicurezza con propagazione delle identità affidabile abilitata e utilizzare tale configurazione di sicurezza all'avvio del cluster. Per ulteriori informazioni, consulta [Crea una configurazione di sicurezza abilitata per il Centro identità](emr-idc-start.md#emr-idc-start-securityconfig).
+ I controlli di accesso granulari AWS Lake Formation che utilizzano Trusted Identity Propagation sono disponibili per i cluster Amazon EMR nella versione 7.2.0 e successive di EMR. Tra le versioni EMR 6.15.0 e 7.1.0, è disponibile solo il controllo degli accessi a livello di tabella, basato su Lake Formation. AWS
+ Con i cluster Amazon EMR che utilizzano Trusted Identity Propagation, le operazioni che supportano il controllo degli accessi basato su Lake Formation con Apache Spark includono SELECT, ALTER TABLE, INSERT INTO e DROP TABLE.
+ I controlli di accesso granulari AWS Lake Formation che utilizzano Trusted Identity Propagation dovranno aggiornare la configurazione del Lake Formation Identity Center aggiungendo l'applicazione IAM Identity gestita da EMR arn come destinazione autorizzata. Puoi trovare l'ARN dell'applicazione IAM Identity gestita da Amazon EMR chiamando l'API EMR `describe-security-configure` e cercando il campo. `IdCApplicationARN` Maggiori dettagli: [Aggiornamento dell'integrazione di IAM Identity Center](https://docs.aws.amazon.com/lake-formation/latest/dg/update-lf-identity-center-connection.html) su come configurare Lake Formation con la configurazione di IAM Identity Center.
+ Per utilizzare controlli di accesso granulari AWS Lake Formation che utilizzano Trusted Identity Propagation, agli utenti di IAM Identity devono essere concesse le autorizzazioni Lake Formation sul database predefinito. Maggiori dettagli: [configura Lake Formation per un cluster EMR abilitato per IAM Identity Center](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html).
+ La propagazione affidabile delle identità con Amazon EMR è supportata nei seguenti paesi: Regioni AWS
+ `af-south-1`: Africa (Città del Capo)
+ `ap-east-1`: Asia Pacifico (Hong Kong)
+ `ap-northeast-1`: Asia Pacifico (Tokyo)
+ `ap-northeast-2`: Asia Pacifico (Seoul)
+ `ap-northeast-3`: Asia Pacifico (Osaka-Locale)
+ `ap-south-1`: Asia Pacifico (Mumbai)
+ `ap-south-2`— Asia Pacifico (Hyderabad)
+ `ap-southeast-1`: Asia Pacifico (Singapore)
+ `ap-southeast-2`: Asia Pacifico (Sydney)
+ `ap-southeast-3`: Asia Pacifico (Giacarta)
+ `ap-southeast-4`— Asia Pacifico (Melbourne)
+ `ca-central-1`: Canada (Centrale)
+ `eu-central-1`: Europa (Francoforte)
+ `eu-central-2` Europa (Zurigo)
+ `eu-north-1`: Europa (Stoccolma)
+ `eu-south-1`: Europa (Milano)
+ `eu-south-2`— Europa (Spagna)
+ `eu-west-1`: Europa (Irlanda)
+ `eu-west-2`: Europa (Londra)
+ `eu-west-3`: Europa (Parigi)
+ `il-central-1`— Israele (Tel Aviv)
+ `me-central-1`— Medio Oriente (Emirati Arabi Uniti)
+ `me-south-1`: Medio Oriente (Bahrein)
+ `sa-east-1`: Sud America (San Paolo)
+ `us-east-1`: Stati Uniti orientali (Virginia settentrionale)
+ `us-east-2`: Stati Uniti orientali (Ohio)
+ `us-west-1`: Stati Uniti occidentali (California settentrionale)
+ `us-west-2`: Stati Uniti occidentali (Oregon)
# Integra Amazon EMR con AWS Lake Formation
AWS Lake Formation è un servizio gestito che ti aiuta a scoprire, catalogare, pulire e proteggere i dati in un data lake Amazon Simple Storage Service (S3). Lake Formation fornisce un accesso granulare a livello di colonna, riga o cella a database e tabelle nel AWS Glue Data Catalog. Per maggiori informazioni, consulta [Che cos’è AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Con Amazon EMR versione 6.7.0 e successive, puoi applicare il controllo degli accessi basato su Lake Formation ai processi Spark, Hive e Presto inviati ai cluster Amazon EMR. Per l'integrazione con Lake Formation, devi creare un cluster EMR con un *ruolo di runtime*. Un ruolo di runtime è un ruolo AWS Identity and Access Management (IAM) che puoi associare ai processi o alle query di Amazon EMR. Amazon EMR utilizza quindi questo ruolo per accedere AWS alle risorse. Per ulteriori informazioni, consulta [Ruoli di runtime per le fasi di Amazon EMR](emr-steps-runtime-roles.md).
## Funzionamento di Amazon EMR con Lake Formation
[Dopo aver integrato Amazon EMR con Lake Formation, puoi eseguire query sui cluster Amazon EMR con l'`Step`API o con AI Studio.](https://docs.aws.amazon.com/emr/latest/APIReference/API_Step.html) SageMaker Quindi, Lake Formation fornisce l'accesso ai dati tramite credenziali temporanee per Amazon EMR. Questo processo è denominato distribuzione di credenziali. Per maggiori informazioni, consulta [Che cos’è AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Di seguito è riportata una panoramica generale sul modo in cui Amazon EMR ottiene l'accesso ai dati protetti dalle policy di sicurezza Lake Formation.
![\[In che modo Amazon EMR accede ai dati protetti dalle policy di sicurezza di Lake Formation\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/lf-emr-security.png)
1. Un utente invia una query Amazon EMR per i dati in Lake Formation.
1. Amazon EMR richiede le credenziali temporanee da Lake Formation per consentire all'utente di accedere ai dati.
1. Lake Formation restituisce le credenziali temporanee.
1. Amazon EMR invia la richiesta di query per recuperare dati da Amazon S3.
1. Amazon EMR riceve i dati da Amazon S3, li filtra e restituisce i risultati in base alle autorizzazioni utente definite in Lake Formation.
Per ulteriori informazioni sull'aggiunta di utenti e gruppi ai policy di Lake Formation, consulta [Concessione delle autorizzazioni Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
## Prerequisiti
Prima di integrare Amazon EMR e Lake Formation, è necessario soddisfare i seguenti requisiti:
+ Attiva l'autorizzazione dei ruoli di runtime sul cluster Amazon EMR.
+ Usa il AWS Glue Data Catalog come archivio di metadati.
+ Definisci e gestisci le autorizzazioni in Lake Formation per accedere a database, tabelle e colonne in AWS Glue Data Catalog. Per maggiori informazioni, consulta [Che cos’è AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
# Accesso a grana fine con Lake Formation
Le versioni 6.15.0 e successive di Amazon EMR includono il supporto per il controllo granulare degli accessi a livello di riga, colonna o cella basato su Lake Formation. AWS Gli argomenti di questa sezione spiegano come accedere alle tabelle del catalogo Glue Data protette da Lake Formation dai job EMR Spark o dalle sessioni interattive con controllo degli accessi granulare.
# Abilitazione di Amazon EMR con Lake Formation
Con Amazon EMR 6.15.0 e versioni successive, quando esegui job Spark su Amazon EMR su cluster EC2 che accedono ai dati nel AWS Glue Data Catalog, puoi AWS Lake Formation utilizzare per applicare autorizzazioni a livello di tabella, riga, colonna e cella su tabelle basate su Hudi, Iceberg o Delta Lake.
Questa sezione illustra come creare una configurazione di sicurezza e impostare Lake Formation per l'utilizzo con Amazon EMR. Descrive inoltre come avviare un cluster con la configurazione di sicurezza creata per Lake Formation.
## Passaggio 1: Impostazione di un ruolo di runtime per il cluster EMR
Per utilizzare un ruolo di runtime per il cluster EMR, devi prima creare una configurazione di sicurezza. Con una configurazione di sicurezza puoi applicare opzioni di sicurezza, autorizzazione e autenticazione coerenti in tutti i tuoi cluster.
1. Crea un file denominato `lf-runtime-roles-sec-cfg.json` con la seguente configurazione di sicurezza.
```
{
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},
"EncryptionConfiguration": {
"EnableAtRestEncryption": false,
"EnableInTransitEncryption": true,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {}
}
}
}
```
L'esempio seguente illustra come utilizzare un file zip con certificati in Amazon S3 per la configurazione dei certificati:
+ Un file zip con certificati in Amazon S3 viene utilizzato come fornitore di chiavi. (Vedi [Fornitura di certificati per la crittografia di dati in transito con Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) per i requisiti dei certificati).
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://MyConfigStore/artifacts/MyCerts.zip"
}
```
L'esempio seguente illustra come utilizzare un provider di chiavi personalizzate per la configurazione dei certificati:
+ Viene utilizzato un provider di chiavi personalizzato. (Vedi [Fornitura di certificati per la crittografia di dati in transito con Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) per i requisiti del certificato).
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "Custom",
"S3Object": "s3://MyConfig/artifacts/MyCerts.jar",
"CertificateProviderClass": "com.mycompany.MyCertProvider"
}
```
1. Quindi, per assicurarti che il tag di sessione possa autorizzare Lake Formation, imposta la proprietà `LakeFormationConfiguration/AuthorizedSessionTagValue` su `Amazon EMR`.
1. Utilizza il seguente comando per creare una configurazione di sicurezza Amazon EMR.
```
aws emr create-security-configuration \
--name 'iamconfig-with-iam-lf' \
--security-configuration file://lf-runtime-roles-sec-cfg.json
```
In alternativa, puoi utilizzare la [console Amazon EMR](https://console.aws.amazon.com//emr) per creare una configurazione di sicurezza con impostazioni personalizzate.
## Fase 2: avvio di un cluster Amazon EMR
Ora puoi avviare un cluster EMR con la configurazione di sicurezza creata nel passaggio precedente. Per ulteriori informazioni sulle configurazioni di sicurezza, consulta le sezioni [Usa le configurazioni di sicurezza per configurare la sicurezza dei cluster Amazon EMR](emr-security-configurations.md) e [Ruoli di runtime per le fasi di Amazon EMR](emr-steps-runtime-roles.md).
## Fase 3: configurare le autorizzazioni a livello di colonna, riga o cella basate su Lake Formation con i ruoli di runtime di Amazon EMR
Per applicare un controllo granulare degli accessi a livello di colonna, riga o cella con Lake Formation, l'amministratore del data lake per Lake Formation deve impostare `Amazon EMR` come valore per la configurazione del tag di sessione,. `AuthorizedSessionTagValue` Lake Formation utilizza questo tag di sessione per autorizzare i chiamanti e fornire l'accesso al data lake. Puoi impostare questo tag di sessione nella sezione **Impostazioni di integrazione dell'applicazione** della console Lake Formation. Sostituiscilo *123456789012* con il tuo Account AWS ID.
## Fase 4: Configurazione delle sovvenzioni AWS Glue and Lake Formation per i ruoli di runtime di Amazon EMR
Per continuare con la configurazione del controllo degli accessi basato su Lake Formation con i ruoli di runtime di Amazon EMR, devi configurare le sovvenzioni AWS Glue and Lake Formation per i ruoli di runtime di Amazon EMR. Per permettere ai ruoli di runtime IAM di interagire con Lake Formation, concedi loro l'accesso con `lakeformation:GetDataAccess` e `glue:Get*`.
Le autorizzazioni di Lake Formation controllano l'accesso alle risorse di AWS Glue Data Catalog, alle sedi Amazon S3 e ai dati sottostanti in tali sedi. Le autorizzazioni IAM controllano l'accesso a Lake Formation and AWS Glue APIs e alle risorse. Anche se disponi dell'autorizzazione di Lake Formation per accedere a una tabella nel catalogo dati (SELECT), l'operazione fallisce se non disponi dell'autorizzazione IAM per l'API `glue:Get*`. Per maggiori dettagli sul controllo degli accessi in Lake Formation, consulta la sezione [Lake Formation access control overview](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-overview.html) (Panoramica del controllo degli accessi a Lake Formation).
1. Crea il file `emr-runtime-roles-lake-formation-policy.json` con i seguenti contenuti.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LakeFormationManagedAccess",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"glue:Get*",
"glue:Create*",
"glue:Update*"
],
"Resource": [
"*"
]
}
]
}
```
------
1. Crea la policy IAM correlata.
```
aws iam create-policy \
--policy-name emr-runtime-roles-lake-formation-policy \
--policy-document file://emr-runtime-roles-lake-formation-policy.json
```
1. Per assegnare questa policy ai ruoli di runtime IAM, segui i passaggi in [Managing AWS Lake Formation permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html).
Ora puoi utilizzare i ruoli di runtime e Lake Formation per applicare le autorizzazioni a livello di tabella e colonna. Puoi anche utilizzare un'identità di origine per controllare le azioni e monitorare le operazioni con AWS CloudTrail.
Per ogni ruolo IAM che intendi utilizzare come ruolo di runtime, imposta la seguente policy di attendibilità, sostituendo `EMR_EC2_DefaultRole` con il ruolo del profilo dell'istanza. Per modificare la policy di attendibilità di un ruolo IAM, consulta [Modifica di una policy di attendibilità del ruolo](https://docs.aws.amazon.com//IAM/latest/UserGuide/roles-managingrole-editing-console.html).
```
{
"Sid":"AllowAssumeRole",
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam:::role/EMR_EC2_DefaultRole"
},
"Action":[
"sts:AssumeRole",
"sts:TagSession"
]
}
```
Per un end-to-end esempio dettagliato, consulta [Introducing runtime roles for Amazon EMR steps.](https://aws.amazon.com/blogs/big-data/introducing-runtime-roles-for-amazon-emr-steps-use-iam-roles-and-aws-lake-formation-for-access-control-with-amazon-emr/)
Per informazioni su come integrare Iceberg e AWS Glue Data Catalog per una gerarchia multicatalogo, vedi [Configurare Spark per accedere a una gerarchia multicatalogo in Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html#emr-lakehouse-using-spark-access). AWS
# Supporto per il formato a tabella aperta
Le versioni 6.15.0 e successive di Amazon EMR includono il supporto per il controllo granulare degli accessi basato su tabelle Hive, Apache Iceberg, Apache Hudi e Delta Lake durante la lettura e la scrittura di dati AWS Lake Formation con Spark SQL. Amazon EMR supporta il controllo degli accessi a livello di tabella, riga, colonna e cella con Apache Hudi. Le versioni 6.15.0 e successive di Amazon EMR includono il supporto per il controllo granulare degli accessi a livello di riga, colonna o cella basato su Lake Formation. AWS A partire da EMR 7.12, le operazioni DML e DDL che modificano i dati delle tabelle sono supportate per le tabelle Apache Hive, Apache Iceberg e Delta Lake utilizzando le credenziali vendute di Lake Formation.
Gli argomenti di questa sezione spiegano come accedere alle tabelle registrate di Lake Formation in formati di tabelle aperte dai job EMR Spark o dalle sessioni interattive con controllo degli accessi granulare.
## Requisiti per l'autorizzazione
### Tabelle non registrate in AWS Lake Formation
Per le tabelle non registrate con AWS Lake Formation, il ruolo di job runtime accede sia al AWS Glue Data Catalog che ai dati della tabella sottostante in Amazon S3. Ciò richiede che il ruolo di job runtime disponga delle autorizzazioni IAM appropriate per le operazioni di AWS Glue e Amazon S3.
### Tabelle registrate in AWS Lake Formation
Per le tabelle registrate con AWS Lake Formation, il ruolo di job runtime accede ai metadati di AWS Glue Data Catalog, mentre le credenziali temporanee fornite da Lake Formation accedono ai dati della tabella sottostante in Amazon S3. Le autorizzazioni Lake Formation necessarie per eseguire un'operazione dipendono dalle chiamate API di AWS Glue Data Catalog e Amazon S3 avviate dal job Spark e possono essere riassunte come segue:
+ L'autorizzazione **DESCRIBE** consente al ruolo di runtime di leggere i metadati della tabella o del database nel Data Catalog
+ L'autorizzazione **ALTER** consente al ruolo di runtime di modificare i metadati di tabelle o database nel Data Catalog
+ L'autorizzazione **DROP** consente al ruolo di runtime di eliminare i metadati di tabelle o database dal Data Catalog
+ L'autorizzazione **SELECT** consente al ruolo di runtime di leggere i dati della tabella da Amazon S3
+ L'autorizzazione **INSERT** consente al ruolo di runtime di scrivere dati di tabella su Amazon S3
+ L'autorizzazione **DELETE** consente al ruolo di runtime di eliminare i dati della tabella da Amazon S3
**Nota**
Lake Formation valuta le autorizzazioni pigramente quando un job Spark chiama AWS Glue per recuperare i metadati della tabella e Amazon S3 per recuperare i dati della tabella. I lavori che utilizzano un ruolo di runtime con autorizzazioni insufficienti non falliranno finché Spark non effettuerà una chiamata AWS Glue o Amazon S3 che richiede l'autorizzazione mancante.
**Nota**
Nella seguente matrice di tabelle supportata:
Le operazioni **contrassegnate come Supported** utilizzano esclusivamente le credenziali di Lake Formation per accedere ai dati delle tabelle per le tabelle registrate con Lake Formation. Se le autorizzazioni di Lake Formation sono insufficienti, l'operazione non ricorrerà alle credenziali del ruolo di runtime. Per le tabelle non registrate con Lake Formation, le credenziali del ruolo di job runtime accedono ai dati della tabella.
Le operazioni **contrassegnate come Supportate con autorizzazioni IAM sulla posizione Amazon S3** non utilizzano le credenziali di Lake Formation per accedere ai dati delle tabelle sottostanti in Amazon S3. Per eseguire queste operazioni, il ruolo di job runtime deve disporre delle autorizzazioni IAM di Amazon S3 necessarie per accedere ai dati della tabella, indipendentemente dal fatto che la tabella sia registrata con Lake Formation.
------
#### [ Hive ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-lf-fgac1.html)
------
#### [ Iceberg ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configurazione Spark per Iceberg:** Se desideri utilizzare il formato Iceberg, imposta le seguenti configurazioni. Sostituisci `DB_LOCATION` con il percorso Amazon S3 in cui si trovano le tabelle Iceberg e sostituisci i segnaposto per regione e ID account con i tuoi valori.
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.region=AWS_REGION
```
Se desideri utilizzare il formato Iceberg nelle versioni precedenti di EMR, usa invece il seguente comando:
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.assume-role.region=AWS_REGION
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Esempi:**
Ecco alcuni esempi di utilizzo delle tabelle Iceberg:
```
-- Create an Iceberg table
CREATE TABLE my_iceberg_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING ICEBERG;
-- Insert data
INSERT INTO my_iceberg_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_iceberg_table;
```
------
#### [ Hudi ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configurazione Spark per Hudi:**
Per avviare la shell Spark su EMR 7.10 o versioni successive, usa il seguente comando:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
```
Per avviare la shell Spark su versioni EMR precedenti, usa invece il comando seguente:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Esempi:**
Ecco alcuni esempi di utilizzo delle tabelle Hudi:
```
-- Create a Hudi table
CREATE TABLE my_hudi_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING HUDI
TBLPROPERTIES (
'type' = 'cow',
'primaryKey' = 'id'
);
-- Insert data
INSERT INTO my_hudi_table VALUES (1, 'Alice', current_timestamp());
-- Query the latest snapshot
SELECT * FROM my_hudi_table;
```
Per interrogare l'ultima istantanea delle copy-on-write tabelle:
```
SELECT * FROM my_hudi_cow_table
```
```
spark.read.table("my_hudi_cow_table")
```
Per eseguire query sui dati compatti più recenti delle tabelle `MOR`, puoi eseguire query sulla tabella ottimizzata per la lettura che presenta il suffisso con `_ro`:
```
SELECT * FROM my_hudi_mor_table_ro
```
```
spark.read.table("my_hudi_mor_table_ro")
```
------
#### [ Delta Lake ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configurazione Spark per Delta Lake:**
Per usare Delta Lake with Lake Formation su EMR 7.10 e versioni successive, esegui il seguente comando:
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog
```
Per utilizzare Delta Lake with Lake Formation su EMR da 6.15 a 7.9, esegui quanto segue
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
Se desideri che Lake Formation utilizzi il server di registrazione per gestire il tuo catalogo Spark, imposta su `spark.sql.catalog..lf.managed` true.
**Esempi:**
Ecco alcuni esempi di utilizzo delle tabelle Delta Lake:
```
-- Create a Delta Lake table
CREATE TABLE my_delta_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING DELTA;
-- Insert data
INSERT INTO my_delta_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_delta_table;
-- Update data
UPDATE my_delta_table SET name = 'Alice Smith' WHERE id = 1;
-- Merge data
MERGE INTO my_delta_table AS target
USING (SELECT 2 as id, 'Bob' as name, current_timestamp() as created_at) AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
```
**Creazione di una tabella Delta Lake in AWS Glue Data Catalog**
Amazon EMR with Lake Formation non supporta i comandi DDL e la creazione di tabelle Delta nelle versioni EMR precedenti alla 7.12. Segui questi passaggi per creare tabelle nel AWS Glue Data Catalog.
1. Usa l'esempio seguente per creare una tabella Delta. Assicurati che la tua posizione S3 esista.
```
spark-sql \
--conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \
--conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"
> CREATE DATABASE if not exists LOCATION 's3:///transactionaldata/native-delta//';
> CREATE TABLE (x INT, y STRING, z STRING) USING delta;
> INSERT INTO VALUES (1, 'a1', 'b1');
```
1. Per vedere i dettagli della tua tabella, vai a [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Nella barra di navigazione a sinistra, espandi **Data Catalog**, scegli **Tabelle**, quindi scegli la tabella che hai creato. In **Schema**, dovresti vedere che la tabella Delta che hai creato con Spark memorizza tutte le colonne in un tipo di dati di `array` AWS Glue.
1. Per definire filtri a livello di colonna e cella in Lake Formation, rimuovi la `col` colonna dallo schema, quindi aggiungi le colonne presenti nello schema della tabella. In questo esempio, aggiungi le colonne `x``y`, e. `z`
------
Con questa funzionalità, è possibile eseguire query istantanee sulle copy-on-write tabelle per interrogare l'istantanea più recente della tabella in un determinato commit o istante di compattazione. Attualmente, un cluster Amazon EMR abilitato a Lake Formation deve recuperare la colonna del tempo di commit di Hudi per eseguire query incrementali e query sui viaggi nel tempo. Non supporta la sintassi e la funzione di Spark. `timestamp as of` `Spark.read()` La sintassi corretta è. `select * from table where _hoodie_commit_time <= point_in_time` Per ulteriori informazioni, vedere [Query Point in time Time-Travel sulla](https://cwiki.apache.org/confluence/display/HUDI/RFC+-+07+%3A+Point+in+time+Time-Travel+queries+on+Hudi+table) tabella Hudi.
**Nota**
Le prestazioni delle letture possono essere più lente nei cluster Lake Formation a causa di ottimizzazioni non supportate. Queste funzioni includono l'elenco dei file basato sui metadati Hudi e i dati ignorati. È preferibile testare le prestazioni dell'applicazione per accertarsi che soddisfi i requisiti.
# Utilizzo delle viste del catalogo dati di Glue in Amazon EMR
**Nota**
La creazione e AWS la gestione delle viste di Glue Data Catalog da utilizzare con EMR su EC2 è disponibile con Amazon [EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-7100-release.html) release 7.10.0 e successive.
Puoi creare e gestire viste nel AWS Glue Data Catalog da utilizzare con EMR su EC2. Queste sono note comunemente come viste del AWS Glue Data Catalog. Queste viste sono utili perché supportano più motori di query SQL, quindi puoi accedere alla stessa vista su AWS servizi diversi, come EMR su EC2 e Amazon Amazon Athena Redshift.
Creando una vista nel Data Catalog, puoi utilizzare le concessioni di risorse e i controlli di accesso basati su tag per concedere l'accesso AWS Lake Formation ad essa. Utilizzando questo metodo di controllo degli accessi, non è necessario configurare un accesso aggiuntivo alle tabelle a cui hai fatto riferimento durante la creazione della vista. Questo metodo di concessione delle autorizzazioni è chiamato semantica, mentre queste viste sono chiamate viste del definitore. Per ulteriori informazioni sul controllo degli accessi in Lake Formation, consulta [Concessione e revoca delle autorizzazioni sulle risorse del Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html) nella AWS Lake Formation Developer Guide.
Le viste del Catalogo dati sono utili per i seguenti casi d'uso:
+ **Controllo granulare degli accessi**: è possibile creare una vista che limiti l'accesso ai dati in base alle autorizzazioni necessarie per l'utente. Ad esempio, puoi utilizzare le viste nel Catalogo dati per impedire ai dipendenti che non lavorano nel reparto delle risorse umane di visualizzare le informazioni di identificazione personale (PII).
+ **Definizione completa della vista**: applicando filtri alla visualizzazione nel Data Catalog, ti assicuri che i record di dati disponibili in una visualizzazione del Data Catalog siano sempre completi.
+ **Sicurezza avanzata**: la definizione della query utilizzata per creare la vista deve essere completa. Questo vantaggio significa che le visualizzazioni del Data Catalog sono meno suscettibili ai comandi SQL di attori malintenzionati.
+ **Condivisione semplice dei dati**: condividi i dati con altri AWS account senza spostare i dati. Per ulteriori informazioni, consulta [Condivisione dei dati tra account in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html).
## Creazione di una vista di Catalogo Dati
Esistono diversi modi per creare una visualizzazione del catalogo dati. Questi includono l'utilizzo di AWS CLI o Spark SQL. Seguono alcuni esempi.
------
#### [ Using SQL ]
Di seguito viene illustrata la sintassi per la creazione di una vista del catalogo dati. Nota il tipo di `MULTI DIALECT` visualizzazione. Ciò distingue la vista del catalogo dati dalle altre viste. Il `SECURITY` predicato è specificato come. `DEFINER` Ciò indica una vista del catalogo dati con `DEFINER` semantica.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW [IF NOT EXISTS] view_name
[(column_name [COMMENT column_comment], ...) ]
[ COMMENT view_comment ]
[TBLPROPERTIES (property_name = property_value, ... )]
SECURITY DEFINER
AS query;
```
Di seguito è riportato un esempio di `CREATE` dichiarazione, che segue la sintassi:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY order_date
```
È inoltre possibile creare una vista in modalità dry-run, utilizzando SQL, per testare la creazione della vista, senza creare effettivamente la risorsa. L'utilizzo di questa opzione comporta una «esecuzione a secco» che convalida l'input e, se la convalida ha esito positivo, restituisce il JSON dell'oggetto della tabella AWS Glue che rappresenterà la vista. In questo caso, la visualizzazione effettiva non viene creata.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW view_name
SECURITY DEFINER
[ SHOW VIEW JSON ]
AS view-sql
```
------
#### [ Using the AWS CLI ]
**Nota**
Quando si utilizza il comando CLI, l'SQL utilizzato per creare la vista non viene analizzato. Ciò può causare un caso in cui la vista viene creata, ma le query non hanno esito positivo. Assicurati di testare la sintassi SQL prima di creare la vista.
Utilizzate il seguente comando CLI per creare una vista:
```
aws glue create-table --cli-input-json '{
"DatabaseName": "database",
"TableInput": {
"Name": "view",
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "data-type"
},
...
{
"Name": "col_n",
"Type": "data-type"
}
],
"SerdeInfo": {}
},
"ViewDefinition": {
"SubObjects": [
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-table1",
...
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-tableN",
],
"IsProtected": true,
"Representations": [
{
"Dialect": "SPARK",
"DialectVersion": "1.0",
"ViewOriginalText": "Spark-SQL",
"ViewExpandedText": "Spark-SQL"
}
]
}
}
}'
```
------
## Operazioni supportate per le viste
I seguenti frammenti di comandi mostrano vari modi di lavorare con le viste nel Catalogo dati:
+ **CREA VISTA**
Crea una vista data-catalog. Di seguito è riportato un esempio che mostra la creazione di una vista da una tabella esistente:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER AS SELECT * FROM my_catalog.my_database.source_table
```
+ **ALTER VIEW**
Sintassi disponibile:
+ `ALTER VIEW view_name [FORCE] ADD DIALECT AS query`
+ `ALTER VIEW view_name [FORCE] UPDATE DIALECT AS query`
+ `ALTER VIEW view_name DROP DIALECT`
È possibile utilizzare l'opzione `FORCE ADD DIALECT` per forzare l'aggiornamento dello schema e degli oggetti secondari secondo il nuovo dialetto del motore. Tieni presente che questa operazione può causare errori di query se non utilizzi anche `FORCE` per aggiornare altri dialetti del motore. Di seguito è riportato un esempio:
```
ALTER VIEW catalog_view FORCE ADD DIALECT
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY orderdate;
```
Quello che segue è un esempio di come modificare una vista per aggiornare il dialetto:
```
ALTER VIEW catalog_view UPDATE DIALECT AS
SELECT count(*) FROM my_catalog.my_database.source_table;
```
+ **DESCRIVI LA VISTA**
Sintassi disponibile per descrivere una vista:
+ `SHOW COLUMNS {FROM|IN} view_name [{FROM|IN} database_name]`— Se l'utente dispone delle autorizzazioni AWS Glue and Lake Formation necessarie per descrivere la vista, può elencare le colonne. Di seguito sono riportati un paio di comandi di esempio per la vista delle colonne:
```
SHOW COLUMNS FROM my_database.source_table;
SHOW COLUMNS IN my_database.source_table;
```
+ `DESCRIBE view_name`— Se l'utente dispone delle autorizzazioni AWS Glue and Lake Formation necessarie per descrivere la vista, può elencare le colonne della vista insieme ai relativi metadati.
+ **ELIMINA VISTA**
Sintassi disponibile:
+ `DROP VIEW [ IF EXISTS ] view_name`
L'esempio seguente mostra un'istruzione `DROP` che verifica l'esistenza di una vista prima di eliminarla:
```
DROP VIEW IF EXISTS catalog_view;
```
+ **MOSTRA CREA VISUALIZZAZIONE**
+ `SHOW CREATE VIEW view_name`: mostra l'istruzione SQL che crea la vista specificata. Di seguito è riportato un esempio che mostra la creazione di una vista data-catalog:
```
SHOW CREATE TABLE my_database.catalog_view;
CREATE PROTECTED MULTI DIALECT VIEW my_catalog.my_database.catalog_view (
net_profit,
customer_id,
item_id,
sold_date)
TBLPROPERTIES (
'transient_lastDdlTime' = '1736267222')
SECURITY DEFINER AS SELECT * FROM
my_database.store_sales_partitioned_lf WHERE customer_id IN (SELECT customer_id from source_table limit 10)
```
+ **MOSTRA VISUALIZZAZIONI**
Elenca tutte le viste del catalogo, ad esempio viste regolari, visualizzazioni multidialettali (MDV) e MDV senza dialetto Spark. La sintassi disponibile è la seguente:
+ `SHOW VIEWS [{ FROM | IN } database_name] [LIKE regex_pattern]`:
Il seguente è un comando di esempio per mostrare le viste:
```
SHOW VIEWS IN marketing_analytics LIKE 'catalog_view*';
```
Per ulteriori informazioni sulla creazione e la configurazione delle viste del catalogo dati, consulta Building [AWS Glue Data Catalog views](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html) nella Developer Guide. AWS Lake Formation
## Interrogazione di una vista di Catalogo Dati
Dopo aver creato una vista del catalogo dati, puoi interrogarla utilizzando un job Amazon EMR Spark con controllo granulare degli accessi AWS Lake Formation abilitato. Il ruolo di job runtime deve disporre dell'`SELECT`autorizzazione Lake Formation per la visualizzazione Data Catalog. Non è necessario concedere l'accesso alle tabelle sottostanti a cui si fa riferimento nella vista.
Dopo aver impostato tutto, è possibile eseguire query sulla vista. Ad esempio, dopo aver creato un'applicazione Amazon EMR in EMR Studio, puoi eseguire la seguente query per accedere a una vista.
```
SELECT * from my_database.catalog_view LIMIT 10;
```
Una funzione utile è la. `invoker_principal` Restituisce l'identificatore univoco del ruolo EMRS Job Runtime. Questo può essere usato per controllare l'output della vista, in base al principio di invocazione. Puoi usarlo per aggiungere una condizione nella tua vista che perfeziona i risultati della query, in base al ruolo chiamante. Il ruolo di job runtime deve disporre dell'autorizzazione all'azione `LakeFormation:GetDataLakePrincipal` IAM per utilizzare questa funzione.
```
select invoker_principal();
```
È possibile aggiungere questa funzione a una `WHERE` clausola, ad esempio, per perfezionare i risultati delle query.
## Considerazioni e limitazioni
Quando si creano viste del catalogo dati, si applica quanto segue:
+ Puoi creare viste del catalogo dati solo con Amazon EMR 7.10 e versioni successive.
+ Il definitore della vista di Catalogo dati deve avere l'accesso `SELECT` alle tabelle di base sottostanti a cui la vista accede. La creazione della vista di Catalogo dati non riesce se una tabella base specifica ha dei filtri Lake Formation imposti sul ruolo del definitore.
+ Le tabelle di base non devono avere l'autorizzazione del `IAMAllowedPrincipals` data lake in Lake Formation. Se presente, si verifica l'errore *Multi Dialect views può fare riferimento solo a tabelle senza le autorizzazioni IAMAllowed Principal.*
+ La posizione Amazon S3 della tabella deve essere registrata come posizione del data lake. Se la tabella non è registrata, si verifica l'errore Le *viste multidialettali possono fare riferimento solo alle tabelle gestite da Lake Formation*. Per informazioni su come registrare le sedi Amazon S3 in Lake Formation, consulta [Registrazione di una sede Amazon S3](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html) nella Developer Guide. AWS Lake Formation
+ Puoi creare solo viste `PROTECTED` in Catalogo dati. Le viste `UNPROTECTED` non sono supportate.
+ Non puoi fare riferimento alle tabelle di un altro AWS account in una definizione di visualizzazione del catalogo dati. Inoltre, non puoi fare riferimento a una tabella nello stesso account che si trova in una Regione separata.
+ Per condividere i dati tra un account o un'area geografica, l'intera visualizzazione deve essere condivisa tra account e regioni, utilizzando i link alle risorse di Lake Formation.
+ Le funzioni definite dall'utente (UDFs) non sono supportate.
+ È possibile utilizzare viste basate sulle tabelle Iceberg. Sono supportati anche i formati a tabella aperta Apache Hudi e Delta Lake.
+ Le viste di Catalogo Dati non possono fare riferimento ad altre viste.
+ Lo schema di visualizzazione di AWS Glue Data Catalog viene sempre memorizzato in lettere minuscole. Ad esempio, se si utilizza un'istruzione DDL per creare una vista del Glue Data Catalog con una colonna denominata`Castle`, la colonna creata nel Glue Data Catalog verrà composta in minuscolo, to. `castle` Se poi si specifica il nome della colonna in una query DML come `Castle` o`CASTLE`, EMR Spark renderà il nome in minuscolo per eseguire la query. Tuttavia, l'intestazione della colonna viene visualizzata utilizzando il maiuscolo specificato nella query.
Se si desidera che una query abbia esito negativo nel caso in cui il nome di colonna specificato nella query DML non corrisponda al nome della colonna nel Glue Data Catalog, è possibile impostare`spark.sql.caseSensitive=true`.
# Considerazioni su Amazon EMR con Lake Formation
Amazon EMR with Lake Formation è disponibile in tutte le regioni [disponibili](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-region.html).
## Considerazioni per Amazon EMR with Lake Formation per la versione 7.9 e precedenti
Considerare quanto segue quando AWS Lake Formation si utilizza EMR 7.9 e versioni precedenti.
+ Il [controllo granulare degli accessi](emr-lf-enable.md#emr-lf-fgac-perms) è disponibile sui cluster con Amazon EMR versioni 6.15 e successive.
+ Gli utenti con accesso a una tabella possono accedere a tutte le sue proprietà. Se disponi di un controllo degli accessi basato su Lake Formation su una tabella, controlla la tabella per assicurarti che le proprietà non contengano dati o informazioni sensibili.
+ I cluster Amazon EMR con Lake Formation non supportano il fallback di Spark su HDFS quando Spark raccoglie le statistiche delle tabelle. Questo di solito aiuta a ottimizzare le prestazioni delle query.
+ Le operazioni che supportano i controlli degli accessi basati su Lake Formation con tabelle Apache Spark non gestite includono `INSERT INTO` e `INSERT OVERWRITE`.
+ Le operazioni che supportano i controlli degli accessi basati su Lake Formation con Apache Spark e Apache Hive includono `SELECT`, `DESCRIBE`, `SHOW DATABASE`, `SHOW TABLE`, `SHOW COLUMN` e `SHOW PARTITION`.
+ Amazon EMR non supporta l'accesso alle seguenti operazioni basate su Lake Formation:
+ Scrive su tabelle regolate
+ Amazon EMR non supporta `CREATE TABLE`. Amazon EMR versione 6.10.0 e successive supporta `ALTER TABLE`.
+ Istruzioni DML diverse dai comandi `INSERT`.
+ Esistono differenze di prestazioni tra la stessa query con e senza il controllo degli accessi basato su Lake Formation.
+ Puoi usare Amazon EMR solo con Lake Formation per i lavori Spark.
+ La propagazione delle identità affidabili non è supportata con la gerarchia multicatalogo in Glue Data Catalog. Per ulteriori informazioni, consulta [Lavorare con una gerarchia multicatalogo in AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Considerazioni per Amazon EMR with Lake Formation per la versione 7.10 e successive
Considera quanto segue quando utilizzi Amazon EMR con AWS Lake Formation EMR 7.10 e versioni successive.
+ Amazon EMR supporta il controllo granulare degli accessi tramite Lake Formation solo per le tabelle Apache Hive, Apache Iceberg, Apache Delta e Apache Hudi. I formati Apache Hive includono Parquet, ORC e xSv CSV.
+ Per le applicazioni abilitate per Lake Formation, i log Spark vengono scritti su Amazon S3 in due gruppi: log dello spazio di sistema e log dello spazio utente. I log dello spazio di sistema possono contenere informazioni riservate come lo schema completo della tabella. Per proteggere questi dati, Amazon EMR archivia i log dello spazio di sistema in una posizione separata dai log dello spazio utente. Si consiglia vivamente agli amministratori degli account di non concedere agli utenti l'accesso ai registri dello spazio di sistema.
+ Se registri una posizione in una tabella con Lake Formation, l'accesso ai dati sarà controllato esclusivamente dalle autorizzazioni del ruolo utilizzato per la registrazione, anziché dal ruolo Job Runtime di Amazon EMR. Se il ruolo di registrazione non è configurato correttamente, i lavori che tentano di accedere alla tabella avranno esito negativo.
+ Non puoi smettere di lavorare `DynamicResourceAllocation` per Lake Formation.
+ Si può usare Lake Formation solo con i processi Spark.
+ Amazon EMR with Lake Formation supporta solo una singola sessione Spark durante un processo.
+ Amazon EMR with Lake Formation supporta solo query tabellari tra account condivise tramite link a risorse.
+ I seguenti elementi non sono supportati:
+ Resilient Distributed Dataset (RDD)
+ Streaming di Spark
+ Scrivere con le autorizzazioni concesse da Lake Formation
+ Controllo degli accessi per colonne annidate
+ Amazon EMR blocca funzionalità che potrebbero compromettere il completo isolamento dei driver di sistema, tra cui:
+ UDTs, Hive UDFs e qualsiasi funzione definita dall'utente che includa classi personalizzate
+ Origini dati personalizzate
+ Fornitura di jar aggiuntivi per l'estensione, il connettore o il metastore di Spark
+ Comando `ANALYZE TABLE`
+ Per applicare i controlli di accesso, `EXPLAIN PLAN` e le operazioni DDL, come `DESCRIBE TABLE` non espongono informazioni riservate.
+ Amazon EMR limita l'accesso ai log Spark dei driver di sistema sulle applicazioni abilitate per Lake Formation. Poiché il driver di sistema viene eseguito con autorizzazioni elevate, gli eventi e i log generati dal driver di sistema possono includere informazioni riservate. Per impedire a utenti o codici non autorizzati di accedere a questi dati sensibili, Amazon EMR disabilita l'accesso ai registri dei driver di sistema.
I log dei profili di sistema vengono sempre conservati nello storage gestito: si tratta di un'impostazione obbligatoria che non può essere disabilitata. Questi registri vengono archiviati in modo sicuro e crittografati utilizzando una chiave KMS gestita dal cliente o una chiave KMS gestita. AWS
[Se la tua applicazione Amazon EMR si trova in una sottorete privata con endpoint VPC per Amazon S3 e alleghi una policy di endpoint per controllare l'accesso, prima che i tuoi lavori possano inviare dati di log a Managed AWS Amazon S3, devi includere le autorizzazioni dettagliate in Managed Storage nella tua policy VPC all'endpoint gateway S3.](logging.html#jobs-log-storage-managed-storage) Per la risoluzione dei problemi relativi alle richieste, contatta l'assistenza. AWS
+ Se hai registrato una posizione in una tabella con Lake Formation, il percorso di accesso ai dati passa attraverso le credenziali archiviate di Lake Formation indipendentemente dall'autorizzazione IAM per il ruolo di job runtime di Amazon EMR. Se si configura erroneamente il ruolo registrato con la posizione della tabella, i processi inviati che utilizzano il ruolo con l'autorizzazione S3 IAM per la posizione della tabella avranno esito negativo.
+ La scrittura su una tabella Lake Formation utilizza l'autorizzazione IAM anziché le autorizzazioni concesse da Lake Formation. Se il ruolo di runtime del processo dispone delle autorizzazioni S3 necessarie, è possibile utilizzarlo per eseguire operazioni di scrittura.
Di seguito sono riportate considerazioni e limitazioni per l'utilizzo di Apache Iceberg:
+ È possibile utilizzare Apache Iceberg solo con il catalogo delle sessioni e non con i cataloghi con nomi arbitrari.
+ Le tabelle Iceberg registrate in Lake Formation supportano solo le tabelle di metadati`history`,`metadata_log_entries`,, `snapshots` `files``manifests`, e. `refs` Amazon EMR nasconde le colonne che potrebbero contenere dati sensibili, ad esempio`partitions`, `path` e. `summaries` Questa limitazione non si applica alle tabelle Iceberg che non sono registrate in Lake Formation.
+ Le tabelle non registrate in Lake Formation supportano tutte le stored procedure di Iceberg. Le procedure di `register_table` e `migrate` non sono supportate per nessuna tabella.
+ Ti consigliamo di utilizzare Iceberg DataFrameWriter V2 anziché V1.
## Considerazioni per Amazon EMR with Lake Formation per la versione 7.12 e successive
### Ambito generale
Esamina le seguenti limitazioni quando usi Lake Formation con Amazon EMR.
+ Non puoi smettere di lavorare `DynamicResourceAllocation` per Lake Formation.
+ Si può usare Lake Formation solo con i processi Spark.
+ Amazon EMR with Lake Formation supporta solo una singola sessione Spark durante un processo.
+ Amazon EMR with Lake Formation supporta solo query tabellari tra account condivise tramite link a risorse.
+ I seguenti elementi non sono supportati:
+ Resilient Distributed Dataset (RDD)
+ Streaming di Spark
+ Controllo degli accessi per colonne annidate
+ Amazon EMR blocca funzionalità che potrebbero compromettere il completo isolamento dei driver di sistema, tra cui:
+ UDTs, Hive UDFs e qualsiasi funzione definita dall'utente che includa classi personalizzate
+ Origini dati personalizzate
+ Fornitura di jar aggiuntivi per l'estensione, il connettore o il metastore di Spark
+ Comando `ANALYZE TABLE`
+ [Se la tua applicazione Amazon EMR si trova in una sottorete privata con endpoint VPC per Amazon S3 e alleghi una policy di endpoint per controllare l'accesso, prima che i tuoi lavori possano inviare dati di log a Managed AWS Amazon S3, devi includere le autorizzazioni dettagliate in Managed Storage nella tua policy VPC all'endpoint gateway S3.](logging.html#jobs-log-storage-managed-storage) Per la risoluzione dei problemi relativi alle richieste, contatta l'assistenza. AWS
+ A partire da Amazon EMR 7.9.0, Spark FGAC supporta il AFile sistema S3 se utilizzato con lo schema s3a://.
+ Amazon EMR 7.11 supporta la creazione di tabelle gestite tramite CTAS.
+ Amazon EMR 7.12 supporta la creazione di tabelle gestite ed esterne utilizzando CTAS.
## Permissions
+ Per applicare i controlli di accesso, le operazioni EXPLAIN PLAN e DDL come DESCRIBE TABLE non espongono informazioni riservate.
+ Quando registri una posizione in una tabella con Lake Formation, l'accesso ai dati utilizza le credenziali archiviate di Lake Formation anziché le autorizzazioni IAM del ruolo di job runtime EMR Serverless. I processi falliranno se il ruolo registrato per la posizione della tabella è configurato in modo errato, anche se il ruolo di runtime dispone delle autorizzazioni S3 IAM per quella posizione.
+ A partire da Amazon EMR 7.12, puoi scrivere su tabelle Hive e Iceberg esistenti utilizzando DataFrameWriter (V2) con credenziali Lake Formation in modalità di aggiunta. Per le operazioni di sovrascrittura o durante la creazione di nuove tabelle, EMR utilizza le credenziali del ruolo di runtime per modificare i dati della tabella.
+ Le seguenti limitazioni si applicano quando si utilizzano viste o tabelle memorizzate nella cache come dati di origine (queste limitazioni non si applicano alle viste del AWS Glue Data Catalog):
+ Per le operazioni MERGE, DELETE e UPDATE
+ Supportato: utilizzo di viste e tabelle memorizzate nella cache come tabelle di origine.
+ Non supportato: utilizzo di viste e tabelle memorizzate nella cache nelle clausole di assegnazione e condizione.
+ Per le operazioni CREATE OR REPLACE e REPLACE TABLE AS SELECT:
+ Non supportata: utilizzo di viste e tabelle memorizzate nella cache come tabelle di origine.
+ Le tabelle Delta Lake con UDFs dati di origine supportano le operazioni MERGE, DELETE e UPDATE solo quando il vettore di eliminazione è abilitato.
## Registri e debug
+ Amazon EMR limita l'accesso ai log Spark dei driver di sistema sulle applicazioni abilitate per Lake Formation. Poiché il driver di sistema funziona con autorizzazioni elevate, gli eventi e i log generati dal driver di sistema possono includere informazioni sensibili. Per impedire a utenti o codici non autorizzati di accedere a questi dati sensibili, Amazon EMR disabilita l'accesso ai registri dei driver di sistema.
I log dei profili di sistema vengono sempre conservati nello storage gestito: si tratta di un'impostazione obbligatoria che non può essere disabilitata. Questi registri vengono archiviati in modo sicuro e crittografati utilizzando una chiave KMS gestita dal cliente o una chiave KMS gestita. AWS
## Iceberg
Leggi le seguenti considerazioni quando usi Apache Iceberg:
+ È possibile utilizzare Apache Iceberg solo con il catalogo delle sessioni e non con i cataloghi con nomi arbitrari.
+ Le tabelle Iceberg registrate in Lake Formation supportano solo le tabelle di metadati`history`,`metadata_log_entries`,, `snapshots` `files``manifests`, e. `refs` Amazon EMR nasconde le colonne che potrebbero contenere dati sensibili, ad esempio`partitions`, `path` e. `summaries` Questa limitazione non si applica alle tabelle Iceberg che non sono registrate in Lake Formation.
+ Le tabelle non registrate in Lake Formation supportano tutte le stored procedure Iceberg. Le procedure di `register_table` e `migrate` non sono supportate per nessuna tabella.
+ Ti suggeriamo di utilizzare Iceberg DataFrameWriter V2 anziché V1.
# API a grana fine nativa di Spark per il controllo degli accessi PySpark
Per mantenere i controlli di sicurezza e accesso ai dati, il controllo granulare degli accessi di Spark (FGAC) limita determinate funzioni. PySpark Queste restrizioni vengono applicate tramite:
+ Blocco esplicito che impedisce l'esecuzione della funzione
+ Incompatibilità dell'architettura che rendono le funzioni non funzionali
+ Funzioni che possono generare errori, restituire messaggi di accesso negato o non eseguire alcuna operazione quando vengono chiamate
Le seguenti PySpark funzionalità non sono supportate in Spark FGAC:
+ Operazioni RDD (bloccate con Spark Exception) RDDUnsupported
+ Spark Connect (non supportato)
+ Spark Streaming (non supportato)
Sebbene abbiamo testato le funzioni elencate in un ambiente FGAC Spark nativo e confermato che funzionano come previsto, i nostri test in genere coprono solo l'utilizzo di base di ciascuna API. Le funzioni con più tipi di input o percorsi logici complessi possono presentare scenari non testati.
Per tutte le funzioni non elencate qui e che non rientrano chiaramente nelle categorie non supportate di cui sopra, consigliamo di:
+ Testarle prima in un ambiente gamma o in una distribuzione su piccola scala
+ Verifica del loro comportamento prima di utilizzarli in produzione
**Nota**
Se vedi elencato un metodo di classe ma non la sua classe base, il metodo dovrebbe comunque funzionare, significa solo che non abbiamo verificato esplicitamente il costruttore della classe base.
L' PySpark API è organizzata in moduli. Il supporto generale per i metodi all'interno di ciascun modulo è dettagliato nella tabella seguente.
| Nome del modulo | Stato | Note |
| --- | --- | --- |
| pyspark\$1core | Supportata | Questo modulo contiene le classi RDD principali e queste funzioni per lo più non sono supportate. |
| pyspark\$1sql | Supportata | |
| pyspark\$1testing | Supportata | |
| pyspark\$1resource | Supportata | |
| pyspark\$1streaming | Bloccato | L'utilizzo dello streaming è bloccato in Spark FGAC. |
| pyspark\$1mllib | sperimentale | Questo modulo contiene operazioni ML basate su RDD e queste funzioni per lo più non sono supportate. Questo modulo non è stato testato a fondo. |
| pyspark\$1ml | sperimentale | Questo modulo contiene operazioni di DataFrame machine learning basate e queste funzioni sono per lo più supportate. Questo modulo non è stato testato a fondo. |
| pyspark\$1pandas | Supportata | |
| pyspark\$1pandas\$1slow | Supportata | |
| pyspark\$1connect | Bloccato | L'utilizzo di Spark Connect è bloccato in Spark FGAC. |
| pyspark\$1pandas\$1connect | Bloccato | L'utilizzo di Spark Connect è bloccato in Spark FGAC. |
| pyspark\$1pandas\$1slow\$1connect | Bloccato | L'utilizzo di Spark Connect è bloccato in Spark FGAC. |
| pyspark\$1errors | sperimentale | Questo modulo non è stato testato a fondo. Le classi di errore personalizzate non possono essere utilizzate. |
**Elenco delle API consentite**
Per un elenco scaricabile e più facile da cercare, un file con i moduli e le classi è disponibile nelle [funzioni Python consentite](samples/Python functions allowed in Native FGAC.zip) in Native FGAC.
# Accesso completo alla tabella di Lake Formation per Amazon EMR su EC2
Con le versioni 7.8.0 e successive di Amazon EMR, puoi sfruttare AWS Lake Formation with Glue Data Catalog, dove il ruolo di job runtime dispone di autorizzazioni complete per le tabelle senza le limitazioni del controllo granulare degli accessi. Questa funzionalità ti consente di leggere e scrivere su tabelle protette da Lake Formation dal tuo batch Amazon EMR su EC2 Spark e dai lavori interattivi. Consulta le seguenti sezioni per saperne di più su Lake Formation e su come utilizzarlo con Amazon EMR su EC2.
## Utilizzo di Lake Formation con accesso completo ai tavoli
Puoi accedere alle tabelle del catalogo Glue Data protette da AWS Lake Formation da Amazon EMR su job EC2 Spark o sessioni interattive in cui il ruolo di runtime del job ha accesso completo alla tabella. Non è necessario abilitare AWS Lake Formation sull'applicazione Amazon EMR su EC2. Quando un job Spark è configurato per Full Table Access (FTA), le credenziali di AWS Lake Formation vengono utilizzate per i dati read/write S3 per le tabelle registrate di AWS Lake Formation, mentre le credenziali del ruolo di runtime del lavoro verranno utilizzate per le read/write tabelle non registrate con Lake Formation. AWS
**Importante**
Non abilitare AWS Lake Formation per il controllo granulare degli accessi. Un job non può eseguire contemporaneamente Full Table Access (FTA) e Fine-Grained Access Control (FGAC) sullo stesso cluster o applicazione EMR.
### Passaggio 1: abilitare l'accesso completo alla tabella in Lake Formation
Per utilizzare la modalità Full Table Access (FTA), devi consentire ai motori di query di terze parti di accedere ai dati senza la convalida del tag di sessione IAM in AWS Lake Formation. Per abilitarli, seguire i passaggi descritti in [Integrazione delle applicazioni per l'accesso completo alla tabella](https://docs.aws.amazon.com/lake-formation/latest/dg/full-table-credential-vending.html).
**Nota**
Quando si accede alle tabelle tra account diversi, è necessario abilitare l'accesso completo alla tabella sia negli account produttore che in quelli consumer. Allo stesso modo, quando si accede alle tabelle interregionali, questa impostazione deve essere abilitata sia nelle regioni produttrici che in quelle di consumo.
### Fase 2: Configurazione delle autorizzazioni IAM per il ruolo di runtime dei processi
Per l'accesso in lettura o scrittura ai dati sottostanti, oltre alle autorizzazioni di Lake Formation, un ruolo di job runtime richiede l'autorizzazione `lakeformation:GetDataAccess` IAM. Con questa autorizzazione, Lake Formation concede la richiesta di credenziali temporanee per accedere ai dati.
Di seguito è riportato un esempio di politica su come fornire le autorizzazioni IAM per accedere a uno script in Amazon S3, caricare i log su S3, le autorizzazioni dell'API AWS Glue e l'autorizzazione per accedere a Lake Formation.
#### Passaggio 2.1 Configurare i permessi di Lake Formation
+ I job Spark che leggono dati da S3 richiedono l'autorizzazione Lake Formation SELECT.
+ Spark rileva che write/delete i dati in S3 richiedono l'autorizzazione Lake Formation ALL (SUPER).
+ I lavori Spark che interagiscono con il catalogo Glue Data richiedono l'autorizzazione DESCRIBE, ALTER, DROP, a seconda dei casi.
Per ulteriori informazioni, consulta Concessione delle [autorizzazioni sulle risorse di Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
### Passaggio 3: inizializza una sessione Spark per l'accesso completo alla tabella utilizzando Lake Formation
#### Prerequisiti
AWS Glue Data Catalog deve essere configurato come metastore per accedere alle tabelle di Lake Formation.
Imposta le seguenti impostazioni per configurare il catalogo Glue come metastore:
```
--conf spark.sql.catalogImplementation=hive
--conf spark.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory
```
Per ulteriori informazioni sull'attivazione di Data Catalog for Amazon EMR su EC2, consulta la configurazione [Metastore per Amazon](metastore-config.html) EMR su EC2.
Per accedere alle tabelle registrate con AWS Lake Formation, è necessario impostare le seguenti configurazioni durante l'inizializzazione di Spark per configurare Spark per utilizzare le credenziali di Lake Formation AWS .
------
#### [ Hive ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Iceberg ]
```
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=S3_DATA_LOCATION
--conf spark.sql.catalog.spark_catalog.client.region=REGION
--conf spark.sql.catalog.spark_catalog.type=glue
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.lakeformation-enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Delta Lake ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Hudi ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
--conf spark.jars=/usr/lib/hudi/hudi-spark-bundle.jar
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer
```
------
+ `spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver`: Configurare EMR Filesystem (EMRFS) o EMR S3A per utilizzare le credenziali di Lake Formation S3 per le tabelle registrate di Lake AWS Formation. Se la tabella non è registrata, utilizzare le credenziali del ruolo di runtime del processo.
+ `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` e `spark.hadoop.fs.s3.folderObject.autoAction.disabled=true`: configurano EMRFS per utilizzare l'applicazione di intestazione di tipo di contenuto/directory x invece del suffisso \$1folder\$1 durante la creazione di cartelle S3. Questo è necessario per leggere le tabelle di Lake Formation, poiché le credenziali di Lake Formation non consentono la lettura delle cartelle delle tabelle con il suffisso \$1folder\$1.
+ `spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true`: configura Spark per saltare la convalida del vuoto della posizione della tabella prima della creazione. Ciò è necessario per le tabelle registrate di Lake Formation, poiché le credenziali di Lake Formation per verificare la posizione vuota sono disponibili solo dopo la creazione della tabella Glue Data Catalog. Senza questa configurazione, le credenziali del ruolo di runtime del processo convalideranno la posizione della tabella vuota.
+ `spark.sql.catalog.createDirectoryAfterTable.enabled=true`: configura Spark per creare la cartella Amazon S3 dopo la creazione della tabella nel metastore Hive. Questo è necessario per le tabelle registrate di Lake Formation, poiché le credenziali di Lake Formation per creare la cartella S3 sono disponibili solo dopo la creazione della tabella Glue Data Catalog.
+ `spark.sql.catalog.dropDirectoryBeforeTable.enabled=true`: Configura Spark per eliminare la cartella S3 prima dell'eliminazione della tabella nel metastore Hive. Ciò è necessario per le tabelle registrate di Lake Formation, poiché le credenziali di Lake Formation per eliminare la cartella S3 non sono disponibili dopo l'eliminazione della tabella dal Glue Data Catalog.
+ `spark.sql.catalog..glue.lakeformation-enabled=true`: Configura il catalogo Iceberg per utilizzare le credenziali di AWS Lake Formation S3 per le tabelle registrate di Lake Formation. Se la tabella non è registrata, usare le credenziali di ambiente predefinite.
#### Configura la modalità di accesso completo alla tabella in Unified Studio SageMaker
Per accedere alle tabelle registrate di Lake Formation dalle sessioni interattive di Spark nei JupyterLab notebook, utilizza la modalità di autorizzazione alla compatibilità. Usa il comando magic %%configure per configurare la configurazione di Spark. Scegliere la configurazione in base al tipo di tabella:
------
#### [ For Hive tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Iceberg tables ]
```
%%configure -f
{
"conf": {
"spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
"spark.sql.catalog.spark_catalog.warehouse": "S3_DATA_LOCATION",
"spark.sql.catalog.spark_catalog.client.region": "REGION",
"spark.sql.catalog.spark_catalog.type": "glue",
"spark.sql.catalog.spark_catalog.glue.account-id": "ACCOUNT_ID",
"spark.sql.catalog.spark_catalog.glue.lakeformation-enabled": "true",
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": "true",
}
}
```
------
#### [ For Delta Lake tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Hudi tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true,
"spark.jars": "/usr/lib/hudi/hudi-spark-bundle.jar",
"spark.sql.extensions": "org.apache.spark.sql.hudi.HoodieSparkSessionExtension",
"spark.sql.catalog.spark_catalog": "org.apache.spark.sql.hudi.catalog.HoodieCatalog",
"spark.serializer": "org.apache.spark.serializer.KryoSerializer"
}
}
```
------
Sostituire i segnaposto:
+ `S3_DATA_LOCATION`: Il percorso del tuo bucket S3
+ `REGION`: AWS regione (ad es. us-east-1)
+ `ACCOUNT_ID`: L'ID del tuo account AWS
**Nota**
È necessario impostare queste configurazioni prima di eseguire qualsiasi operazione Spark sul notebook.
#### Operazioni supportate
Queste operazioni utilizzeranno le credenziali di AWS Lake Formation per accedere ai dati della tabella.
+ CREATE TABLE
+ ALTER TABLE
+ INSERT INTO
+ INSERT OVERWRITE
+ UPDATE
+ MERGE INTO
+ DELETE FROM
+ ANALYZE TABLE
+ REPAIR TABLE
+ DROP TABLE
+ Query su origini dati Spark
+ Scritture di origini dati Spark
**Nota**
Le operazioni non elencate sopra continueranno a utilizzare le autorizzazioni IAM per accedere ai dati delle tabelle.
#### Considerazioni
+ Se una tabella Hive viene creata utilizzando un lavoro per cui non è abilitato l'accesso completo alla tabella e non viene inserito alcun record, le letture o scritture successive da un lavoro con accesso completo alla tabella avranno esito negativo. Questo perché EMR Spark senza accesso completo alla tabella aggiunge il `$folder$` suffisso al nome della cartella della tabella. Per risolvere questo problema, è possibile procedere in questi modi:
+ Inserire almeno una riga nella tabella da un processo che non ha FTA abilitato.
+ Configura il lavoro che non ha FTA abilitato in modo che non utilizzi il `$folder$` suffisso nel nome della cartella in S3. Ciò si può ottenere impostando la configurazione `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` di Spark.
+ Crea una cartella S3 nella posizione della tabella `s3://path/to/table/table_name` utilizzando la console AWS S3 o la CLI AWS S3.
+ L'accesso completo alla tabella è supportato con il file system EMR (EMRFS) a partire dalla versione 7.8.0 di Amazon EMR e con il file system S3A a partire dalla versione 7.10.0 di Amazon EMR.
+ L'accesso completo alle tabelle è supportato per le tabelle Hive, Iceberg, Delta e Hudi.
+ **Considerazioni su Hudi FTA Write Support:**
+ Le scritture Hudi FTA richiedono l'utilizzo HoodieCredentialedHadoopStorage per la vendita di credenziali durante l'esecuzione del lavoro. Imposta la seguente configurazione durante l'esecuzione dei job Hudi: `hoodie.storage.class=org.apache.spark.sql.hudi.storage.HoodieCredentialedHadoopStorage`
+ Il supporto di scrittura Full Table Access (FTA) per Hudi è disponibile a partire dalla release 7.12 di Amazon EMR.
+ Il supporto di scrittura Hudi FTA attualmente funziona solo con le configurazioni Hudi predefinite. Le impostazioni Hudi personalizzate o non predefinite potrebbero non essere completamente supportate e potrebbero causare comportamenti imprevisti.
+ Il clustering per le tabelle Hudi Merge-On-Read (MOR) non è supportato a questo punto in modalità di scrittura FTA.
+ I lavori che fanno riferimento alle tabelle con le regole Lake Formation Fine-Grained Access Control (FGAC) o Glue Data Catalog Views avranno esito negativo. Per interrogare una tabella con regole FGAC o Glue Data Catalog View, è necessario utilizzare la modalità FGAC. Puoi abilitare la modalità FGAC seguendo i passaggi descritti nella AWS documentazione: Utilizzo di [Amazon EMR su EC2 con Lake AWS Formation](emr-serverless-lf-enable.html) per un controllo granulare degli accessi.
+ L'accesso completo alla tabella non supporta Spark Streaming.
+ Quando si scrive Spark DataFrame su una tabella Lake Formation, è supportata solo la modalità APPEND per le tabelle Hive e Iceberg: `df.write.mode("append").saveAsTable(table_name)`
+ La creazione di tabelle esterne richiede autorizzazioni IAM.
+ Poiché Lake Formation memorizza temporaneamente nella cache le credenziali all'interno di un lavoro Spark, un processo batch Spark o una sessione interattiva attualmente in esecuzione potrebbero non riflettere le modifiche alle autorizzazioni.
+ È necessario utilizzare un ruolo definito dall'utente e non un ruolo collegato al servizio: [requisiti per i ruoli di Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/registration-role.html).
#### Hudi FTA Write Support - Operazioni supportate
La tabella seguente mostra le operazioni di scrittura supportate per le tabelle Hudi Copy-On-Write (COW) e Merge-On-Read (MOR) in modalità Full Table Access:
**Operazioni di scrittura supportate da Hudi FTA**
| Tipo tabella | Operation | Comando di scrittura SQL | Stato |
| --- | --- | --- | --- |
| MUCCA | INSERT | INSERT INTO TABLE | Supportata |
| MUCCA | INSERT | INSERISCI NELLA TABELLA - PARTIZIONE (statica, dinamica) | Supportata |
| MUCCA | INSERT | INSERT OVERWRITE | Supportata |
| MUCCA | INSERT | INSERT OVERWRITE - PARTIZIONE (statica, dinamica) | Supportata |
| UPDATE | UPDATE | UPDATE TABLE | Supportata |
| MUCCA | UPDATE | TABELLA DI AGGIORNAMENTO - Cambia partizione | Non supportato |
| DELETE | DELETE | DELETE FROM TABLE | Supportata |
| ALTER | ALTER | MODIFICA TABELLA: RINOMINA IN | Non supportato |
| MUCCA | ALTER | MODIFICA TABELLA - IMPOSTA TBLPROPERTIES | Supportata |
| MUCCA | ALTER | ALTER TABLE - ANNULLA TBLPROPERTIES | Supportata |
| MUCCA | ALTER | ALTERA TABELLA - MODIFICA COLONNA | Supportata |
| MUCCA | ALTER | ALTERA TABELLA - AGGIUNGI COLONNE | Supportata |
| MUCCA | ALTER | ALTER TABLE - AGGIUNGI UNA PARTIZIONE | Supportata |
| MUCCA | ALTER | ALTERA TABELLA - ELIMINA LA PARTIZIONE | Supportata |
| MUCCA | ALTER | ALTER TABLE - RECUPERA LE PARTIZIONI | Supportata |
| MUCCA | ALTER | RIPARA LE PARTIZIONI DI SINCRONIZZAZIONE DELLE TABELLE | Supportata |
| DROP | DROP | DROP TABLE | Supportata |
| MUCCA | DROP | DROP TABLE - PURGE | Supportata |
| CREATE | CREATE | CREATE TABLE - Gestito | Supportata |
| MUCCA | CREATE | CREA TABELLA - PARTIZIONA PER | Supportata |
| MUCCA | CREATE | CREA UNA TABELLA SE NON ESISTE | Supportata |
| MUCCA | CREATE | CREATE TABLE LIKE | Supportata |
| MUCCA | CREATE | CREATE TABLE AS SELECT | Supportata |
| CREATE | CREATE | CREA TABELLA con LOCATION - Tabella esterna | Non supportato |
| DATAFRAME (INSERIRE) | DATAFRAME (INSERIRE) | saveAsTable.Sovrascrivi | Supportata |
| MUCCA | DATAFRAME (INSERISCI) | saveAsTable.Aggiungi | Non supportato |
| MUCCA | DATAFRAME (INSERISCI) | saveAsTable.Ignora | Supportata |
| MUCCA | DATAFRAME (INSERISCI) | saveAsTable.ErrorIfExists | Supportata |
| MUCCA | DATAFRAME (INSERISCI) | saveAsTable - Tabella esterna (Path) | Non supportato |
| MUCCA | DATAFRAME (INSERISCI) | salva (percorso) - DF v1 | Non supportato |
| ALTRO | INSERT | INSERT INTO TABLE | Supportata |
| MOR | INSERT | INSERISCI NELLA TABELLA - PARTIZIONE (statica, dinamica) | Supportata |
| ALTRO | INSERT | INSERT OVERWRITE | Supportata |
| MOR | INSERT | INSERT OVERWRITE - PARTIZIONE (statica, dinamica) | Supportata |
| UPDATE | UPDATE | UPDATE TABLE | Supportata |
| ALTRO | UPDATE | TABELLA DI AGGIORNAMENTO - Cambia partizione | Non supportato |
| DELETE | DELETE | DELETE FROM TABLE | Supportata |
| ALTER | ALTER | MODIFICA TABELLA: RINOMINA IN | Non supportato |
| - ALTRO | ALTER | MODIFICA TABELLA - IMPOSTA TBLPROPERTIES | Supportata |
| ALTRO | ALTER | MODIFICA TABELLA - ANNULLA TBLPROPERTIES | Supportata |
| ALTRO | ALTER | MODIFICA TABELLA - MODIFICA COLONNA | Supportata |
| ALTRO | ALTER | ALTERA TABELLA - AGGIUNGI COLONNE | Supportata |
| - ALTRO | ALTER | ALTER TABLE - AGGIUNGI UNA PARTIZIONE | Supportata |
| - ALTRO | ALTER | ALTERA TABELLA - ELIMINA LA PARTIZIONE | Supportata |
| - ALTRO | ALTER | ALTER TABLE - RECUPERA LE PARTIZIONI | Supportata |
| - ALTRO | ALTER | RIPARA LE PARTIZIONI DI SINCRONIZZAZIONE DELLE TABELLE | Supportata |
| DROP | DROP | DROP TABLE | Supportata |
| ALTRO | DROP | DROP TABLE - PURGE | Supportata |
| CREATE | CREATE | CREATE TABLE - Gestito | Supportata |
| ALTRO | CREATE | CREA TABELLA - PARTIZIONA PER | Supportata |
| - ALTRO | CREATE | CREA UNA TABELLA SE NON ESISTE | Supportata |
| ALTRO | CREATE | CREATE TABLE LIKE | Supportata |
| MOR | CREATE | CREATE TABLE AS SELECT | Supportata |
| CREATE | CREATE | CREA TABELLA con LOCATION - Tabella esterna | Non supportato |
| DATAFRAME (UPSERT) | DATAFRAME (UPSERT) | saveAsTable.Sovrascrivi | Supportata |
| ALTRO | DATAFRAME (SCONVOLTO) | saveAsTable.Aggiungi | Non supportato |
| ALTRO | DATAFRAME (SCONVOLTO) | saveAsTable.Ignora | Supportata |
| ALTRO | DATAFRAME (SCONVOLTO) | saveAsTable.ErrorIfExists | Supportata |
| PIÙ | DATAFRAME (SCONVOLTO) | saveAsTable - Tabella esterna (Path) | Non supportato |
| - ALTRO | DATAFRAME (SCONVOLTO) | salva (percorso) - DF v1 | Non supportato |
| DATAFRAME (ELIMINA) | DATAFRAME (ELIMINA) | saveAsTable.Aggiungi | Non supportato |
| ALTRO | DATAFRAME (ELIMINA) | saveAsTable - Tabella esterna (Path) | Non supportato |
| - ALTRO | DATAFRAME (ELIMINA) | salva (percorso) - DF v1 | Non supportato |
| DATAFRAME (BULK\$1INSERT) | DATAFRAME (BULK\$1INSERT) | saveAsTable.Sovrascrivi | Supportata |
| ALTRO | DATAFRAME (BULK\$1INSERT) | saveAsTable.Aggiungi | Non supportato |
| ALTRO | DATAFRAME (BULK\$1INSERT) | saveAsTable.Ignora | Supportata |
| ALTRO | DATAFRAME (BULK\$1INSERT) | saveAsTable.ErrorIfExists | Supportata |
| PIÙ | DATAFRAME (BULK\$1INSERT) | saveAsTable - Tabella esterna (Path) | Non supportato |
| - ALTRO | DATAFRAME (BULK\$1INSERT) | salva (percorso) - DF v1 | Non supportato |
# Integrazione di Amazon EMR con Apache Ranger
A partire da Amazon EMR 5.32.0, è possibile avviare un cluster che si integra nativamente con Apache Ranger. Apache Ranger è un framework open source che consente di abilitare, monitorare e gestire la sicurezza completa dei dati attraverso la piattaforma Hadoop. Per ulteriori informazioni, consulta [Apache Ranger](https://ranger.apache.org/). L'integrazione nativa consente di utilizzare Apache Ranger per imporre un controllo granulare di accesso ai dati su Amazon EMR.
Questa sezione fornisce una panoramica delle nozioni di base dell'integrazione di Amazon EMR con Apache Ranger. Include inoltre i prerequisiti e le fasi necessari per avviare un cluster Amazon EMR integrato con Apache Ranger.
L'integrazione nativa di Amazon EMR con Apache Ranger offre i seguenti vantaggi principali:
+ Controllo dell'accesso granulare ai database e alle tabelle del metastore Hive, che consente di definire policy di filtraggio dei dati a livello di database, tabella e colonna per le applicazioni Apache Spark e Apache Hive. Il filtraggio a livello di riga e il mascheramento dei dati sono supportati con le applicazioni Hive.
+ La possibilità di utilizzare le policy Hive esistenti direttamente con Amazon EMR per le applicazioni Hive.
+ Controllo dell'accesso ai dati di Amazon S3 a livello di prefisso e oggetto, che consente di definire policy di filtraggio dei dati per l'accesso ai dati S3 utilizzando il file system EMR.
+ La possibilità di utilizzare i CloudWatch registri per il controllo centralizzato.
+ Amazon EMR installa e gestisce i plug-in Apache Ranger per conto tuo.
# Apache Ranger con Amazon EMR
Apache Ranger è un framework che consente di abilitare, monitorare e gestire la sicurezza completa dei dati attraverso la piattaforma Hadoop.
Apache Ranger è dotata delle seguenti caratteristiche:
+ Amministrazione della sicurezza centralizzata per gestire tutte le attività relative alla sicurezza in un'interfaccia utente centrale o utilizzando REST. APIs
+ Autorizzazione granulare per eseguire un'operazione specifica o un'operazione con un componente o uno strumento Hadoop, gestito tramite uno strumento di amministrazione centrale.
+ Un metodo di autorizzazione standardizzato per tutti i componenti Hadoop.
+ Supporto avanzato per vari metodi di autorizzazione.
+ Verifica centralizzata dell'accesso degli utenti e delle operazioni amministrative (relative alla sicurezza) all'interno di tutti i componenti di Hadoop.
Apache Ranger utilizza due componenti chiave per l'autorizzazione:
+ **Server di amministrazione delle policy di Apache Ranger**: questo server consente di definire le policy di autorizzazione per le applicazioni Hadoop. Durante l'integrazione con Amazon EMR, puoi definire e applicare policy per Apache Spark e Hive per accedere al Hive Metastore e ai dati di Amazon S3 [File System EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs). Per l'integrazione con Amazon EMR, puoi configurare un server di amministrazione delle policy di Apache Ranger esistente.
+ **Plug-in Apache Ranger**: questo plug-in convalida l'accesso di un utente rispetto alle policy di autorizzazione definite nel server di amministrazione delle policy di Apache Ranger. Amazon EMR installa e configura automaticamente il plug-in Apache Ranger per ogni applicazione Hadoop selezionata nella configurazione di Apache Ranger.
**Topics**
+ [Architettura dell'integrazione di Amazon EMR con Apache Ranger](emr-ranger-architecture.md)
+ [Componenti Amazon EMR da utilizzare con Apache Ranger](emr-ranger-components.md)
# Architettura dell'integrazione di Amazon EMR con Apache Ranger
![\[Diagramma dell'architettura Amazon EMR e Apache Ranger.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/emr-ranger-architecture.png)
# Componenti Amazon EMR da utilizzare con Apache Ranger
Amazon EMR consente il controllo granulare degli accessi con Apache Ranger attraverso i seguenti componenti. Fai riferimento al [diagramma dell'architettura](emr-ranger-architecture.md) per una rappresentazione grafica dei componenti Amazon EMR con i plug-in Apache Ranger.
**Secret agent (Agente segreto)**: l'agente segreto archivia in modo sicuro i segreti e distribuisce i segreti ad altri componenti o applicazioni Amazon EMR. I segreti possono includere credenziali utente temporanee, chiavi di crittografia o ticket Kerberos. L'agente segreto viene eseguito su ogni nodo del cluster e intercetta le chiamate al servizio metadati dell'istanza. Per le richieste alle credenziali del ruolo del profilo dell'istanza, l'agente segreto vende le credenziali in base all'utente richiedente e alle risorse richieste dopo aver autorizzato la richiesta con il plug-in EMRFS S3 Ranger. L'agente segreto viene eseguito come *`emrsecretagent`*utente e scrive i log nella directory /. emr/secretagent/log Il processo si basa su un set specifico di regole `iptables` per funzionare. È importante assicurarsi che `iptables` non sia disabilitato. Se si personalizza la configurazione `iptables`, le regole della tabella NAT devono essere mantenute e lasciate invariate.
**EMR record server (Server di registro EMR)**: il server di registro riceve le richieste di accesso ai dati da Spark. In seguito autorizza le richieste inoltrando le risorse richieste al plug-in Spark Ranger per Amazon EMR. Il server di registro legge i dati da Amazon S3 e restituisce i dati filtrati a cui l'utente è autorizzato ad accedere in funzione della policy di Ranger. Il server di registrazione viene eseguito su ogni nodo del cluster come utente emr\$1record\$1server e scrive i log nella directory/-record-server. var/log/emr
# Considerazioni sull'utilizzo di Amazon EMR con Apache Ranger
## Applicazioni supportate per Amazon EMR con Apache Ranger
Attualmente, l'integrazione tra Amazon EMR e Apache Ranger in cui EMR installa i plug-in Ranger supporta le seguenti applicazioni:
+ Apache Spark (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Hive (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ S3 Access tramite EMRFS (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
Le seguenti applicazioni possono essere installate in un cluster EMR e possono essere configurate per soddisfare le esigenze di sicurezza:
+ Apache Hadoop (disponibile con EMR 5.32\$1 e EMR 6.3\$1 compresi YARN e HDFS)
+ Apache Livy (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Zeppelin (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Hue (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ Ganglia (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ HCatalog (Disponibile con EMR 5.32\$1 ed EMR 6.3\$1)
+ Mahout (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ MXNet (Disponibile con EMR 5.32\$1 ed EMR 6.3\$1)
+ TensorFlow (Disponibile con EMR 5.32\$1 ed EMR 6.3\$1)
+ Tez (disponibile con EMR 5.32\$1 e EMR 6.3\$1)
+ Trino (disponibile con EMR 6.7\$1)
+ ZooKeeper (Disponibile con EMR 5.32\$1 ed EMR 6.3\$1)
**Importante**
Le applicazioni elencate sopra sono le uniche applicazioni attualmente supportate. Per garantire la sicurezza del cluster, è consentito creare un cluster EMR con solo le applicazioni nell'elenco precedente quando Apache Ranger è abilitato.
Altre applicazioni non sono attualmente supportate. Per garantire la sicurezza del cluster, il tentativo di installare altre applicazioni causerà il rifiuto del cluster.
AWS I formati Glue Data Catalog e Open table come Apache Hudi, Delta Lake e Apache Iceberg non sono supportati.
**Funzionalità di Amazon EMR supportate con Apache Ranger**
Le seguenti funzionalità di Amazon EMR sono supportate quando utilizzi Amazon EMR con Apache Ranger:
+ Crittografia dei dati su disco e in transito.
+ Autenticazione Kerberos (obbligatoria)
+ Gruppi di istanze, parchi istanze e istanze Spot
+ Riconfigurazione delle applicazioni in un cluster in esecuzione
+ Server-Side Encryption (SSE) EMRFS
**Nota**
Le impostazioni di crittografia di Amazon EMR regolano SSE. Per ulteriori informazioni, consulta [Opzioni di crittografia](emr-data-encryption-options.md).
## Limiti dell'applicazione
Ci sono diverse limitazioni da tenere a mente quando si integra Amazon EMR e Apache Ranger:
+ Al momento non è possibile utilizzare la console per creare una configurazione di sicurezza che specifichi l'opzione di integrazione AWS Ranger in. AWS GovCloud (US) Region La configurazione della sicurezza può essere eseguita utilizzando la CLI.
+ Kerberos deve essere installato nel cluster.
+ Le applicazioni UIs (interfacce utente) come l'interfaccia utente di YARN Resource Manager, l'interfaccia utente HDFS e l' NameNode interfaccia utente Livy non sono impostate con l'autenticazione per impostazione predefinita.
+ Le autorizzazioni predefinite HDFS `umask` sono configurate in modo che gli oggetti creati siano impostati su `world wide readable` per impostazione predefinita.
+ Amazon EMR non supporta la modalità ad alta disponibilità (principale multipla) con Apache Ranger.
+ Per ulteriori limitazioni, consulta le limitazioni per ogni applicazione.
**Nota**
Le impostazioni di crittografia di Amazon EMR regolano SSE. Per ulteriori informazioni, consulta [Opzioni di crittografia](emr-data-encryption-options.md).
## Limitazioni del plug-in
Ogni plug-in ha limitazioni specifiche. Per le limitazioni del plug-in Apache Hive, consulta [Limitazioni del plug-in Apache Hive](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-hive.html#emr-ranger-hive-limitations). Per le limitazioni del plug-in Apache Spark, consulta [Limitazioni del plug-in Apache Spark](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-spark.html#emr-ranger-spark-limitations). Per le limitazioni del plug-in EMRFS S3, consulta [Limitazioni del plug-in EMRFS S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-emrfs.html#emr-ranger-emrfs-limitations).
# Configurazione di Amazon EMR per Apache Ranger
Prima di installare Apache Ranger, consulta le informazioni contenute in questa sezione per verificare che Amazon EMR sia configurato correttamente.
**Topics**
+ [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md)
+ [Ruoli IAM per l'integrazione nativa con Apache Ranger](emr-ranger-iam.md)
+ [Creazione di una configurazione di sicurezza EMR](emr-ranger-security-config.md)
+ [Archivia i certificati TLS in Gestione dei segreti AWS](emr-ranger-tls-certificates.md)
+ [Avvia un cluster EMR con Apache Ranger](emr-ranger-start-emr-cluster.md)
+ [Configurazione dei cluster Amazon EMR abilitati da Zeppelin per Apache Ranger](emr-ranger-configure-zeppelin.md)
+ [Problemi noti per l'integrazione con Amazon EMR](emr-ranger-security-considerations.md)
# Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR
Per l'integrazione di Amazon EMR, i plug-in dell'applicazione Apache Ranger devono comunicare con il server Admin utilizzando TLS/SSL.
**Prerequisito: SSL abilitato con il server Admin Ranger**
Apache Ranger su Amazon EMR richiede una comunicazione SSL bidirezionale tra i plug-in e il server Admin Ranger. Per garantire che i plugin comunichino con il server Apache Ranger tramite SSL, abilita il seguente attributo all'interno del ranger-admin-site file.xml sul server Ranger Admin.
```
ranger.service.https.attrib.ssl.enabled
true
```
Inoltre, sono necessarie le seguenti configurazioni.
```
ranger.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.pass
__
ranger.service.https.attrib.keystore.keyalias
ranger.service.https.attrib.clientAuth
want
ranger.service.https.port
6182
```
# Certificati TLS per l'integrazione di Apache Ranger con Amazon EMR
L'integrazione di Apache Ranger con Amazon EMR richiede che il traffico dai nodi di Amazon EMR al server Admin Ranger sia crittografato utilizzando TLS e che i plug-in Ranger si autentichino al server Apache Ranger utilizzando l'autenticazione TLS reciproca bidirezionale. Il servizio Amazon EMR richiede il certificato pubblico del server Admin Ranger (specificato nell'esempio precedente) e il certificato privato.
**Certificati del plug-in Apache Ranger**
I certificati TLS pubblici del plug-in Apache Ranger devono essere accessibili al server Admin Apache Ranger per convalidare quando i plug-in si connettono. Esistono tre metodi diversi per eseguire questa operazione.
**Metodo 1: Configurazione di un truststore nel server Admin Apache Ranger**
Compila le seguenti configurazioni in ranger-admin-site .xml per configurare un truststore.
```
ranger.truststore.file
ranger.truststore.password
```
**Metodo 2: Caricamento del certificato in Java cacerts truststore**
Se il tuo server Admin Ranger non specifica un truststore nelle sue opzioni JVM, puoi inserire i certificati pubblici del plug-in nell'archivio cacerts predefinito.
**Metodo 3: Creazione di un truststore specificato come parte delle opzioni JVM**
In `{RANGER_HOME_DIRECTORY}/ews/ranger-admin-services.sh`, modifica `JAVA_OPTS` per includere `"-Djavax.net.ssl.trustStore="` e `"-Djavax.net.ssl.trustStorePassword="`. Ad esempio, aggiungi la seguente riga dopo il JAVA\$1OPTS esistente.
```
JAVA_OPTS=" ${JAVA_OPTS} -Djavax.net.ssl.trustStore=${RANGER_HOME}/truststore/truststore.jck -Djavax.net.ssl.trustStorePassword=changeit"
```
**Nota**
Questa specifica può esporre la password truststore se un utente è in grado di accedere al server Admin Apache Ranger e vedere i processi in esecuzione, ad esempio quando si utilizza il comando `ps`.
**Utilizzo di certificati autofirmati**
I certificati autofirmati non sono consigliati come certificati. I certificati autofirmati potrebbero non essere revocati o non essere conformi ai requisiti di sicurezza interni.
# Installazione della definizione del servizio per l'integrazione di Ranger con Amazon EMR
Una definizione di servizio viene utilizzata dal server Admin Ranger per descrivere gli attributi delle policy per un'applicazione. Le policy vengono quindi archiviate in un repository di policy per il download dei client.
Per poter configurare le definizioni dei servizi, le chiamate REST devono essere effettuate al server Admin Ranger. Consulta [Apache Ranger Public APIsv2](https://ranger.apache.org/apidocs/resource_PublicAPIsv2.html#resource_PublicAPIsv2_createServiceDef_POST) per informazioni APIs richieste nella sezione seguente.
**Installazione della definizione del servizio di Apache Spark**
Per installare la definizione del servizio di Apache Spark, consulta [Plugin Apache Spark per l'integrazione di Ranger con Amazon EMR](emr-ranger-spark.md).
**Installazione della definizione del servizio EMRFS**
Per installare la definizione del servizio S3 per Amazon EMR, consulta [Plugin EMRFS S3 per l'integrazione di Ranger con Amazon EMR](emr-ranger-emrfs.md).
**Utilizzo della definizione del servizio Hive**
Apache Hive può utilizzare la definizione del servizio Ranger esistente fornita con Apache Ranger 2.0 e versioni successive. Per ulteriori informazioni, consulta [Plugin Apache Hive per l'integrazione di Ranger con Amazon EMR](emr-ranger-hive.md).
# Regole del traffico di rete per l'integrazione con Amazon EMR
Quando Apache Ranger è integrato con il cluster EMR, il cluster deve comunicare con server aggiuntivi e AWS.
Tutti i nodi Amazon EMR, inclusi i nodi principali e attività, devono essere in grado di comunicare con i server Admin Apache Ranger per scaricare le policy. Se il tuo Apache Ranger Admin è in esecuzione su Amazon EC2, devi aggiornare il gruppo di sicurezza per poter prelevare il traffico dal cluster EMR.
Oltre a comunicare con il server Ranger Admin, tutti i nodi devono essere in grado di comunicare con i seguenti servizi: AWS
+ Simple Storage Service (Amazon S3)
+ AWS KMS (se si utilizza EMRFS SSE-KMS)
+ Amazon CloudWatch
+ AWS STS
Se prevedi di eseguire il cluster EMR all'interno di una sottorete privata, configura il VPC per comunicare con questi servizi utilizzando [AWS PrivateLink ed endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) nella *Guida per l'utente di Amazon VPC* oppure utilizzando un'[istanza NAT (Network Address Translation)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) nella *Guida per l'utente di Amazon VPC*.
# Ruoli IAM per l'integrazione nativa con Apache Ranger
L'integrazione tra Amazon EMR e Apache Ranger si basa su tre ruoli chiave che è necessario creare prima di avviare il cluster:
+ Un profilo dell'istanza Amazon EC2 personalizzato per Amazon EMR
+ Un ruolo IAM per Apache Ranger Engines
+ Un ruolo IAM per altri servizi AWS
Questa sezione fornisce una panoramica di questi ruoli e delle policy che è necessario includere per ogni ruolo IAM. Per informazioni sulla creazione di questi ruoli, consulta [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md).
# Profilo di istanza EC2 per Amazon EMR
Amazon EMR utilizza un ruolo di servizio IAM per eseguire operazioni per tuo conto per il provisioning e la gestione dei cluster. Il ruolo di servizio per le istanze EC2 del cluster, detto anche profilo dell'istanza EC2 per Amazon EMR, è un tipo speciale di ruolo di servizio assegnato a ogni istanza EC2 in un cluster all'avvio.
Per definire le autorizzazioni per l'interazione del cluster EMR con i dati di Amazon S3 e con il metastore Hive protetto da Apache Ranger e AWS altri servizi, definisci un profilo di istanza EC2 personalizzato da utilizzare al posto di quando avvii il cluster. `EMR_EC2_DefaultRole`
Per ulteriori informazioni, consultare [Ruolo di servizio per istanze EC2 del cluster (profilo istanza EC2)](emr-iam-role-for-ec2.md) e [Personalizza i ruoli IAM con Amazon EMR](emr-iam-roles-custom.md).
È necessario aggiungere le seguenti istruzioni al profilo di istanza EC2 predefinito per Amazon EMR per poter etichettare le sessioni e accedere ai Gestione dei segreti AWS certificati TLS che archivia.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam:::role/",
"arn:aws:iam:::role/"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:::secret:*",
"arn:aws:secretsmanager:::secret:*"
]
}
```
**Nota**
Per le autorizzazioni di Secrets Manager, non dimenticare il carattere jolly ("\$1") alla fine del nome segreto, altrimenti le richieste non avranno esito positivo. Il carattere jolly vale per le versioni segrete.
**Nota**
Limita l'ambito della Gestione dei segreti AWS policy ai soli certificati necessari per il provisioning.
# Ruolo IAM per Apache Ranger
Questo ruolo fornisce ai motori di esecuzione attendibili, ad esempio Apache Hive e Amazon EMR Record Serve, le credenziali per accedere ai dati Amazon S3. Utilizza solo questo ruolo per accedere ai dati di Amazon S3, incluse le chiavi KMS, se utilizzi S3 SSE-KMS.
Questo ruolo deve essere creato con la policy minima riportata nell'esempio seguente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudwatchLogsPermissions",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Resource": [
"arn:aws:logs:*:123456789012:log-group:CLOUDWATCH_LOG_GROUP_NAME_IN_SECURITY_CONFIGURATION:*"
]
},
{
"Sid": "BucketPermissionsInS3Buckets",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket2"
]
},
{
"Sid": "ObjectPermissionsInS3Objects",
"Action": [
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
}
]
}
```
------
**Importante**
L'asterisco «\$1» alla fine della risorsa di CloudWatch registro deve essere incluso per consentire la scrittura nei flussi di registro.
**Nota**
Se utilizzi la visualizzazione di coerenza EMRFS o la crittografia S3-SSE, aggiungi le autorizzazioni alle tabelle DynamoDB e alle chiavi del servizio di gestione delle chiavi in modo che i motori di esecuzione possano interagire con tali motori.
Il ruolo IAM per Apache Ranger viene assunto dal ruolo del profilo dell'istanza EC2. Utilizza l'esempio seguente per creare una policy di affidabilità che consenta di assumere il ruolo IAM per Apache Ranger dal ruolo del profilo dell'istanza EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Ruolo IAM per altri AWS servizi per l'integrazione con Amazon EMR
Questo ruolo fornisce agli utenti che non sono motori di esecuzione affidabili le credenziali per interagire con AWS i servizi, se necessario. Non utilizzare questo ruolo IAM per consentire l'accesso ai dati di Amazon S3, a meno che non si tratti di dati che devono essere accessibili a tutti gli utenti.
Questo ruolo verrà assunto dal ruolo del profilo dell'istanza EC2. Utilizza l'esempio seguente per creare una policy di affidabilità che consenta di assumere il ruolo IAM per Apache Ranger dal ruolo del profilo dell'istanza EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Convalida le autorizzazioni per l'integrazione di Amazon EMR con Apache Ranger
Consulta [Risoluzione dei problemi di Apache Ranger](emr-ranger-troubleshooting.md) per istruzioni sulla convalida delle autorizzazioni.
# Creazione di una configurazione di sicurezza EMR
**Creazione di una configurazione di sicurezza di Amazon EMR per Apache Ranger**
Prima di lanciare un cluster Amazon EMR integrato con Apache Ranger, crea una configurazione di sicurezza.
------
#### [ Console ]
**Per creare una configurazione di sicurezza che specifichi l'opzione di integrazione con Ranger AWS**
1. Nella console di Amazon EMR, seleziona **Security configurations (Configurazioni di sicurezza)** e in seguito **Create (Crea)**.
1. Digitare un nome in **Name (Nome)** per la configurazione di sicurezza. Questo nome è utilizzato per specificare la configurazione di sicurezza al momento della creazione di un cluster.
1. In **AWS Ranger Integration** (Integrazione Ranger), seleziona **Enable fine-grained access control managed by Apache Ranger** (Abilita controllo granulare degli accessi gestito da Apache Ranger).
1. Seleziona lo **IAM role for Apache Ranger (Ruolo IAM per Apache Ranger)** da applicare. Per ulteriori informazioni, consulta [Ruoli IAM per l'integrazione nativa con Apache Ranger](emr-ranger-iam.md).
1. Seleziona il **ruolo IAM per altri servizi AWS ** da applicare.
1. Configura i plugin per connetterti al server di amministrazione Ranger inserendo l'ARN di Secrets Manager per il server di amministrazione e l'indirizzo.
1. Seleziona le applicazioni per configurare i plug-in Ranger. Inserisci l'ARN di Secrets Manager che contiene il certificato TLS privato per il plug-in.
Se Apache Spark o Apache Hive non vengono configurati e vengono selezionati come applicazione per il cluster, la richiesta ha esito negativo.
1. Configurare altre opzioni per la configurazione di sicurezza come appropriato e scegliere **Create (Crea)**. È necessario abilitare l'autenticazione Kerberos utilizzando il KDC dedicato al cluster o esterno.
**Nota**
Al momento non è possibile utilizzare la console per creare una configurazione di sicurezza che specifichi l'opzione di integrazione AWS Ranger in. AWS GovCloud (US) Region La configurazione della sicurezza può essere eseguita utilizzando la CLI.
------
#### [ CLI ]
**Creazione di una configurazione di sicurezza per l'integrazione di Apache Ranger**
1. Sostituiscila `` con l'ID del tuo AWS account.
1. Sostituisci `` con la Regione in cui si trova la risorsa.
1. Specifica un valore per `TicketLifetimeInHours` per determinare il periodo di validità di un ticket Kerberos emesso dal KDC.
1. Specifica l'indirizzo del server Admin Ranger per `AdminServerURL`.
```
{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24
}
}
},
"AuthorizationConfiguration":{
"RangerConfiguration":{
"AdminServerURL":"https://__:6182",
"RoleForRangerPluginsARN":"arn:aws:iam::__:role/__",
"RoleForOtherAWSServicesARN":"arn:aws:iam::__:role/__",
"AdminServerSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"RangerPluginConfigurations":[
{
"App":"Spark",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Hive",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"EMRFS-S3",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Trino",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
}
],
"AuditConfiguration":{
"Destinations":{
"AmazonCloudWatchLogs":{
"CloudWatchLogGroup":"arn:aws:logs::__:log-group:__"
}
}
}
}
}
}
```
PolicyRespositoryNames Sono i nomi dei servizi specificati nell'amministratore di Apache Ranger.
Crea una configurazione di sicurezza Amazon EMR con il seguente comando. Sostituisci security-configuration con un nome a tua scelta. Seleziona questa configurazione per nome quando crei il cluster.
```
aws emr create-security-configuration \
--security-configuration file://./security-configuration.json \
--name security-configuration
```
------
**Configurazione di caratteristiche di sicurezza aggiuntive**
Per integrare Amazon EMR con Apache Ranger in modo sicuro, configura le seguenti caratteristiche di sicurezza di EMR:
+ Abilita l'autenticazione Kerberos utilizzando il KDC dedicato al cluster o esterno. Per istruzioni, consulta [Utilizzo di Kerberos per l'autenticazione con Amazon EMR](emr-kerberos.md).
+ (Facoltativo) Abilita la crittografia in transito o inattiva. Per ulteriori informazioni, consulta [Opzioni di crittografia per Amazon EMR](emr-data-encryption-options.md).
Per ulteriori informazioni, consulta [Sicurezza in Amazon EMR](emr-security.md).
# Archivia i certificati TLS in Gestione dei segreti AWS
I plug-in Ranger installati su un cluster Amazon EMR e il server Admin Ranger devono comunicare tramite TLS per garantire che i dati delle policy e le altre informazioni inviate non possano essere letti se vengono intercettati. EMR impone inoltre che i plug-in eseguano l'autenticazione al server Admin Ranger fornendo il proprio certificato TLS ed eseguendo l'autenticazione TLS bidirezionale. Questa configurazione richiedeva la creazione di quattro certificati: due coppie di certificati TLS privati e pubblici. Per istruzioni sull'installazione del certificato nel server Admin Ranger, consulta [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md). Per completare la configurazione, i plug-in Ranger installati nel cluster EMR necessitano di due certificati: il certificato TLS pubblico del server di amministrazione e il certificato privato che il plug-in utilizzerà per autenticarsi sul server Admin Ranger. Per fornire questi certificati TLS, devono essere presenti in Gestione dei segreti AWS e forniti in una configurazione di sicurezza EMR.
**Nota**
Si consiglia, per quanto non sia necessario, di creare una coppia di certificati per ciascuna delle applicazioni per limitare l'impatto in caso di compromissione di uno dei certificati del plug-in.
**Nota**
È necessario monitorare e ruotare i certificati prima della data di scadenza.
## Formato del certificato
L'importazione dei certificati su Gestione dei segreti AWS è la stessa indipendentemente dal fatto che si tratti del certificato del plug-in privato o del certificato di amministrazione Ranger pubblico. Prima di importare i certificati TLS, questi devono essere in formato PEM 509x.
Un esempio di certificato pubblico è nel formato:
```
-----BEGIN CERTIFICATE-----
...Certificate Body...
-----END CERTIFICATE-----
```
Un esempio di certificato privato è nel formato:
```
-----BEGIN PRIVATE KEY-----
...Private Certificate Body...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...Trust Certificate Body...
-----END CERTIFICATE-----
```
Anche il certificato privato deve contenere un certificato di affidabilità.
Puoi verificare che i certificati siano nel formato corretto eseguendo il seguente comando:
```
openssl x509 -in -text
```
## Importazione di un certificato in Gestione dei segreti AWS
Quando crei il tuo segreto nel Secrets Manager, seleziona **Other type of secrets** (Altro tipo di segreti) in **secret type** (Tipo di segreto) e incolla il certificato codificato PEM nel campo **Plaintext** (Testo normale).
![\[Importazione di un certificato in. Gestione dei segreti AWS\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-tls-cert-import.png)
# Avvia un cluster EMR con Apache Ranger
Prima di avviare un cluster Amazon EMR con Apache Ranger, assicurati che ogni componente soddisfi i seguenti requisiti minimi di versione:
+ Amazon EMR versione 5.32.0 o successive, o 6.3.0 o successive. Consigliamo di utilizzare la versione del rilascio di Amazon EMR più recente.
+ Server Admin Apache Ranger 2.x.
Completa questa procedura:
+ Installa Apache Ranger se non lo hai già fatto. Per ulteriori informazioni, consulta [Installazione di Apache Ranger 0.5.0](https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+0.5.0+Installation).
+ Assicurati che ci sia connettività di rete tra il tuo cluster Amazon EMR e il server Admin Apache Ranger. Per informazioni, consultare [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md).
+ Crea i ruoli IAM necessari. Per informazioni, consulta [Ruoli IAM per l'integrazione nativa con Apache Ranger](emr-ranger-iam.md).
+ Crea una configurazione di sicurezza EMR per l'installazione di Apache Ranger. Per ulteriori informazioni, consulta [Creazione di una configurazione di sicurezza EMR](emr-ranger-security-config.md).
# Configurazione dei cluster Amazon EMR abilitati da Zeppelin per Apache Ranger
L'argomento illustra come configurare [Apache Zeppelin](https://zeppelin.apache.org/) per un cluster Amazon EMR abilitato per Apache Ranger in modo da poter utilizzare Zeppelin come notebook per l'esplorazione interattiva dei dati. Zeppelin è incluso nel rilascio di Amazon EMR versione 5.0.0 e successive. Le versioni precedenti includono Zeppelin come applicazione sandbox. Per ulteriori informazioni, consulta [Versioni del rilascio 4.x di Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-4x.html) nella *Guida ai rilasci di Amazon EMR*.
Per impostazione predefinita, Zeppelin è configurato con un log-in e una password di default che non sono sicuri in un ambiente multi-tenant.
Per configurare Zeppelin, completa la procedura riportata di seguito.
1. **Modifica del meccanismo di autenticazione**.
Modifica del file `shiro.ini` per implementare il meccanismo di autenticazione preferito. Zeppelin supporta Active Directory, LDAP, PAM e Knox SSO. Consulta [Autenticazione Apache Shiro per Apache Zeppelin](https://zeppelin.apache.org/docs/0.8.2/setup/security/shiro_authentication.html) per ulteriori informazioni.
1. **Configurazione di Zeppelin per rappresentare l'utente finale**
Consentire a Zeppelin di rappresentare l'utente finale fa sì che i processi inviati da Zeppelin vengano eseguiti come utente finale. Aggiungi la seguente configurazione a `core-site.xml`:
```
[
{
"Classification": "core-site",
"Properties": {
"hadoop.proxyuser.zeppelin.hosts": "*",
"hadoop.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Quindi, aggiungi la seguente configurazione a `hadoop-kms-site.xml` in `/etc/hadoop/conf`:
```
[
{
"Classification": "hadoop-kms-site",
"Properties": {
"hadoop.kms.proxyuser.zeppelin.hosts": "*",
"hadoop.kms.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Puoi anche aggiungere queste configurazioni al tuo cluster Amazon EMR tramite la console seguendo la procedura descritta in [Riconfigurazione di un gruppo di istanze nella console](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html#emr-configure-apps-running-cluster-console).
1. **Consenti a Zeppelin di eseguire il comando sudo come utente finale**
Crea un file `/etc/sudoers.d/90-zeppelin-user` che contenga quanto segue:
```
zeppelin ALL=(ALL) NOPASSWD:ALL
```
1. **Modifica le impostazioni degli interpreti per eseguire i processi degli utenti nei propri processi**.
Per tutti gli interpreti, configurali per creare un'istanza degli interpreti "per user" (per utente) nei processi "isolated" (isolati).
![\[Diagramma dell'architettura Amazon EMR e Apache Ranger.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/per_user.png)
1. **Modifica `zeppelin-env.sh`**
Aggiungi quanto segue a `zeppelin-env.sh` in modo che Zeppelin inizi ad avviare interpreti come utente finale:
```
ZEPPELIN_IMPERSONATE_USER=`echo ${ZEPPELIN_IMPERSONATE_USER} | cut -d @ -f1`
export ZEPPELIN_IMPERSONATE_CMD='sudo -H -u ${ZEPPELIN_IMPERSONATE_USER} bash -c'
```
Aggiungi quanto segue a `zeppelin-env.sh` per modificare le autorizzazioni predefinite del notebook in sola lettura solo per l'autore:
```
export ZEPPELIN_NOTEBOOK_PUBLIC="false"
```
Infine, aggiungete quanto segue `zeppelin-env.sh` per includere il percorso della RecordServer classe EMR dopo la prima `CLASSPATH` istruzione:
```
export CLASSPATH="$CLASSPATH:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-connector-common.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-spark-connector.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-client.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-common.jar:/usr/share/aws/emr/record-server/lib/jars/secret-agent-interface.jar"
```
1. **Riavvia Zeppelin.**
Per riavviare Zeppelin, esegui il comando seguente:
```
sudo systemctl restart zeppelin
```
# Problemi noti per l'integrazione con Amazon EMR
**Problemi noti**
C'è un problema noto all'interno del rilascio di Amazon EMR 5.32 in cui le autorizzazioni per `hive-site.xml` sono state modificate in modo che solo gli utenti privilegiati possano leggerlo, in quanto potrebbero esserci credenziali memorizzate al suo interno. Ciò potrebbe impedire a Hue di leggere `hive-site.xml` e fare in modo che le pagine Web vengano ricaricate continuamente. Se si verificano problemi, aggiungi la seguente configurazione per risolvere il problema:
```
[
{
"Classification": "hue-ini",
"Properties": {},
"Configurations": [
{
"Classification": "desktop",
"Properties": {
"server_group":"hive_site_reader"
},
"Configurations":[
]
}
]
}
]
```
Sussiste un problema noto per cui il plug-in EMRFS S3 per Apache Ranger attualmente non supporta la caratteristica Security Zone di Apache Ranger. Le restrizioni per il controllo degli accessi definite utilizzando la funzione Security Zone non vengono applicate ai cluster Amazon EMR.
**Applicazione UIs**
Per impostazione predefinita, l'interfaccia utente di un'applicazione non esegue l'autenticazione. Ciò include l'ResourceManager interfaccia utente, l'interfaccia NodeManager utente, l'interfaccia utente Livy, tra gli altri. Inoltre, qualsiasi utente che abbia la possibilità di accedere a UIs è in grado di visualizzare le informazioni sui lavori di tutti gli altri utenti.
Se questo comportamento non è desiderato, è necessario assicurarsi che venga utilizzato un gruppo di sicurezza per limitare l'accesso all'applicazione UIs da parte degli utenti.
**Autorizzazioni HDFS predefinite**
Per impostazione predefinita, agli oggetti creati dagli utenti in HDFS vengono concesse autorizzazioni leggibili a livello mondiale. Ciò può tradursi nella leggibilità dei dati da parte degli utenti che non dovrebbero avervi accesso. Per modificare questo comportamento in modo che le autorizzazioni predefinite dei file siano impostate per la lettura e la scrittura solo dall'autore del processo, esegui questa procedura.
Quando si crea il cluster EMR, fornisci la seguente configurazione:
```
[
{
"Classification": "hdfs-site",
"Properties": {
"dfs.namenode.acls.enabled": "true",
"fs.permissions.umask-mode": "077",
"dfs.permissions.superusergroup": "hdfsadmingroup"
}
}
]
```
Inoltre, esegui la seguente operazione di bootstrap:
```
--bootstrap-actions Name='HDFS UMask Setup',Path=s3://elasticmapreduce/hdfs/umask/umask-main.sh
```
# Plugin Apache Ranger per scenari di integrazione Amazon EMR
I plug-in Apache Ranger convalidano l'accesso di un utente rispetto alle policy di autorizzazione definite nel server amministratore delle policy di Apache Ranger.
**Topics**
+ [Plugin Apache Hive per l'integrazione di Ranger con Amazon EMR](emr-ranger-hive.md)
+ [Plugin Apache Spark per l'integrazione di Ranger con Amazon EMR](emr-ranger-spark.md)
+ [Plugin EMRFS S3 per l'integrazione di Ranger con Amazon EMR](emr-ranger-emrfs.md)
+ [Plugin Trino per l'integrazione di Ranger con Amazon EMR](emr-ranger-trino.md)
# Plugin Apache Hive per l'integrazione di Ranger con Amazon EMR
Apache Hive è un motore di esecuzione popolare all'interno dell'ecosistema Hadoop. Amazon EMR fornisce un plug-in Apache Ranger per essere in grado di fornire controlli di accesso granulare per Hive. Il plug-in è compatibile con il server open source Apache Ranger Admin versione 2.0 e successive.
**Topics**
+ [Funzionalità supportate](#emr-ranger-supported-features)
+ [Installazione della configurazione del servizio](#emr-ranger-hive-service-config)
+ [Considerazioni](#emr-ranger-hive-considerations)
+ [Limitazioni](#emr-ranger-hive-limitations)
## Funzionalità supportate
Il plug-in Apache Ranger per Hive su EMR supporta tutte le funzionalità del plug-in open source, che include database, tabella, controlli di accesso a livello di colonna, filtraggio riga e mascheramento dei dati. Per una tabella dei comandi Hive e delle autorizzazioni Ranger associate, consulta [Comandi Hive per la mappatura delle autorizzazioni Ranger](https://cwiki.apache.org/confluence/display/RANGER/Hive+Commands+to+Ranger+Permission+Mapping).
## Installazione della configurazione del servizio
Il plugin Apache Hive è compatibile con la definizione del servizio Hive esistente all'interno di Apache Hive Hadoop SQL.
![\[Definizione del servizio Apache Hive per Hadoop SQL.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger_service_mgr.png)
Se non disponi di un'istanza del servizio in Hadoop SQL, come mostrato sopra, puoi crearne una. Fai clic sul pulsante **\$1** accanto ad Hadoop SQL.
1. **Nome del servizio (se visualizzato)**: immetti il nome del servizio. Il valore suggerito è **amazonemrhive**. Prendi nota di questo nome del servizio: è necessario quando si crea una configurazione di sicurezza EMR.
1. **Nome visualizzato**: immetti il nome da visualizzare per il servizio. Il valore suggerito è **amazonemrhive**.
![\[Dettagli del servizio Apache Hive per Hadoop SQL.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger_create_service.png)
Le proprietà di configurazione di Apache Hive vengono utilizzate per stabilire una connessione al server di amministrazione Apache Ranger con un 2 per HiveServer implementare il completamento automatico durante la creazione delle politiche. Non è necessario che le proprietà seguenti siano accurate se non si dispone di un processo HiveServer 2 persistente e possono essere compilate con qualsiasi informazione.
+ **Nome utente**: inserisci un nome utente per la connessione JDBC a un'istanza di un'istanza HiveServer 2.
+ **Password**: inserisci la password per il nome utente sopra.
+ **jdbc.driver. ClassName**: Immettere il nome della classe JDBC per la connettività Apache Hive. Puoi utilizzare il valore predefinito.
+ **jdbc.url**: Immettere la stringa di connessione JDBC da utilizzare per la connessione a 2. HiveServer
+ **Nome comune per certificato**: il campo CN all'interno del certificato utilizzato per connettersi al server Admin da un plug-in client. Questo valore deve corrispondere al campo CN nel certificato TLS creato per il plug-in.
![\[Proprietà di configurazione del servizio Apache Hive.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger_config_props.png)
Il pulsante **Test Connection** verifica se i valori sopra riportati possono essere utilizzati per connettersi correttamente all'istanza 2. HiveServer Una volta che il servizio è stato creato correttamente, il Service Manager dovrebbe avere il seguente aspetto:
![\[Connesso all'istanza HiveServer 2\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger_config_connected.png)
## Considerazioni
**Server dei metadati Hive**
Il server dei metadati Hive è accessibile solo dai motori attendibili, in particolare Hive e `emr_record_server`, come misura di protezione da accessi non autorizzati. Il server dei metadati Hive è accessibile anche da tutti i nodi del cluster. La porta 9083 richiesta consente a tutti i nodi di accedere al nodo principale.
**Autenticazione**
Per impostazione predefinita, Apache Hive è configurato per l'autenticazione tramite Kerberos come configurato nella configurazione di sicurezza EMR. HiveServer2 può essere configurato per autenticare gli utenti anche tramite LDAP. Consulta [Implementazione dell'autenticazione LDAP per Hive su un cluster Amazon EMR multi-tenant](https://aws.amazon.com/blogs/big-data/implementing-ldap-authentication-for-hive-on-a-multi-tenant-amazon-emr-cluster/) per maggiori informazioni.
## Limitazioni
Di seguito sono riportate le attuali limitazioni per il plug-in Apache Hive su Amazon EMR 5.x:
+ I ruoli Hive non sono attualmente supportati. Le istruzioni Grant (Concedi) e Revoke (Revoca) non sono supportate.
+ L'interfaccia CLI di Hive non è supportata. JDBC/Beeline è l'unico modo autorizzato per connettere Hive.
+ `hive.server2.builtin.udf.blacklist`la configurazione deve essere compilata con UDFs ciò che ritieni non sicuro.
# Plugin Apache Spark per l'integrazione di Ranger con Amazon EMR
Amazon EMR ha integrato EMR per fornire un controllo granulare degli RecordServer accessi per SparkSQL. EMR RecordServer è un processo privilegiato in esecuzione su tutti i nodi di un cluster abilitato per Apache Ranger. Quando un driver o un executor Spark esegue un'istruzione SparkSQL, tutte le richieste di metadati e dati passano attraverso. RecordServer Per ulteriori informazioni su EMR RecordServer, consulta la [Componenti Amazon EMR da utilizzare con Apache Ranger](emr-ranger-components.md) pagina.
**Topics**
+ [Funzionalità supportate](#emr-ranger-spark-supported-features)
+ [Ridistribuire la definizione del servizio per utilizzare le istruzioni INSERT, ALTER o DDL](#emr-ranger-spark-redeploy-service-definition)
+ [Installazione della definizione del servizio](#emr-ranger-spark-install-servicedef)
+ [Creazione di policy SparkSQL](#emr-ranger-spark-create-sparksql)
+ [Considerazioni](#emr-ranger-spark-considerations)
+ [Limitazioni](#emr-ranger-spark-limitations)
## Funzionalità supportate
| Azione SQL statement/Ranger | STATUS | Rilascio di EMR supportato |
| --- | --- | --- |
| SELECT | Supportata | A partire da 5.32 |
| SHOW DATABASES | Supportata | A partire da 5.32 |
| SHOW COLUMNS | Supportata | A partire da 5.32 |
| SHOW TABLES | Supportata | A partire da 5.32 |
| SHOW TABLE PROPERTIES (MOSTRA PROPRIETÀ TABELLA) | Supportata | A partire da 5.32 |
| DESCRIBE TABLE | Supportata | A partire da 5.32 |
| INSERT OVERWRITE | Supportata | A partire da 5.34 e 6.4 |
| INSERT INTO | Supportata | A partire da 5.34 e 6.4 |
| ALTER TABLE | Supportata | A partire da 6.4 |
| CREATE TABLE | Supportata | A partire da 5.35 e 6.7 |
| CREATE DATABASE | Supportata | A partire da 5.35 e 6.7 |
| DROP TABLE | Supportata | A partire da 5.35 e 6.7 |
| DROP DATABASE | Supportata | A partire da 5.35 e 6.7 |
| DROP VIEW | Supportata | A partire da 5.35 e 6.7 |
| CREATE VIEW | Non supportato | |
Quando si utilizza SparkSQL sono supportate le seguenti caratteristiche:
+ Controllo granulare degli accessi sulle tabelle all'interno del metastore Hive; le policy possono essere create a livello di database, tabella e colonna.
+ Le policy di Apache Ranger possono includere policy di concessione e di negazione a utenti e gruppi.
+ Gli eventi di controllo vengono inviati ai CloudWatch registri.
## Ridistribuire la definizione del servizio per utilizzare le istruzioni INSERT, ALTER o DDL
**Nota**
A partire da Amazon EMR 6.4, puoi utilizzare Spark SQL con le istruzioni: INSERT INTO, INSERT OVERWRITE o ALTER TABLE. A partire da Amazon EMR 6.7, puoi utilizzare Spark SQL per creare o rimuovere database e tabelle. Se si dispone di un'installazione esistente sul server Apache Ranger con le definizioni del servizio Apache Spark implementate, utilizzare il codice seguente per ridistribuire le definizioni del servizio.
```
# Get existing Spark service definition id calling Ranger REST API and JSON processor
curl --silent -f -u : \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/name/amazon-emr-spark' | jq .id
# Download the latest Service definition
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
# Update the service definition using the Ranger REST API
curl -u : -X PUT -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/'
```
## Installazione della definizione del servizio
L'installazione della definizione del servizio Apache Spark di EMR richiede l'installazione del server Admin Ranger. Per informazioni, consulta [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md).
Segui queste fasi per installare la definizione del servizio Apache Spark:
**Fase 1: SSH nel server Admin Apache Ranger**.
Ad esempio:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Fase 2: Download della definizione del servizio e del plug-in del server Admin Apache Ranger**
In una directory temporanea, scarica la definizione del servizio. Questa definizione del servizio è supportata dalle versioni Ranger 2.x.
```
mkdir /tmp/emr-spark-plugin/
cd /tmp/emr-spark-plugin/
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-spark-plugin-2.x.jar
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
```
**Fase 3: Installazione del plug-in Apache Spark per Amazon EMR**
```
export RANGER_HOME=.. # Replace this Ranger Admin's home directory eg /usr/lib/ranger/ranger-2.0.0-admin
mkdir $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
mv ranger-spark-plugin-2.x.jar $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
```
**Fase 4: Registrazione della definizione del servizio Apache Spark per Amazon EMR**
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se questo comando viene eseguito correttamente, viene visualizzato un nuovo servizio nell'interfaccia utente del server Admin Ranger denominato "AMAZON-EMR-SPARK", come mostrato nell'immagine seguente (Ranger versione 2.0).
![\["AMAZON-EMR-SPARK" registrato nell'Admin Ranger.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark.png)
**Fase 5: Creare un'istanza dell'applicazione AMAZON-EMR-SPARK**
**Nome del servizio (se visualizzato):** il nome del servizio che verrà utilizzato. Il valore suggerito è **amazonemrspark**. Prendi nota di questo nome del servizio dal momento che sarà necessario quando crei una configurazione di sicurezza EMR.
**Nome visualizzato:** il nome da visualizzare per questa istanza. Il valore suggerito è **amazonemrspark**.
**Nome comune per certificato**: il campo CN all'interno del certificato utilizzato per connettersi al server Admin da un plug-in client. Questo valore deve corrispondere al campo CN nel certificato TLS creato per il plug-in.
![\[Il server Admin Ranger crea il servizio.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-service.png)
**Nota**
Il certificato TLS per questo plug-in dovrebbe essere stato registrato nel truststore sul server Admin Ranger. Per ulteriori dettagli, consulta [Certificati TLS per l'integrazione di Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md).
## Creazione di policy SparkSQL
Quando si crea una nuova policy, i campi da compilare sono i seguenti:
**Nome policy**: il nome della policy.
**Etichetta policy**: un'etichetta che è possibile inserire in questa policy.
**Database**: il database a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutti i database.
**Tabella**: le tabelle a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutte le tabelle.
**Colonna Spark EMR**: le colonne a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutte le colonne.
**Description (Descrizione)**: la descrizione di questa policy.
![\[Il server Admin Ranger crea i dettagli della policy di SparkSQL.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-policy-details.png)
Per specificare gli utenti e i gruppi, immetti gli utenti e i gruppi riportati di seguito per concedere le autorizzazioni. È inoltre possibile specificare delle esclusioni per **consentire** e **negare** le condizioni.
![\[I dettagli della policy SparkSQL del server Admin Ranger consentono le condizioni.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions.png)
Dopo aver specificato le condizioni di autorizzazione e negazione, fai clic su **Save (Salva)**.
## Considerazioni
Ogni nodo all'interno del cluster EMR deve essere in grado di connettersi al nodo principale sulla porta 9083.
## Limitazioni
Di seguito sono riportate le attuali limitazioni per il plug-in Apache Spark:
+ Record Server si connette sempre ad HMS in esecuzione su un cluster Amazon EMR. Configura HMS per la connessione alla modalità remota, se necessario. Non inserire i valori di configurazione all'interno del file di configurazione Hive-site.xml di Apache Spark.
+ Le tabelle create utilizzando le origini dati Spark su CSV o Avro non sono leggibili utilizzando EMR. RecordServer Utilizza Hive per creare e scrivere dati, per poi leggerli utilizzando Record.
+ Le tabelle Delta Lake, Hudi e Iceberg non sono supportate.
+ Gli utenti devono avere accesso al database predefinito. Questo è un requisito per Apache Spark.
+ Il server Admin Ranger non supporta il completamento automatico.
+ Il plug-in SparkSQL per Amazon EMR non supporta i filtri di riga o il mascheramento dei dati.
+ Quando si utilizza ALTER TABLE con Spark SQL, una posizione di partizione deve essere la directory figlio di una posizione di tabella. L'inserimento di dati in una partizione in cui la posizione della partizione è diversa da quella della tabella non è supportata.
# Plugin EMRFS S3 per l'integrazione di Ranger con Amazon EMR
Per semplificare la fornitura di controlli degli accessi agli oggetti in S3 in un cluster multi-tenant, il plug-in EMRFS S3 fornisce controlli degli accessi ai dati all'interno di S3 quando vi si accede tramite EMRFS. È possibile consentire l'accesso alle risorse S3 a livello di utente e gruppo.
Per raggiungere questo obiettivo, quando l'applicazione tenta di accedere ai dati all'interno di S3, EMRFS invia una richiesta di credenziali al processo Secret Agent, in cui la richiesta viene autenticata e autorizzata rispetto a un plug-in Apache Ranger. Se la richiesta è autorizzata, l'agente segreto assume il ruolo IAM per Apache Ranger Engines con una policy limitata per generare credenziali che hanno accesso solo alla policy Ranger che ha consentito l'accesso. Le credenziali vengono quindi passate a EMRFS per accedere a S3.
**Topics**
+ [Funzionalità supportate](#emr-ranger-emrfs-features)
+ [Installazione della configurazione del servizio](#emr-ranger-emrfs-service-config)
+ [Creazione di policy EMRFS S3](#emr-ranger-emrfs-create-policies)
+ [Note sull'utilizzo delle policy EMRFS S3](#emr-ranger-emrfs-considerations)
+ [Limitazioni](#emr-ranger-emrfs-limitations)
## Funzionalità supportate
Il plug-in EMRFS S3 fornisce l'autorizzazione a livello di archiviazione. È possibile creare policy che consentano l'accesso di utenti e gruppi a bucket e prefissi S3. L'autorizzazione è gestita solo rispetto a EMRFS.
## Installazione della configurazione del servizio
Per installare la definizione del servizio EMRFS, devi configurare il server di amministrazione Ranger. Per configurare il server, vedere. [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md)
Attenersi alla seguente procedura per installare la definizione del servizio EMRFS.
**Fase 1: SSH nel server Admin Apache Ranger**.
Esempio:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Fase 2: Scarica la definizione del servizio EMRFS**.
In una directory temporanea, scarica la definizione del servizio Amazon EMR. Questa definizione del servizio è supportata dalle versioni Ranger 2.x.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json
```
**Fase 3: Registrare la definizione del servizio EMRFS S3**.
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se questo comando viene eseguito correttamente, viene visualizzato un nuovo servizio nell'interfaccia utente del server Admin Ranger denominato "AMAZON-EMR-S3", come mostrato nell'immagine seguente (Ranger versione 2.0).
![\[Il server Admin Ranger crea il servizio EMRFS S3.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png)
**Fase 4: Creare un'istanza dell'applicazione. AMAZON-EMR-EMRFS**
Crea un'istanza della definizione del servizio.
+ Fai clic sul **segno \$1** accanto a AMAZON-EMR-EMRFS.
Riempi i seguenti campi:
**Nome del servizio (se visualizzato)**: il valore suggerito è**amazonemrs3**. Prendi nota di questo nome del servizio dal momento che sarà necessario quando crei una configurazione di sicurezza EMR.
**Nome visualizzato**: immetti il nome da visualizzare per il servizio. Il valore suggerito è **amazonemrs3**.
**Nome comune per certificato**: il campo CN all'interno del certificato utilizzato per connettersi al server Admin da un plug-in client. Questo valore deve corrispondere al campo CN nel certificato TLS creato per il plug-in.
![\[Il server Admin Ranger modifica il servizio EMRFS S3.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png)
**Nota**
Il certificato TLS per questo plug-in dovrebbe essere stato registrato nel truststore sul server Admin Ranger. Per ulteriori dettagli, consulta [Certificati TLS per l'integrazione di Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md).
Quando viene creato il servizio, il Service Manager include "AMAZON-EMR-EMRFS", come mostrato nell'immagine seguente.
![\[Il server Admin Ranger mostra il nuovo servizio EMRFS S3.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png)
## Creazione di policy EMRFS S3
Per creare una nuova policy, nella pagina **Create Policy** (Crea policy) del Service Manager compila i campi riportati di seguito.
**Nome policy**: il nome della policy.
**Etichetta policy**: un'etichetta che è possibile inserire in questa policy.
**Risorsa S3**: una risorsa che inizia con il bucket e il prefisso facoltativo. Per ulteriori informazioni sulle best practice, consulta [Note sull'utilizzo delle policy EMRFS S3](#emr-ranger-emrfs-considerations). Le risorse nel server Admin Ranger non devono contenere **s3://**, **s3a://** o **s3n://**.
![\[Il server Admin Ranger crea la policy per il servizio EMRFS S3.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png)
È possibile specificare utenti e gruppi per concedere le autorizzazioni. È inoltre possibile specificare delle esclusioni per **consentire** e **negare** le condizioni.
![\[Ranger Admin mostra user/group le autorizzazioni per la politica EMRFS S3.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png)
**Nota**
Sono consentite al massimo tre risorse per ogni policy. L'aggiunta di più di tre risorse può causare un errore quando questa policy viene utilizzata in un cluster EMR. L'aggiunta di più di tre policy consente di visualizzare un promemoria relativo al limite di policy.
## Note sull'utilizzo delle policy EMRFS S3
Quando si creano policy S3 all'interno di Apache Ranger, occorre tenere a mente alcune considerazioni sull'utilizzo.
### Autorizzazioni a più oggetti S3
È possibile utilizzare policy ricorrenti ed espressioni con caratteri jolly per concedere autorizzazioni a più oggetti S3 con prefissi comuni. Le policy ricorrenti forniscono autorizzazioni a tutti gli oggetti con un prefisso comune. Le espressioni con caratteri jolly selezionano più prefissi. Insieme, forniscono le autorizzazioni a tutti gli oggetti con più prefissi comuni, come mostrato nei seguenti esempi.
**Example Utilizzo di una policy ricorrente**
Supponiamo che necessiti di autorizzazioni per elencare tutti i file parquet in un bucket S3 organizzato come segue.
```
s3://sales-reports/americas/
+- year=2000
| +- data-q1.parquet
| +- data-q2.parquet
+- year=2019
| +- data-q1.json
| +- data-q2.json
| +- data-q3.json
| +- data-q4.json
|
+- year=2020
| +- data-q1.parquet
| +- data-q2.parquet
| +- data-q3.parquet
| +- data-q4.parquet
| +- annual-summary.parquet
+- year=2021
```
Innanzitutto, considera i file parquet con il prefisso `s3://sales-reports/americas/year=2000`. Puoi concedere GetObject le autorizzazioni a tutti in due modi:
**Utilizzo di policy non ricorrenti**: un'opzione consiste nell'utilizzare due policy non ricorrenti separate, una per la directory e l'altra per i file.
La prima policy concede l'autorizzazione al prefisso `s3://sales-reports/americas/year=2020` (non è presente il `/` finale).
```
- S3 resource = "sales-reports/americas/year=2000"
- permission = "GetObject"
- user = "analyst"
```
La seconda policy utilizza l'espressione jolly per concedere autorizzazioni a tutti i file con prefisso `sales-reports/americas/year=2020/` (nota il `/` finale).
```
- S3 resource = "sales-reports/americas/year=2020/*"
- permission = "GetObject"
- user = "analyst"
```
**Utilizzo di una policy ricorrente**: un'alternativa più conveniente consiste nell'utilizzare una singola policy ricorrente e concedere l'autorizzazione ricorrente al prefisso.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
Finora, solo i file parquet con il prefisso `s3://sales-reports/americas/year=2000` sono stati inclusi. È ora possibile includere anche i file parquet con un prefisso diverso, `s3://sales-reports/americas/year=2020`, nella stessa policy ricorrente introducendo un'espressione con caratteri jolly come segue.
```
- S3 resource = "sales-reports/americas/year=20?0"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Politiche PutObject e DeleteObject autorizzazioni
La scrittura di politiche `PutObject` e `DeleteObject` autorizzazioni per i file su EMRFS richiede un'attenzione speciale perché, a differenza delle autorizzazioni, richiedono GetObject autorizzazioni ricorsive aggiuntive concesse al prefisso.
**Example Politiche PutObject DeleteObject e autorizzazioni**
Ad esempio, l'eliminazione del file non `annual-summary.parquet` richiede solo l' DeleteObject autorizzazione per il file effettivo.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "DeleteObject"
- user = "analyst"
```
ma anche una policy che conceda autorizzazioni ricorrenti `GetObject` e `PutObject` per il suo prefisso.
Allo stesso modo, la modifica del file `annual-summary.parquet` richiede non solo un'autorizzazione `PutObject` per il file effettivo,
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "PutObject"
- user = "analyst"
```
ma anche una policy che conceda l'autorizzazione ricorrente `GetObject` per il suo prefisso.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Caratteri jolly nelle policy
Sono disponibili due aree in cui è possibile specificare i caratteri jolly. Quando si specifica una risorsa S3, è possibile utilizzare i valori "\$1" e "?". "\$1" fornisce la corrispondenza con un percorso S3 e corrisponde a tutto ciò che viene dopo il prefisso. Per esempio, la seguente policy.
```
S3 resource = "sales-reports/americas/*"
```
Questo corrisponde ai seguenti percorsi S3.
```
sales-reports/americas/year=2020/
sales-reports/americas/year=2019/
sales-reports/americas/year=2019/month=12/day=1/afile.parquet
sales-reports/americas/year=2018/month=6/day=1/afile.parquet
sales-reports/americas/year=2017/afile.parquet
```
Il carattere jolly "?" corrisponde a un singolo carattere. Ad esempio, per la policy:
```
S3 resource = "sales-reports/americas/year=201?/"
```
Questo corrisponde ai seguenti percorsi S3.
```
sales-reports/americas/year=2019/
sales-reports/americas/year=2018/
sales-reports/americas/year=2017/
```
### Caratteri jolly negli utenti
Esistono due caratteri jolly incorporati quando si assegnano utenti per consentire l'accesso agli utenti. Il primo è il carattere jolly "\$1USER\$1" che fornisce l'accesso a tutti gli utenti. Il secondo carattere jolly è "\$1OWNER\$1" che fornisce l'accesso diretto o l'accesso al proprietario di un particolare oggetto. Tuttavia, il carattere jolly "\$1USER\$1" non è attualmente supportato.
## Limitazioni
Di seguito sono riportate le attuali limitazioni per il plug-in EMRFS S3:
+ Apache Ranger può avere al massimo tre policy.
+ L'accesso a S3 deve essere realizzato tramite EMRFS e può essere utilizzato con le applicazioni correlate ad Hadoop. Il seguente elemento non è supportato:
- Librerie Boto3
- AWS SDK e AWK CLI
- Connettore open source S3A
+ Le policy di negazione di Apache Ranger non sono supportate.
+ Le operazioni su S3 con chiavi con crittografia CSE-KMS non sono attualmente supportate.
+ Il supporto tra Regioni non è supportato.
+ La caratteristica Security Zone di Apache Ranger non è supportata. Le restrizioni per il controllo degli accessi definite utilizzando la funzione Security Zone non vengono applicate ai cluster Amazon EMR.
+ L'utente Hadoop non genera eventi di verifica poiché Hadoop accede sempre al profilo dell'istanza EC2.
+ Si consiglia di disabilitare la visualizzazione di coerenza Amazon EMR. S3 ha un'elevata coerenza, pertanto tale visualizzazione non è più necessaria. Per maggiori informazioni, consulta [Forte coerenza di Amazon S3](https://aws.amazon.com/s3/consistency/).
+ Il plug-in EMRFS S3 effettua numerose chiamate STS. Si consiglia di eseguire test di carico su un account di sviluppo e monitorare il volume delle chiamate STS. Si consiglia inoltre di effettuare una richiesta STS per aumentare AssumeRole i limiti del servizio.
+ Il server Ranger Admin non supporta il completamento automatico.
# Plugin Trino per l'integrazione di Ranger con Amazon EMR
Trino (precedentemente PrestoSQL) è un motore di query SQL che consente di eseguire query su più origini dati, come HDFS, archiviazione di oggetti, database relazionali e database NoSQL. Elimina la necessità di migrare i dati in una posizione centrale e consente di interrogare i dati ovunque si trovino. Amazon EMR mette a disposizione un plugin Apache Ranger per fornire un controllo granulare degli accessi a Trino. Il plug-in è compatibile con il server open source Apache Ranger Admin versione 2.0 e successive.
**Topics**
+ [Funzionalità supportate](#emr-ranger-trino-features)
+ [Installazione della configurazione del servizio](#emr-ranger-trino-service-config)
+ [Creazione di policy Trino](#emr-ranger-trino-create-policies)
+ [Considerazioni](#emr-ranger-trino-considerations)
+ [Limitazioni](#emr-ranger-trino-limitations)
## Funzionalità supportate
Il plugin Apache Ranger per Trino su Amazon EMR supporta tutte le funzionalità del motore di query Trino, che è protetto da un controllo granulare degli accessi comprendente controlli degli accessi a livello di database, tabella e colonna, filtraggio di riga e mascheramento dei dati. Le policy di Apache Ranger possono includere policy di concessione e di negazione a utenti e gruppi. Gli eventi di controllo vengono inoltre inviati ai log. CloudWatch
## Installazione della configurazione del servizio
L'installazione della definizione del servizio Trino richiede la configurazione del server Admin Ranger. Per configurare il server Admin Ranger, consulta [Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR](emr-ranger-admin.md).
Attenersi alla seguente procedura per installare la definizione del servizio Trino.
1. SSH nel server Admin Apache Ranger.
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
1. Disinstalla il plugin del server Presto, se presente. Eseguire il seguente comando seguente. Se viene visualizzato l'errore "Service not found" (Servizio non trovato), il plugin del server Presto non è stato installato sul server. Passare alla fase successiva.
```
curl -f -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X DELETE -k 'https://**:6182/service/public/v2/api/servicedef/name/presto'
```
1. Scarica la definizione del servizio e il plugin del server Admin Apache Ranger. In una directory temporanea, scarica la definizione del servizio. Questa definizione del servizio è supportata dalle versioni Ranger 2.x.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-trino.json
```
1. Registra la definizione del servizio Apache Trino per Amazon EMR.
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-trino.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se questo comando viene eseguito correttamente, viene visualizzato un nuovo servizio nell'interfaccia utente di Admin Apache Ranger denominato `TRINO`, come mostrato nell'immagine seguente.
![\[Il server Admin Ranger crea il servizio.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-service-trino.png)
1. Crea un'istanza dell'applicazione `TRINO` inserendo le informazioni seguenti.
**Service Name** (Nome del servizio): il nome del servizio che verrà utilizzato. Il valore suggerito è `amazonemrtrino`. Prendi nota di questo nome del servizio dal momento che sarà necessario durante la creazione di una configurazione di sicurezza per Amazon EMR.
**Nome visualizzato:** il nome da visualizzare per questa istanza. Il valore suggerito è `amazonemrtrino`.
![\[Nome visualizzato per il server Admin Ranger.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-display-name-trino.png)
**jdbc.driver. ClassName**: Il nome della classe JDBC per la connettività Trino. Puoi usare il valore predefinito.
**jdbc.url**: la stringa di connessione JDBC da utilizzare per la connessione a un coordinatore Trino.
**Nome comune per certificato**: il campo CN all'interno del certificato utilizzato per connettersi al server Admin da un plug-in client. Questo valore deve corrispondere al campo CN nel certificato TLS creato per il plug-in.
![\[Nome comune per il server Admin Ranger.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-common-name-trino.png)
Il certificato TLS per questo plugin dovrebbe essere stato registrato nel trust store sul server Admin Ranger. Per ulteriori informazioni, consulta la sezione [Certificati TLS](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-admin-tls.html).
## Creazione di policy Trino
Quando crei una nuova policy, compila i campi seguenti.
**Nome policy**: il nome della policy.
**Etichetta policy**: un'etichetta che è possibile inserire in questa policy.
**Catalog** (Catalogo): il catalogo a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutti i cataloghi.
**Schema** (Schema): gli schemi a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutti gli schemi.
**Tabella**: le tabelle a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutte le tabelle.
**Column** (Colonna): le colonne a cui viene applicata questa policy. Il carattere jolly "\$1" rappresenta tutte le colonne.
**Description (Descrizione)**: la descrizione di questa policy.
Esistono altri tipi di policy, ad esempio **Trino User** (Utente Trino) (per l'accesso alla rappresentazione di utenti), **Trino System/Session Property** (Proprietà sistema/sessione Trino) (per modificare le proprietà del sistema o della sessione del motore), **Functions/Procedures** (Funzioni/procedure) (per consentire chiamate a funzioni o procedure) e **URL** (per consentire l'accesso in lettura/scrittura al motore nei percorsi dati).
![\[Il server Admin Ranger crea i dettagli della policy.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-policy-details-trino.png)
Per concedere autorizzazioni a utenti e gruppi specifici, inserirli. È inoltre possibile specificare delle esclusioni per **consentire** e **negare** le condizioni.
![\[I dettagli della policy del server Admin Ranger consentono di negare le condizioni.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions-trino.png)
Dopo aver specificato le condizioni di autorizzazione e negazione, scegli **Save** (Salva).
## Considerazioni
Quando si creano policy Trino all'interno di Apache Ranger, occorre tenere a mente alcune considerazioni sull'utilizzo.
**Server dei metadati Hive**
Il server dei metadati Hive è accessibile solo dai motori attendibili, in particolare il motore Trino, come misura di protezione da accessi non autorizzati. Il server dei metadati Hive è accessibile anche da tutti i nodi del cluster. La porta 9083 richiesta consente a tutti i nodi di accedere al nodo principale.
**Autenticazione**
Per impostazione predefinita, Trino è configurato per l'autenticazione utilizzando Kerberos, come specificato nella configurazione di sicurezza di Amazon EMR.
**Crittografia in transito obbligatoria**
Il plugin Trino richiede che la crittografia in transito sia abilitata nella configurazione di sicurezza di Amazon EMR. Per abilitare la crittografia, consulta [Crittografia dei dati in transito](emr-data-encryption-options.md#emr-encryption-intransit).
## Limitazioni
Di seguito sono riportate le attuali limitazioni per il plugin Trino:
+ Il server Admin Ranger non supporta il completamento automatico.
# Risoluzione dei problemi di Apache Ranger
Seguono alcuni dei problemi comunemente diagnosticati relativi all'utilizzo di Apache Ranger.
## Raccomandazioni
+ **Test utilizzando un cluster a nodo principale singolo:** il provisioning dei cluster a nodo master singolo è più rapido rispetto a un cluster a più nodi e può ridurre il tempo per ogni iterazione di test.
+ **Imposta la modalità di sviluppo sul cluster.** Quando avvii il cluster EMR, imposta il parametro `--additional-info"` su:
`'{"clusterType":"development"}'`
Questo parametro può essere impostato solo tramite AWS CLI o AWS SDK e non è disponibile tramite la console Amazon EMR. Quando questo contrassegno è impostato e il master non riesce a eseguire il provisioning, il servizio Amazon EMR mantiene il cluster attivo per un po' di tempo prima di disattivarlo. Questo arco temporale è molto utile per sondare i vari file di log prima che il cluster venga terminato.
# Insuccesso del provisioning del cluster EMR
Esistono diversi motivi alla base del mancato avvio di un cluster Amazon EMR. Di seguito sono riportati alcuni modi per diagnosticare il problema.
**Verifica dei log di provisioning EMR**
Amazon EMR utilizza Puppet per installare e configurare le applicazioni in un cluster. Esaminando i registri verranno forniti dettagli sulla presenza o meno di errori durante la fase di provisioning di un cluster. I log sono accessibili sul cluster o su S3 se sono configurati per essere inviati a S3.
I log vengono archiviati in `/var/log/provision-node/apps-phase/0/{UUID}/puppet.log` sul disco e `s3:////node//provision-node/apps-phase/0/{UUID}/puppet.log.gz.`.
**Messaggi di errore comuni**
| Messaggio di errore | Causa |
| --- | --- |
| Puppet (err): avvio di Systemd non riuscito\$1 emr-record-server Registro journalctl per: emr-record-server | Impossibile avviare EMR Record Server. Consulta "Log di EMR Record Server" di seguito. |
| Puppet (err): avvio di Systemd non riuscito\$1 emr-record-server log journalctl per emrsecretagent: | Impossibile avviare EMR Secret Agent. Consulta "Controllo dei log Secret Agent" di seguito. |
| /Stage [main] /ranger\$1plugins: :ranger\$1hive\$1 (avviso): 140408606197664:ERROR:0906D06C:Routine PEM: PEM\$1READ\$1BIO:NESSUNA RIGA DI AVVIO:PEM\$1LIB.C:707:IN ATTESA: QUALSIASI CHIAVE plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Hive plugin]/Exec[create keystore and truststore for Ranger Hive plugin]/returns PRIVATA | Il certificato TLS privato in Secrets Manager per il certificato del plug-in Apache Ranger non è nel formato corretto o non è un certificato privato. Consulta [Certificati TLS per l'integrazione di Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md) per i formati dei certificati. |
| /Stage [main] /ranger\$1plugins: :ranger\$1s3\$1 plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Ranger s3 plugin]/Exec[create keystore and truststore for Ranger amazon-emr-s3 plugin]/returns (notice): An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::XXXXXXXXXXX:assumed-role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXX non è autorizzato a eseguire: secretsmanager: GetSecretValue on resource: arn:aws:SecretsManager:US-EAST-1:xxxxxxxx:secret: -XXXXXXX AdminServer | Il ruolo del profilo dell'istanza EC2 non dispone delle autorizzazioni corrette per recuperare i certificati TLS da Secret Agent. |
** SecretAgent Registri di controllo**
I log di Secret Agent si trovano in `/emr/secretagent/log/` su un nodo EMR o nella directory `s3:////node//daemons/secretagent/` in S3.
**Messaggi di errore comuni**
| Messaggio di errore | Causa |
| --- | --- |
| Eccezione nel thread «main» com.amazonaws.services.securitytoken.model. AWSSecurityTokenServiceException: User: arn:aws:sts: :xxxxxxxxxx:Assumed- role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXX non è autorizzato a eseguire: sts: AssumeRole on resource: arn:aws:iam: :XXXXXXXXXX:role/\$1 (Service:; Codice di stato: 403; Codice di errore:; Codice di errore:; ID richiesta: XXXXXXXX-XXXXXX-XXXXXXXXXX; Proxy: nullo RangerPluginDataAccessRole) AWSSecurity TokenService AccessDenied | L'eccezione precedente indica che il ruolo del profilo dell'istanza EMR EC2 non dispone delle autorizzazioni per assumere il ruolo. **RangerPluginDataAccessRole** Per informazioni, consulta [Ruoli IAM per l'integrazione nativa con Apache Ranger](emr-ranger-iam.md). |
| ERROR qtp54617902-149: Web App Exception Occurred javax.ws.rs. NotAllowedException: Metodo HTTP 405 non consentito | Puoi ignorare questi errori senza correre rischi. |
**Controllo dei log di EMR Record Server (per SparkSQL)**
I log dell'EMR Record Server sono disponibili in/var/log/emr-record-server/ su un nodo EMR oppure possono essere trovati nella directory s3:////node/ /daemons//in S3. emr-record-server
**Messaggi di errore comuni**
| Messaggio di errore | Causa |
| --- | --- |
| InstanceMetadataServiceResourceFetcherI log di EMR Record Server sono disponibili in/-record-server/ su un nodo EMR oppure possono essere trovati nella directory s3:////node/ /daemons//in S3. ----sep----:105 - [] Impossibile recuperare il token com.amazonaws. SdkClientException: connessione all'endpoint del servizio non riuscita | L'EMR SecretAgent non è riuscito a comparire o presenta un problema. Ispeziona SecretAgent i log per individuare eventuali errori e lo script del pupazzo per determinare se ci sono errori di provisioning. |
# Le query falliscono inaspettatamente per l'integrazione di Ranger con Amazon EMR
**Controlla i log dei plugin Apache Ranger (registri di Apache Hive, EMR, EMR, ecc.RecordServer) SecretAgent**
Questa sezione è comune a tutte le applicazioni che si integrano con il plug-in Ranger, come Apache Hive, EMR Record Server ed EMR. SecretAgent
**Messaggi di errore comuni**
| Messaggio di errore | Causa |
| --- | --- |
| ERROR:272 PolicyRefresher - [] (PolicyRefresherserviceName=policy-repository): impossibile trovare il servizio. Will clean up local cache of policies (-1) | Questo messaggio di errore indica che il nome del servizio fornito nella configurazione di sicurezza EMR non corrisponde a un repository delle policy di servizio nel server Admin Ranger. |
Se all'interno del server Ranger Admin il tuo AMAZON-EMR-SPARK servizio è simile al seguente, dovresti inserirlo come nome del servizio. **amazonemrspark**
![\[Il server di amministrazione Ranger mostra AMAZON-EMR-SPARK la risoluzione dei problemi.\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark-troubleshooting.png)
# Controlla il traffico di rete con gruppi di sicurezza per il tuo cluster Amazon EMR
I gruppi di sicurezza agiscono da firewall virtuale per le istanze EC2 nel cluster allo scopo di controllare il traffico in entrata e quello in uscita. Ogni gruppo di sicurezza ha un set di regole che controlla il traffico in entrata verso le istanze e un set di regole per controllare il traffico in uscita. Per ulteriori informazioni, consulta [Gruppi di sicurezza Amazon EC2 per le istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) nella *Guida per l'utente di Amazon EC2*.
È possibile utilizzare due classi di gruppi di sicurezza con Amazon EMR: *gruppi di sicurezza gestiti da Amazon EMR* e *gruppi di sicurezza aggiuntivi*.
A ogni cluster sono associati gruppi di sicurezza gestiti. È possibile utilizzare i gruppi di sicurezza gestiti predefiniti creati da Amazon EMR oppure specificare gruppi di sicurezza gestiti personalizzati. In entrambi i casi, Amazon EMR aggiunge automaticamente le regole ai gruppi di sicurezza gestiti di cui un cluster ha bisogno per comunicare tra istanze e servizi del cluster. AWS
I gruppi di sicurezza aggiuntivi sono facoltativi. È possibile specificarli in aggiunta ai gruppi di sicurezza gestiti per definire l'accesso alle istanze del cluster. Altri gruppi di sicurezza contengono solo regole definite. Amazon EMR non li modifica.
Le regole che Amazon EMR crea nei gruppi di sicurezza gestiti consentono al cluster di comunicare tra i componenti interni. Per consentire agli utenti e alle applicazioni di accedere a un cluster dall'esterno del cluster, è possibile modificare le regole per i gruppi di sicurezza gestiti oppure è possibile creare ulteriori gruppi di sicurezza con regole aggiuntive o entrambe le cose.
**Importante**
Modificare le regole per i gruppi di sicurezza gestiti può avere conseguenze impreviste. Potresti inavvertitamente bloccare il traffico necessario per il corretto funzionamento dei cluster e causare errori in quanto i nodi non sono raggiungibili. Pianifica attentamente e verifica le configurazioni per i gruppi di sicurezza prima dell'implementazione.
Puoi, quindi, specificare i gruppi di sicurezza solo al momento della creazione di un cluster. Essi non possono essere aggiunti a un cluster o alle istanze del cluster mentre il cluster è in esecuzione, ma è possibile modificare, aggiungere o rimuovere regole dai gruppi di sicurezza esistenti. Le regole diventano effettive non appena vengono salvate.
Per impostazione predefinita, i gruppi di sicurezza sono restrittivi Se non si aggiunge una regola che consente il traffico, il traffico viene rifiutato. Se è presente più di una regola che si applica allo stesso traffico e alla stessa origine, viene applicata la regola più permissiva. Ad esempio, se si dispone di una regola che consente SSH dall'indirizzo IP 192.0.2.12/32 e un'altra regola che consente l'accesso a tutto il traffico TCP dall'intervallo 192.0.2.0/24, ha precedenza la regola che consente tutto il traffico TCP dall'intervallo che include 192.0.2.12. In questo caso, il client all'intervallo 192.0.2.12 può avere più accesso di quanto si desideri.
**Importante**
Presta attenzione quando modifichi le regole per i gruppi di sicurezza per aprire le porte. Assicurati di aggiungere regole che permettano solo il traffico da client affidabili e autenticati per i protocolli e le porte necessari per eseguire i tuoi carichi di lavoro.
È possibile configurare il *blocco degli accessi pubblici* per Amazon EMR in ogni Regione utilizzata per impedire la creazione del cluster quando una regola consente l'accesso pubblico su una porta non aggiunta a un elenco di eccezioni. Per AWS gli account creati dopo luglio 2019, l'accesso pubblico a blocchi di Amazon EMR è attivo per impostazione predefinita. Per AWS gli account che hanno creato un cluster prima di luglio 2019, l'accesso pubblico a blocchi di Amazon EMR è disattivato per impostazione predefinita. Per ulteriori informazioni, consulta [Utilizzo del blocco dell'accesso pubblico di Amazon EMR](emr-block-public-access.md).
**Topics**
+ [Utilizzo dei gruppi di sicurezza gestiti da Amazon EMR](emr-man-sec-groups.md)
+ [Utilizzo di gruppi di sicurezza aggiuntivi per un cluster Amazon EMR](emr-additional-sec-groups.md)
+ [Specifica dei gruppi di sicurezza gestiti da Amazon EMR e aggiuntivi](emr-sg-specify.md)
+ [Specifica dei gruppi di sicurezza EC2 per EMR Notebooks](emr-managed-notebooks-security-groups.md)
+ [Utilizzo del blocco dell'accesso pubblico di Amazon EMR](emr-block-public-access.md)
**Nota**
Amazon EMR mira a utilizzare alternative inclusive per termini di settore potenzialmente offensivi o non inclusivi come "master" e "slave". Siamo passati a una nuova terminologia per promuovere un'esperienza più inclusiva e facilitare la comprensione dei componenti del servizio.
Ora descriviamo i "nodi" come **istanze** e descriviamo i tipi di istanze Amazon EMR come **primario**i, **principale** e **attività**. Durante la transizione, potresti ancora trovare riferimenti precedenti a termini obsoleti, come quelli relativi ai gruppi di sicurezza per Amazon EMR.
# Utilizzo dei gruppi di sicurezza gestiti da Amazon EMR
**Nota**
Amazon EMR mira a utilizzare alternative inclusive per termini di settore potenzialmente offensivi o non inclusivi come "master" e "slave". Siamo passati a una nuova terminologia per promuovere un'esperienza più inclusiva e facilitare la comprensione dei componenti del servizio.
Ora descriviamo i "nodi" come **istanze** e descriviamo i tipi di istanze Amazon EMR come **primario**i, **principale** e **attività**. Durante la transizione, potresti ancora trovare riferimenti precedenti a termini obsoleti, come quelli relativi ai gruppi di sicurezza per Amazon EMR.
I diversi gruppi di sicurezza gestiti sono associati all'istanza primaria e alle istanze principali e attività in un cluster. Quando si crea un cluster in una sottorete privata, è necessario un ulteriore gruppo di sicurezza gestito per l'accesso ai servizi. Per ulteriori informazioni sul ruolo dei gruppi di sicurezza gestiti per quanto riguarda la configurazione di rete, consulta [Opzioni Amazon VPC all'avvio di un cluster](emr-clusters-in-a-vpc.md).
Quando vengono specificati i gruppi di sicurezza gestiti per un cluster, è necessario utilizzare lo stesso tipo di gruppo di sicurezza, predefinito o personalizzato, per tutti i gruppi di sicurezza gestiti. Ad esempio, non è possibile specificare un gruppo di sicurezza personalizzato per l'istanza primaria, quindi non specificare un gruppo di sicurezza personalizzato per le istanze principali e le istanze attività.
Se utilizzi i gruppi di sicurezza gestiti predefiniti, non è necessario specificarli quando si crea un cluster. Amazon EMR utilizza automaticamente le impostazioni predefinite. Inoltre, se le impostazioni predefinite non esistono ancora nel VPC del cluster, Amazon EMR le crea. Amazon EMR le crea anche se vengono specificate in modo esplicito e non esistono ancora.
Puoi modificare le regole nei gruppi di sicurezza gestiti dopo la creazione dei cluster. Quando crei un nuovo cluster, Amazon EMR controlla le regole nei gruppi di sicurezza gestiti specificati e quindi crea tutte le regole *in entrata* mancanti necessarie per il nuovo cluster, oltre alle regole che possono essere state aggiunte in precedenza. Salvo diversamente specificato, ciascuna regola per gruppi di sicurezza gestiti da Amazon EMR predefiniti viene anche aggiunta a gruppi di sicurezza gestiti da Amazon EMR personalizzati da te specificati.
I gruppi di sicurezza gestiti predefiniti sono i seguenti:
+ **ElasticMapReduce-primario**
Per le regole in questo gruppo di sicurezza, consulta [Gruppo di sicurezza gestito da Amazon EMR per l'istanza primaria (sottoreti pubbliche)](#emr-sg-elasticmapreduce-master).
+ **ElasticMapReduce-nucleo**
Per le regole in questo gruppo di sicurezza, consulta [Gruppo di sicurezza gestito da Amazon EMR per le istanze principali e attività (sottoreti pubbliche)](#emr-sg-elasticmapreduce-slave).
+ **ElasticMapReduce-Primario-Privato**
Per le regole in questo gruppo di sicurezza, consulta [Gruppo di sicurezza gestito da Amazon EMR per l'istanza primaria (sottoreti private)](#emr-sg-elasticmapreduce-master-private).
+ **ElasticMapReduce-Privato principale**
Per le regole in questo gruppo di sicurezza, consulta [Gruppo di sicurezza gestito da Amazon EMR per le istanze principali e attività (sottoreti private)](#emr-sg-elasticmapreduce-slave-private).
+ **ElasticMapReduce-ServiceAccess**
Per le regole in questo gruppo di sicurezza, consulta [Gruppo di sicurezza gestito da Amazon EMR per l'accesso ai servizi (sottoreti private)](#emr-sg-elasticmapreduce-sa-private).
## Gruppo di sicurezza gestito da Amazon EMR per l'istanza primaria (sottoreti pubbliche)
**Il gruppo di sicurezza gestito predefinito per l'istanza principale nelle sottoreti pubbliche ha il **nome di gruppo** -primary. ElasticMapReduce** Include le seguenti regole: Se specifichi un gruppo di sicurezza gestito personalizzato, Amazon EMR aggiungerà le stesse regole al gruppo di sicurezza personalizzato.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-man-sec-groups.html)
**Per concedere a fonti attendibili l'accesso SSH al gruppo di sicurezza primario con la console**
Per modificare i gruppi di sicurezza, devi disporre dell'autorizzazione per gestire i gruppi di sicurezza per il VPC in cui si trova il cluster. Per ulteriori informazioni, consulta [Modifica delle autorizzazioni per un utente](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html) e la [Policy di esempio](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) che consente di gestire i gruppi di sicurezza EC2 nella *Guida per l'utente IAM*.
1. [Accedi a e apri Console di gestione AWS la console Amazon EMR su https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Scegli **Cluster**. Scegli l'**ID** del cluster che desideri modificare.
1. Nel riquadro **Rete e sicurezza**, espandi il menu a discesa dei **gruppi di sicurezza EC2 (firewall)**.
1. Nel **nodo primario**, scegli il tuo gruppo di sicurezza.
1. Sceglere **Edit inbound rules (Modifica regole in entrata)**.
1. Verifica la presenza di una regola in entrata che consenta l'accesso pubblico con le seguenti impostazioni. Se esiste, scegli **Elimina** per rimuoverla.
+ **Tipo**
SSH
+ **Porta**
22
+ **Origine**
Personalizzata 0.0.0.0/0
**avvertimento**
Prima di dicembre 2020, esisteva una regola preconfigurata per consentire il traffico in entrata sulla porta 22 da tutte le fonti. Questa regola è stata creata per semplificare le connessioni SSH iniziali al nodo primario. Consigliamo vivamente di rimuovere questa regola in entrata e limitare il traffico alle origini affidabili.
1. Scorri fino alla fine dell'elenco di regole e seleziona **Aggiungi regola**.
1. Per **Tipo**, seleziona **SSH**.
Selezionando SSH si inserisce in automatico **TCP** per **Protocollo** e **22** per **Intervallo porta**.
1. Per origine, seleziona **Il mio IP** per aggiungere in automatico il tuo indirizzo IP come indirizzo di origine. Puoi anche aggiungere un intervallo di indirizzi IP affidabili del client **Custom (Personalizzato)**, o creare regole aggiuntive per altri client. In molti ambienti di rete, gli indirizzi IP vengono allocati in modo dinamico, perciò, nel futuro, potrebbe essere necessario aggiornare gli indirizzi IP per client affidabili.
1. Scegli **Save** (Salva).
1. Facoltativamente, scegli l'altro gruppo di sicurezza in **Core e task nodes** nel pannello **Rete e sicurezza e** ripeti i passaggi precedenti per consentire al client SSH l'accesso ai nodi principali e task.
## Gruppo di sicurezza gestito da Amazon EMR per le istanze principali e attività (sottoreti pubbliche)
**Il gruppo di sicurezza gestito predefinito per le istanze core e task nelle sottoreti pubbliche ha il nome di **gruppo** -core. ElasticMapReduce** Il gruppo di sicurezza gestito predefinito ha le regole seguenti e Amazon EMR aggiunge le stesse regole se si specifica un gruppo di sicurezza gestito personalizzato.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Gruppo di sicurezza gestito da Amazon EMR per l'istanza primaria (sottoreti private)
****Il gruppo di sicurezza gestito predefinito per l'istanza principale nelle sottoreti private ha il nome di gruppo -Primary-Private. ElasticMapReduce**** Il gruppo di sicurezza gestito predefinito ha le regole seguenti e Amazon EMR aggiunge le stesse regole se si specifica un gruppo di sicurezza gestito personalizzato.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Gruppo di sicurezza gestito da Amazon EMR per le istanze principali e attività (sottoreti private)
****Il gruppo di sicurezza gestito predefinito per le istanze core e task nelle sottoreti private ha il nome di gruppo -Core-Private. ElasticMapReduce**** Il gruppo di sicurezza gestito predefinito ha le regole seguenti e Amazon EMR aggiunge le stesse regole se si specifica un gruppo di sicurezza gestito personalizzato.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-man-sec-groups.html)
### Modifica di regole in uscita
Per impostazione predefinita, Amazon EMR crea questo gruppo di sicurezza con regole in uscita che consentono tutto il traffico in uscita su protocolli e porte. L'autorizzazione di tutto il traffico in uscita è selezionata perché diverse applicazioni Amazon EMR e cliente eseguibili su cluster Amazon EMR potrebbero richiedere regole di uscita diverse. Amazon EMR non è in grado di prevedere queste impostazioni specifiche durante la creazione di gruppi di sicurezza predefiniti. È possibile definire l'ambito in uscita nei gruppi di sicurezza in modo da includere solo le regole che si adattano ai casi d'uso e alle policy di sicurezza. Questo gruppo di sicurezza richiede almeno le seguenti regole in uscita, ma alcune applicazioni potrebbero richiedere un'uscita aggiuntiva.
| Tipo | Protocollo | Intervallo porte | Destinazione | Informazioni |
| --- | --- | --- | --- | --- |
| Tutte le regole TCP | TCP | Tutti | pl- xxxxxxxx | Elenco dei prefissi Amazon S3 gestiti com.amazonaws.MyRegion.s3. |
| All Traffic | Tutti | Tutti | sg- xxxxxxxxxxxxxxxxx | L'ID del gruppo di sicurezza ElasticMapReduce-Core-Private. |
| All Traffic | Tutti | Tutti | sg- xxxxxxxxxxxxxxxxx | L'ID del gruppo di sicurezza ElasticMapReduce-Primary-Private. |
| TCP personalizzato | TCP | 9443 | sg- xxxxxxxxxxxxxxxxx | L'ID del gruppo di sicurezza ElasticMapReduce-ServiceAccess. |
## Gruppo di sicurezza gestito da Amazon EMR per l'accesso ai servizi (sottoreti private)
**Il gruppo di sicurezza gestito predefinito per l'accesso ai servizi nelle sottoreti private ha il **nome del gruppo** di -. ElasticMapReduce ServiceAccess** Dispone di regole in entrata e di regole in uscita che consentono il traffico su HTTPS (porta 8443, porta 9443) per altri i gruppi di sicurezza gestiti nelle sottoreti private. Tali regole consentono al cluster manager di comunicare con il nodo primario e con i nodi principale e attività. Le stesse regole sono necessarie se si utilizzano gruppi di sicurezza personalizzati.
| Tipo | Protocollo | Intervallo porte | Origine | Informazioni |
| --- | --- | --- | --- | --- |
| Regole in ingresso richieste per i cluster Amazon EMR con Amazon EMR versione 5.30.0 e successive. |
| TCP personalizzato | TCP | 9443 | L'ID del gruppo di sicurezza gestito dell'istanza primaria. | Questa regola consente la comunicazione tra il gruppo di sicurezza dell'istanza primaria e il gruppo di sicurezza di accesso al servizio. |
| Regole in uscita richieste per tutti i cluster Amazon EMR |
| TCP personalizzato | TCP | 8443 | L'ID del gruppo di sicurezza gestito dell'istanza primaria. | Tali regole consentono al cluster manager di comunicare con il nodo primario e con i nodi principale e attività. |
| TCP personalizzato | TCP | 8443 | L'ID del gruppo di sicurezza gestito specificato per le istanze principali e di attività. | Tali regole consentono al cluster manager di comunicare con il nodo primario e con i nodi principale e attività. |
# Utilizzo di gruppi di sicurezza aggiuntivi per un cluster Amazon EMR
Sia se si utilizzano i gruppi di sicurezza gestiti predefiniti o se si specificano gruppi di sicurezza gestiti personalizzati, è possibile utilizzare i gruppi di sicurezza aggiuntivi. I gruppi di sicurezza aggiuntivi offrono la flessibilità necessaria per definire l'accesso tra diversi cluster e dai client, risorse e applicazioni esterne.
Si consideri lo scenario riportato di seguito come un esempio: Disponi di più cluster che devono comunicare reciprocamente ma desideri consentire l'accesso SSH in entrata all'istanza primaria solo a un determinato sottoinsieme di cluster. Per eseguire questa operazione, puoi utilizzare lo stesso set di gruppi di sicurezza gestiti per i cluster. Quindi crei gruppi di sicurezza aggiuntivi che consentono l'accesso SSH in entrata da client affidabili e specifichi i gruppi di sicurezza aggiuntivi per l'istanza primaria per ogni cluster nel sottoinsieme.
Puoi applicare fino a 15 gruppi di sicurezza aggiuntivi per l'istanza principale, 15 per le istanze core e task e 15 per l'accesso al servizio (nelle sottoreti private). Se necessario, puoi specificare lo stesso gruppo di sicurezza aggiuntivo per le istanze primarie, principali, attività e per l'accesso ai servizi. Il numero massimo di gruppi di sicurezza e di regole nell'account è soggetto ai limiti dell'account. Per ulteriori informazioni, consulta [Limiti del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups) nella *Guida per l'utente di Amazon VPC*.
# Specifica dei gruppi di sicurezza gestiti da Amazon EMR e aggiuntivi
Puoi specificare i gruppi di sicurezza utilizzando AWS CLI l' Console di gestione AWS API Amazon EMR. Se non specifichi i gruppi di sicurezza, Amazon EMR crea i gruppi di sicurezza predefiniti. Specificare i gruppi di sicurezza aggiuntivi è facoltativo. Puoi assegnare i gruppi di sicurezza aggiuntivi per le istanze primarie, principali, attività e per l'accesso ai servizi (solo sottoreti private).
------
#### [ Console ]
**Per specificare i gruppi di sicurezza con la console**
1. [Accedi a e apri Console di gestione AWS la console Amazon EMR su https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. In **EMR on EC2** (EMR su EC2), nel riquadro di navigazione a sinistra, scegli **Clusters** (Cluster) e seleziona **Create cluster** (Crea cluster).
1. In **Networking** (Reti), seleziona la freccia accanto ai **EC2 security groups (firewall) (Gruppi di sicurezza EC2 [firewall])** per espandere questa sezione. In **Primary node** (Nodo primario) e **Core and task nodes** (Nodi core e attività), i gruppi di sicurezza gestiti da Amazon EMR predefiniti sono selezionati per impostazione predefinita. Se utilizzi una sottorete privata, hai la possibilità di selezionare un gruppo di sicurezza anche per **Service access** (Accesso al servizio).
1. Per modificare il gruppo di sicurezza gestito da Amazon EMR, utilizza il menu a discesa **Choose security groups** (Scegli gruppi di sicurezza) per selezionare un'opzione diversa dall'elenco di opzioni **Amazon EMR-managed security group** (Gruppo di sicurezza gestito da Amazon EMR). Hai un gruppo di sicurezza gestito da Amazon EMR sia per **Primary node** (Nodo primario) sia per **Core and task nodes** (Nodi core e attività).
1. Per aggiungere gruppi di sicurezza personalizzati, utilizza lo stesso menu a discesa **Choose security groups** (Scegli gruppi di sicurezza) per selezionare fino a quattro gruppi di sicurezza personalizzati dall'elenco di opzioni **Custom security group** (Gruppi di sicurezza personalizzati). È possibile avere fino a quattro gruppi di sicurezza personalizzati sia per **Primary node** (Nodo primario) sia per **Core and task nodes** (Nodi core e attività).
1. Scegli qualsiasi altra opzione applicabile al cluster.
1. Per avviare il cluster, scegli **Create cluster** (Crea cluster).
------
## Specificare i gruppi di sicurezza con AWS CLI
Per specificare i gruppi di sicurezza utilizzando il AWS CLI `create-cluster` comando con i seguenti parametri dell'`--ec2-attributes`opzione:
| Parametro | Description |
| --- | --- |
| `EmrManagedPrimarySecurityGroup` | Utilizza questo parametro per specificare un gruppo di sicurezza gestito personalizzato per l'istanza primaria. Se è specificato questo parametro, è necessario specificare anche `EmrManagedCoreSecurityGroup`. Per i cluster in sottoreti private deve essere specificato anche `ServiceAccessSecurityGroup`. |
| `EmrManagedCoreSecurityGroup` | Utilizza questo parametro per specificare un gruppo di sicurezza gestito personalizzato per le istanze principali e di attività. Se è specificato questo parametro, è necessario specificare anche `EmrManagedPrimarySecurityGroup`. Per i cluster in sottoreti private deve essere specificato anche `ServiceAccessSecurityGroup`. |
| `ServiceAccessSecurityGroup` | Utilizza questo parametro per specificare un gruppo di sicurezza gestito personalizzato per l'accesso ai servizi, che si applica solo ai cluster nelle sottoreti private. Il gruppo di sicurezza specificato come `ServiceAccessSecurityGroup` non deve essere utilizzato per alcun altro scopo e deve essere riservato anche ad Amazon EMR. Se è specificato questo parametro, è necessario specificare anche `EmrManagedPrimarySecurityGroup`. |
| `AdditionalPrimarySecurityGroups` | Utilizza questo parametro per specificare fino a quattro gruppi di sicurezza aggiuntivi per l'istanza primaria. |
| `AdditionalCoreSecurityGroups` | Utilizza questo parametro per specificare fino a quattro gruppi di sicurezza aggiuntivi per le istanze principali e di attività. |
**Example Specifica di gruppi di sicurezza gestiti da Amazon EMR e gruppi di sicurezza aggiuntivi personalizzati**
L'esempio seguente specifica gruppi di sicurezza gestiti da Amazon EMR personalizzati per un cluster in una sottorete privata, più gruppi di sicurezza aggiuntivi per l'istanza primaria e un singolo gruppo di sicurezza aggiuntivo per le istanze principale e attività.
I caratteri di continuazione della riga Linux (\$1) sono inclusi per questioni di leggibilità. Possono essere rimossi o utilizzati nei comandi Linux. Per Windows, rimuoverli o sostituirli con un accento circonflesso (^).
```
1. aws emr create-cluster --name "ClusterCustomManagedAndAdditionalSGs" \
2. --release-label emr-emr-7.12.0 --applications Name=Hue Name=Hive \
3. Name=Pig --use-default-roles --ec2-attributes \
4. SubnetIds=subnet-xxxxxxxxxxxx,KeyName=myKey,\
5. ServiceAccessSecurityGroup=sg-xxxxxxxxxxxx,\
6. EmrManagedPrimarySecurityGroup=sg-xxxxxxxxxxxx,\
7. EmrManagedCoreSecurityGroup=sg-xxxxxxxxxxx,\
8. AdditionalPrimarySecurityGroups=['sg-xxxxxxxxxxx',\
9. 'sg-xxxxxxxxxxx','sg-xxxxxxxxxx'],\
10. AdditionalCoreSecurityGroups=sg-xxxxxxxxxxx \
11. --instance-type m5.xlarge
```
Per ulteriori informazioni, consulta [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html) nella *Guida di riferimento ai comandi della AWS CLI *.
# Specifica dei gruppi di sicurezza EC2 per EMR Notebooks
Al momento della creazione di un notebook EMR, per controllare il traffico di rete tra il notebook EMR e il cluster Amazon EMR vengono utilizzati due gruppi di sicurezza quando si usa l'editor del notebook. I gruppi di sicurezza predefiniti dispongono di regole minime che consentono solo il traffico di rete tra il servizio EMR Notebooks e i cluster a cui sono collegati i notebook.
Un notebook EMR utilizza [Apache Livy](https://livy.incubator.apache.org/) per comunicare con il cluster tramite un proxy utilizzando la porta TCP 18888. Quando si creano gruppi di sicurezza personalizzati con regole su misura per l'ambiente, è possibile limitare il traffico di rete in modo che solo un sottoinsieme di notebook sia in grado di eseguire il codice all'interno dell'editor del notebook su determinati cluster. Il cluster utilizza la sicurezza personalizzata in aggiunta ai gruppi di sicurezza predefiniti per il cluster. Per ulteriori informazioni, consulta [Controllo del traffico di rete con i gruppi di sicurezza](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html) nella *Guida alla gestione di Amazon EMR* e [Specifica dei gruppi di sicurezza EC2 per EMR Notebooks](#emr-managed-notebooks-security-groups).
## Gruppo di sicurezza EC2 predefinito per l'istanza primaria
Il gruppo di sicurezza EC2 predefinito per l'istanza primaria è associato all'istanza primaria in aggiunta ai gruppi di sicurezza del cluster dell'istanza primaria.
Nome del gruppo: **ElasticMapReduceEditors-Livy**
**Regole**
+ In entrata
Consenti la porta TCP 18888 da qualsiasi risorsa del gruppo di sicurezza predefinito EC2 per EMR Notebooks.
+ In uscita
Nessuno
## Gruppi di sicurezza EC2 predefiniti per EMR Notebooks
Il gruppo di sicurezza EC2 predefinito per il notebook EMR è associato all'editor del notebook per qualsiasi notebook EMR a cui è assegnato.
**Nome del gruppo: -Editor ElasticMapReduceEditors**
**Regole**
+ In entrata
Nessuno
+ In uscita
Consenti la porta TCP 18888 a qualsiasi risorsa del gruppo di sicurezza predefinito EC2 per EMR Notebooks.
## Gruppo di sicurezza EC2 personalizzato per EMR Notebooks quando si associano notebook con repository Git
Per collegare un repository Git al notebook, il gruppo di sicurezza per il notebook EMR deve includere una regola in uscita per consentire al notebook di instradare il traffico a Internet. Si consiglia di creare un nuovo gruppo di sicurezza per questo scopo. L'aggiornamento del gruppo di sicurezza predefinito **ElasticMapReduceEditors-Editor** può fornire le stesse regole in uscita ad altri notebook collegati a questo gruppo di sicurezza.
**Regole**
+ In entrata
Nessuno
+ In uscita
Consenti al notebook di instradare il traffico a Internet tramite il cluster, come illustrato nell'esempio seguente: Ad esempio, viene utilizzato il valore 0.0.0.0/0. È possibile modificare questa regola per specificare gli indirizzi IP dei repository basati su Git.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-managed-notebooks-security-groups.html)
# Utilizzo del blocco dell'accesso pubblico di Amazon EMR
Il *blocco dell'accesso pubblico (BPA)* di Amazon EMR impedisce l'avvio di un cluster in una sottorete pubblica se il cluster dispone di una configurazione di sicurezza che consente il traffico in entrata da indirizzi IP pubblici su una porta.
**Importante**
Il *blocco dell'accesso pubblico* è abilitato per impostazione predefinita. Per aumentare la protezione degli account, ti consigliamo di mantenerlo abilitato.
## Informazioni sul blocco dell'accesso pubblico
Puoi utilizzare la configurazione a livello di account del *blocco dell'accesso pubblico* per gestire a livello centrale l'accesso della rete pubblica ai cluster Amazon EMR.
Quando un tuo utente Account AWS avvia un cluster, Amazon EMR verifica le regole delle porte nel gruppo di sicurezza per il cluster e le confronta con le regole del traffico in entrata. Se il gruppo di sicurezza ha una regola in entrata che apre le porte agli indirizzi IP pubblici IPv4 0.0.0.0/0 o IPv6 : :/0 e tali porte non sono specificate come eccezioni per il tuo account, Amazon EMR non consente all'utente di creare il cluster.
Se un utente modifica le regole del gruppo di sicurezza per un cluster in esecuzione in una sottorete pubblica in modo da avere una regola di accesso pubblico che viola la configurazione BPA del tuo account, Amazon EMR revoca la nuova regola se dispone dell'autorizzazione per farlo. Se Amazon EMR non dispone dell'autorizzazione per revocare la regola, crea un evento nel pannello di controllo di AWS Health che descrive la violazione. Per concedere l'autorizzazione alla revoca della regola ad Amazon EMR, consulta [Configura Amazon EMR per revocare le regole dei gruppi di sicurezza](#revoke-block-public-access).
Il blocco dell'accesso pubblico è abilitato per impostazione predefinita per tutti i cluster di ogni Regione AWS per il tuo Account AWS. Il BPA si applica all'intero ciclo di vita di un cluster, ma non si applica ai cluster creati in sottoreti private. È possibile configurare eccezioni alla regola BPA; la porta 22 è un'eccezione per impostazione predefinita. Per ulteriori informazioni sull'impostazione delle eccezioni, consulta [Configurazione del blocco degli accessi pubblici](#configure-block-public-access).
## Configurazione del blocco degli accessi pubblici
È possibile aggiornare i gruppi di sicurezza e la configurazione del blocco dell'accesso pubblico negli account in qualsiasi momento.
Puoi attivare e disattivare le impostazioni di accesso pubblico a blocchi (BPA) con Console di gestione AWS, the AWS Command Line Interface (AWS CLI) e l'API Amazon EMR. Le impostazioni si applicano a tutto l'account su base individuale. Region-by-Region Per preservare la sicurezza del cluster, si consiglia di mantenere abilitato il blocco dell'accesso pubblico.
------
#### [ Console ]
**Per configurare l'accesso pubblico a blocchi con la console**
1. [Accedi a Console di gestione AWS, quindi apri la console Amazon EMR su https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Nella barra di navigazione in alto, seleziona la **Regione** che desideri configurare, se non è già selezionata.
1. In **EMR on EC2** (EMR su EC2), nel riquadro di navigazione a sinistra, scegli **Block public access** (Blocca accesso pubblico).
1. In **Block public access settings (Impostazioni blocco accesso pubblico)** completare la procedura seguente.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-block-public-access.html)
------
#### [ AWS CLI ]
**Per configurare l'accesso pubblico a blocchi utilizzando il AWS CLI**
+ Utilizzare il comando `aws emr put-block-public-access-configuration` per configurare il blocco degli accessi pubblici come mostrato negli esempi seguenti.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/emr/latest/ManagementGuide/emr-block-public-access.html)
------
## Configura Amazon EMR per revocare le regole dei gruppi di sicurezza
Amazon EMR necessita dell'autorizzazione per revocare le regole dei gruppi di sicurezza e conformarsi alla configurazione del blocco dell'accesso pubblico. Puoi utilizzare uno dei seguenti approcci per concedere ad Amazon EMR l'autorizzazione necessaria:
+ **Consigliato** Collega la policy gestita da `AmazonEMRServicePolicy_v2` al ruolo di servizio. Per ulteriori informazioni, consulta [Ruolo di servizio per Amazon EMR (ruolo EMR)](emr-iam-role.md).
+ Crea una nuova policy inline che consenta l'operazione `ec2:RevokeSecurityGroupIngress` sui gruppi di sicurezza. Per ulteriori informazioni su come modificare una policy di autorizzazione dei ruoli, consulta **Modifica di una policy di autorizzazioni dei ruoli** con la [console IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy), l'[API AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-api.html#roles-modify_permissions-policy-api) e la [AWS CLI](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-cli.html#roles-modify_permissions-policy-cli) nella *Guida per l'utente IAM*.
## Risoluzione delle violazioni dell'accesso pubblico
Se si verifica una violazione del blocco dell'accesso pubblico, puoi mitigarla con una delle seguenti azioni:
+ Se desideri accedere a un'interfaccia Web sul tuo cluster, usa una delle opzioni descritte in [Visualizzazione di interfacce Web ospitate su cluster Amazon EMR](emr-web-interfaces.md) per accedere all'interfaccia tramite SSH (porta 22).
+ Per consentire il traffico verso il cluster da indirizzi IP specifici anziché dall'indirizzo IP pubblico, aggiungi una regola del gruppo di sicurezza. Per ulteriori informazioni, consulta [Aggiunta di regole a un gruppo di sicurezza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) nella *Guida alle operazioni di base di Amazon EC2*.
+ **(Non consigliato)** Puoi configurare le eccezioni BPA di Amazon EMR per includere la porta o l'intervallo di porte desiderati. Quando specifichi un'eccezione BPA, introduci un rischio con una porta non protetta. Se intendi specificare un'eccezione, devi rimuoverla appena non è più necessaria. Per ulteriori informazioni, consulta [Configurazione del blocco degli accessi pubblici](#configure-block-public-access).
## Identificazione dei cluster associati alle regole dei gruppi di sicurezza
Potrebbe essere necessario identificare tutti i cluster associati a una determinata regola dei gruppi di sicurezza o trovare la regola dei gruppi di sicurezza per un determinato cluster.
+ Se conosci il gruppo di sicurezza, puoi identificare i cluster associati, se trovi le interfacce di rete per tale gruppo di sicurezza. Per ulteriori informazioni, consulta [Come posso trovare le risorse associate a un gruppo di sicurezza di Amazon EC2](https://forums.aws.amazon.com/knowledge-center/ec2-find-security-group-resources)? su AWS re:Post. Le istanze Amazon EC2 collegate a queste interfacce di rete verranno contrassegnate con l'ID del cluster a cui appartengono.
+ Se desideri trovare i gruppi di sicurezza per un cluster noto, segui i passaggi riportati in [Visualizza lo stato e i dettagli del cluster Amazon EMR](emr-manage-view-clusters.md). Puoi trovare i gruppi di sicurezza per il cluster nel riquadro **Rete e sicurezza** della console o nel campo `Ec2InstanceAttributes` della AWS CLI.
# Convalida della conformità per Amazon EMR
I revisori di terze parti valutano la sicurezza e la conformità di Amazon EMR nell'ambito di AWS diversi programmi di conformità. Questi includono SOC, PCI, FedRAMP, HIPAA e altri.
Per un elenco dei AWS servizi che rientrano nell'ambito di specifici programmi di conformità, consulta la sezione [AWS Servizi rientranti nell'ambito del programma di conformità](https://aws.amazon.com/compliance/services-in-scope/). Per informazioni generali, consultare [Programmi per la conformità di AWS](https://aws.amazon.com/compliance/programs/).
È possibile scaricare report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
La tua responsabilità di conformità durante l'utilizzo di Amazon EMR è determinata dalla riservatezza dei dati, dagli obiettivi di conformità dell'azienda e dalle leggi e normative applicabili. Se l'uso di Amazon EMR è soggetto alla conformità a standard come HIPAA, PCI o FedRAMP, fornisce risorse per aiutarti a: AWS
+ Guide [rapide di avvio su sicurezza e conformità: queste guide all'](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance)implementazione illustrano considerazioni sull'architettura e forniscono passaggi per implementare ambienti di base incentrati sulla sicurezza e la conformità. AWS
+ [Whitepaper Architecting for HIPAA Security and Compliance: questo white paper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) descrive in che modo le aziende possono utilizzare per creare applicazioni conformi allo standard HIPAA. AWS
+ [AWS risorse per la conformità](https://aws.amazon.com/compliance/resources/): questa raccolta di cartelle di lavoro e guide potrebbe riguardare il settore e la località in cui operi.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Questo AWS servizio valuta la conformità delle configurazioni delle risorse alle pratiche interne, alle linee guida del settore e alle normative.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Questo AWS servizio offre una visione completa dello stato di sicurezza dell'utente e consente AWS di verificare la conformità agli standard e alle best practice del settore della sicurezza.
# Resilienza in Amazon EMR
L'infrastruttura AWS globale è costruita attorno a AWS regioni e zone di disponibilità. AWS Le regioni forniscono più zone di disponibilità fisicamente separate e isolate, collegate con reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità, è possibile progettare e gestire applicazioni e database che eseguono il failover automatico tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture tradizionali a data center singolo o multiplo.
[Per ulteriori informazioni su AWS regioni e zone di disponibilità, consulta infrastruttura globale.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
Oltre all'infrastruttura AWS globale, Amazon EMR offre diverse funzionalità per supportare le tue esigenze di resilienza e backup dei dati.
+ **Integrazione con Amazon S3 tramite EMRFS**
+ **Supporto per più nodi master**
# Sicurezza dell'infrastruttura in Amazon EMR
In quanto servizio gestito, Amazon EMR è protetto dalla sicurezza di rete AWS globale. Per informazioni sui servizi di AWS sicurezza e su come AWS protegge l'infrastruttura, consulta [AWS Cloud Security](https://aws.amazon.com/security/). Per progettare il tuo AWS ambiente utilizzando le migliori pratiche per la sicurezza dell'infrastruttura, vedi [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected* Framework.
Utilizza chiamate API AWS pubblicate per accedere ad Amazon EMR attraverso la rete. I client devono supportare quanto segue:
+ Transport Layer Security (TLS). È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Suite di cifratura con Perfect Forward Secrecy (PFS), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
**Topics**
+ [Connessione ad Amazon EMR utilizzando un endpoint VPC di interfaccia](interface-vpc-endpoint.md)
# Connessione ad Amazon EMR utilizzando un endpoint VPC di interfaccia
Puoi connetterti direttamente ad Amazon EMR utilizzando un'interfaccia [VPC endpoint (AWS PrivateLink) nel tuo Virtual Private Cloud (](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html)VPC) invece di connetterti tramite Internet. Quando utilizzi un endpoint VPC di interfaccia, la comunicazione tra il tuo VPC e Amazon EMR avviene interamente all'interno della rete. AWS Ogni endpoint VPC è rappresentato da una o più [interfacce di rete elastiche](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) con indirizzi IP privati nelle sottoreti VPC.
L'endpoint VPC di interfaccia collega il tuo VPC direttamente ad Amazon EMR senza un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione. Direct Connect Le istanze presenti nel tuo VPC non richiedono indirizzi IP pubblici per comunicare con l'API di Amazon EMR.
Per utilizzare Amazon EMR tramite il VPC, devi connetterti da un'istanza che si trova all'interno del VPC o connettere la rete privata al VPC utilizzando Amazon Virtual Private Network (VPN) o Direct Connect. Per informazioni su Amazon VPN, consulta [Connessioni VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*. *Per informazioni su AWS Direct Connect, consulta [Creare una connessione](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-connection.html) nella Guida per l'utente.Direct Connect *
Puoi creare un endpoint VPC di interfaccia per connetterti ad Amazon EMR utilizzando la AWS console o i comandi (). AWS Command Line Interface AWS CLI Per ulteriori informazioni, consulta [Creazione di un endpoint di interfaccia](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#create-interface-endpoint).
Se dopo aver creato un endpoint VPC di interfaccia abiliti nomi host DNS privati per l'endpoint, l'endpoint Amazon EMR predefinito restituisce il tuo endpoint VPC. L'endpoint del nome del servizio predefinito per Amazon EMR è nel formato seguente.
```
elasticmapreduce.Region.amazonaws.com
```
Se non abiliti nomi host DNS privati, Amazon VPC fornisce un nome di endpoint DNS che puoi utilizzare nel formato seguente:
```
VPC_Endpoint_ID.elasticmapreduce.Region.vpce.amazonaws.com
```
Per ulteriori informazioni, consultare [Endpoint VPC di interfaccia (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) nella *Guida per l'utente di Amazon VPC*.
Amazon EMR supporta l'esecuzione di chiamate a tutte le sue [operazioni API](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) all'interno del VPC.
Puoi collegare le policy di endpoint VPC a un endpoint VPC per controllare l'accesso per le entità principali IAM. Puoi inoltre associare i gruppi di sicurezza a un endpoint VPC per controllare l'accesso in ingresso e in uscita in base all'origine e alla destinazione del traffico di rete, ad esempio un intervallo di indirizzi IP. Per ulteriori informazioni, consulta [Controllo dell'accesso ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html).
## Creazione di una policy di endpoint VPC per Amazon EMR
Puoi creare una policy per gli endpoint di Amazon VPC per Amazon EMR per specificare quanto segue:
+ Il principale che può o non può eseguire azioni
+ Le azioni che possono essere eseguite
+ Le risorse sui cui si possono eseguire le azioni
Per ulteriori informazioni, consultare [Controllo degli accessi ai servizi con endpoint VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in *Guida per l'utente di Amazon VPC*.
**Example — Policy degli endpoint VPC per negare tutti gli accessi da un account specifico AWS**
La seguente politica degli endpoint VPC nega all' AWS account *123456789012* tutti gli accessi alle risorse che utilizzano l'endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example - Policy di endpoint VPC per consentire l'accesso VPC solo a un'entità principale IAM (utente) specificata**
La seguente politica degli endpoint VPC consente l'accesso completo solo a un utente *lijuan* nell'account. AWS *123456789012* A tutte le altre entità principali IAM viene negato l'accesso utilizzando l'endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/lijuan"
]
}
}]
}
```
**Example - Policy di endpoint VPC per consentire operazioni EMR di sola lettura**
La seguente policy sugli endpoint VPC consente solo *123456789012* all' AWS account di eseguire le azioni Amazon EMR specificate.
Le operazioni specificate forniscono l'accesso di sola lettura equivalente per Amazon EMR. Tutte le altre azioni sul VPC vengono negate per l'account specificato. A tutti gli altri account viene negato l'accesso. Per un elenco delle operazioni Amazon EMR, consulta [Operazioni, risorse e chiavi di condizione per Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors"
],
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example - Policy di endpoint VPC per negare l'accesso a un cluster specificato**
La seguente policy sugli endpoint VPC consente l'accesso completo a tutti gli account e i principali, ma nega qualsiasi accesso AWS dell'account *123456789012* alle azioni eseguite sul cluster Amazon EMR con ID cluster. *j-A1B2CD34EF5G* Altre operazioni Amazon EMR che non supportano le autorizzazioni a livello di risorsa per i cluster sono comunque consentite. Per l'elenco delle operazioni Amazon EMR e dei tipi di risorse corrispondenti, consulta [Operazioni, risorse e chiavi di condizione per Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "arn:aws:elasticmapreduce:us-west-2:123456789012:cluster/j-A1B2CD34EF5G",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```