As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Considerações e limitações do Amazon EMR com a integração do Centro de Identidade Considere os seguintes pontos ao usar o Centro de Identidade do IAM com o Amazon EMR: + A propagação de identidade confiável por meio do Centro de Identidade é compatível com o Amazon EMR 6.15.0 e versões superiores, somente com o Apache Spark. Além disso, a propagação de identidade confiável por meio do Identity Center usando o recurso de perfis de runtime do EMR é compatível com o Amazon EMR 7.8.0 e versões superiores, e somente com o Apache Spark. + Para habilitar clusters do EMR com propagação de identidade confiável, você deve usar o AWS CLI para criar uma configuração de segurança que tenha a propagação de identidade confiável ativada e usar essa configuração de segurança ao iniciar seu cluster. Para obter mais informações, consulte [Criação de uma configuração de segurança habilitada para o Centro de Identidade](emr-idc-start.md#emr-idc-start-securityconfig). + Controles de acesso refinados AWS Lake Formation que usam o Trusted Identity Propagation estão disponíveis para clusters do Amazon EMR na versão 7.2.0 e superior do EMR. Entre as versões 6.15.0 e 7.1.0 do EMR, somente o controle de acesso em nível de tabela, baseado no Lake Formation, está disponível. AWS + Com clusters do Amazon EMR que usam a Propagação de identidade confiável, as operações que oferecem suporte ao controle de acesso baseado no Lake Formation com o Apache Spark incluem SELECT, ALTER TABLE, INSERT INTO e DROP TABLE. + Controles de acesso refinados AWS Lake Formation que usam o Trusted Identity Propagation precisarão atualizar a configuração do Lake Formation Identity Center adicionando o aplicativo IAM Identity gerenciado pelo EMR, arn, como alvo autorizado. Você pode encontrar o ARN da aplicação de identidade do IAM gerenciada pelo Amazon EMR chamando a API `describe-security-configure` do EMR e procurando o campo `IdCApplicationARN`. Mais detalhes: [Atualizar a integração com o Centro de Identidade do IAM](https://docs.aws.amazon.com/lake-formation/latest/dg/update-lf-identity-center-connection.html) sobre como configurar o Lake Formation com a configuração do Centro de Identidade do IAM. + Para usar controles de acesso refinados usando AWS Lake Formation o Trusted Identity Propagation, os usuários do IAM Identity devem receber permissões do Lake Formation no banco de dados padrão. Mais detalhes: [Configurar o Lake Formation para um cluster EMR habilitado para o Centro de Identidade do IAM](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html). + A propagação de identidade confiável com o Amazon EMR é suportada no seguinte: Regiões da AWS + `af-south-1`: África (Cidade do Cabo) + `ap-east-1`: Ásia-Pacífico (Hong Kong) + `ap-northeast-1`: Ásia-Pacífico (Tóquio) + `ap-northeast-2`: Ásia-Pacífico (Seul) + `ap-northeast-3`: Asia Pacific (Osaka) + `ap-south-1`: Ásia-Pacífico (Mumbai) + `ap-south-2`: Ásia-Pacífico (Hyderabad) + `ap-southeast-1`: Ásia-Pacífico (Singapura) + `ap-southeast-2`: Ásia-Pacífico (Sydney) + `ap-southeast-3`: Ásia-Pacífico (Jacarta) + `ap-southeast-4`: Ásia-Pacífico (Melbourne) + `ca-central-1`: Canadá (Central) + `eu-central-1`: Europa (Frankfurt) + `eu-central-2`: Europa (Zurique) + `eu-north-1`: Europa (Estocolmo) + `eu-south-1`: Europa (Milão) + `eu-south-2`: Europa (Espanha) + `eu-west-1`: Europa (Irlanda) + `eu-west-2`: Europa (Londres) + `eu-west-3`: Europa (Paris) + `il-central-1`: Israel (Tel Aviv) + `me-central-1`: Oriente Médio (EAU) + `me-south-1`: Oriente Médio (Bahrein) + `sa-east-1`: América do Sul (São Paulo) + `us-east-1`: Leste dos EUA (Norte da Virgínia) + `us-east-2`: Leste dos EUA (Ohio) + `us-west-1`: Oeste dos EUA (Norte da Califórnia) + `us-west-2`: Oeste dos EUA (Oregon) + Se a função do IAM para a função do centro de identidade for excluída e recriada acidentalmente, o principal terá uma ID principal diferente. O exemplo *NewRole* teria principal-id *456* que não corresponderia ao principal-id registrado. *123* A única maneira de resolver isso neste momento é redefinir o principal nas políticas de recursos downstream em cada conta downstream.