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á. # Plug-in EMRFS do S3 para integração do Ranger com o Amazon EMR Para facilitar o fornecimento de controles de acesso contra objetos no S3 em um cluster multilocatário, o plug-in EMRFS S3 fornece controles de acesso aos dados no S3 ao acessá-los pelo EMRFS. Você pode permitir acesso aos recursos do S3 em nível de usuário e grupo. Para conseguir isso, quando sua aplicação tenta acessar dados no S3, o EMRFS envia uma solicitação de credenciais ao processo do agente secreto, onde a solicitação é autenticada e autorizada em um plug-in Apache Ranger. Se a solicitação for autorizada, o agente secreto assumirá o perfil do IAM para os mecanismos do Apache Ranger com uma política restrita para gerar credenciais que só tenham acesso à política Ranger que permitiu o acesso. As credenciais então são repassadas ao EMRFS para acessar o S3. **Topics** + [Recursos compatíveis](#emr-ranger-emrfs-features) + [Instalação da configuração de serviço](#emr-ranger-emrfs-service-config) + [Criar políticas do EMRFS S3](#emr-ranger-emrfs-create-policies) + [Notas sobre o uso das políticas do EMRFS S3](#emr-ranger-emrfs-considerations) + [Limitações](#emr-ranger-emrfs-limitations) ## Recursos compatíveis O plug-in EMRFS S3 concede autorização de nível de armazenamento. Políticas podem ser criadas para conceder acesso a usuários e grupos a buckets e prefixos do S3. A autorização é feita somente em relação ao EMRFS. ## Instalação da configuração de serviço Para instalar a definição do serviço EMRFS, você deve configurar o servidor Ranger Admin. Para configurar o servidor, consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md). Siga estas etapas para instalar a definição de serviço do EMRFS. **Etapa 1: SSH no servidor Apache Ranger Admin**. Por exemplo: ``` ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal ``` **Etapa 2: download da definição do serviço EMRFS**. Em um diretório temporário, baixe a definição de serviço do Amazon EMR. Essa definição de serviço é compatível com as versões Ranger 2.x. ``` wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json ``` **Etapa 3: registrar a definição de serviço do S3 para EMRFS**. ``` 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 esse comando for executado com êxito, você verá um novo serviço na interface de usuário do Ranger Admin chamado “AMAZON-EMR-S3”, conforme mostrado na imagem a seguir (a versão 2.0 do Ranger é exibida). ![\[O Ranger Admin cria o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png) **Etapa 4: Crie uma instância do AMAZON-EMR-EMRFS aplicativo**. Crie uma instância da definição de serviço. + Clique no **\$1** ao lado de AMAZON-EMR-EMRFS. Preencha os seguintes campos: **Nome do serviço (se for exibido)**: o valor sugerido é **amazonemrs3**. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração de segurança do EMR. **Nome de exibição**: o nome exibido para o serviço. O valor sugerido é **amazonemrs3**. **Nome comum para certificado:** o campo CN dentro do certificado usado para se conectar ao servidor de administração com base em um plug-in cliente. Esse valor deve corresponder ao campo CN no certificado TLS criado para o plug-in. ![\[Ranger Admin edita o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png) **nota** O certificado TLS para o plug-in deveria ter sido registrado no armazenamento confiável do servidor Ranger Admin. Consulte [Certificados TLS para integração do Apache Ranger com o Amazon EMR](emr-ranger-admin-tls.md) para obter mais detalhes. Quando o serviço é criado, o Service Manager inclui “AMAZON-EMR-EMRFS”, conforme mostra a imagem a seguir. ![\[Ranger Admin mostrando o novo serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png) ## Criar políticas do EMRFS S3 Para criar uma nova política na página **Criar política** do Service Manager, preencha os campos a seguir. **Nome da política**: o nome da política. **Rótulo de política**: um rótulo que você pode colocar na política. **Recurso do S3**: um recurso que começa com o bucket e o prefixo opcional. Consulte [Notas sobre o uso das políticas do EMRFS S3](#emr-ranger-emrfs-considerations) para obter informações sobre práticas recomendadas. Os recursos no servidor Ranger Admin não devem conter **s3://**, **s3a://** ou **s3n://**. ![\[Administrador do Ranger mostrando a política de criação para o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png) É possível especificar usuários e grupos para conceder permissões. Também é possível especificar exclusões para condições de **permissão** e **negação**. ![\[Administrador do Ranger mostrando user/group permissões para a política do EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png) **nota** São permitidos no máximo três recursos por política. Adicionar mais de três recursos poderá resultar em um erro quando essa política é usada em um cluster do EMR. Adicionar mais de três políticas exibirá um lembrete sobre o limite da política. ## Notas sobre o uso das políticas do EMRFS S3 Ao criar políticas do S3 no Apache Ranger, atente para algumas considerações sobre o uso. ### Permissões para múltiplos objetos do S3 É possível usar políticas recursivas e expressões curinga para conceder permissões a vários objetos do S3 com prefixos comuns. As políticas recursivas concedem permissões a todos os objetos com um prefixo comum. As expressões curinga selecionam múltiplos prefixos. Juntos, eles concedem permissões a todos os objetos com múltiplos prefixos comuns, conforme mostrado nos exemplos a seguir. **Example Usar uma política recursiva** Suponha que você queira permissões para listar todos os arquivos parquet em um bucket do S3 organizado da forma a seguir. ``` 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 ``` Primeiro, considere os arquivos parquet que tenham o prefixo `s3://sales-reports/americas/year=2000`. Você pode conceder GetObject permissões a todos eles de duas maneiras: **Usar políticas não recursivas**: uma opção é usar duas políticas não recursivas separadas, uma para o diretório e outra para os arquivos. A primeira política concede permissão ao prefixo `s3://sales-reports/americas/year=2020` (não há `/` final). ``` - S3 resource = "sales-reports/americas/year=2000" - permission = "GetObject" - user = "analyst" ``` A segunda política usa a expressão curinga para conceder permissões a todos os arquivos com prefixo `sales-reports/americas/year=2020/` (observe o `/` final). ``` - S3 resource = "sales-reports/americas/year=2020/*" - permission = "GetObject" - user = "analyst" ``` **Usar uma política recursiva**: uma alternativa mais conveniente é usar uma única política recursiva e conceder permissão recursiva ao prefixo. ``` - S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` Até agora, apenas os arquivos parquet com o prefixo `s3://sales-reports/americas/year=2000` foram incluídos. Também já é possível incluir os arquivos parquet com outro prefixo, `s3://sales-reports/americas/year=2020`, na mesma política recursiva introduzindo uma expressão curinga da forma a seguir. ``` - S3 resource = "sales-reports/americas/year=20?0" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` ### Políticas PutObject e DeleteObject permissões Escrever políticas `PutObject` e `DeleteObject` permissões para arquivos no EMRFS precisa de cuidados especiais porque, diferentemente das GetObject permissões, elas precisam de permissões recursivas adicionais concedidas ao prefixo. **Example Políticas PutObject e DeleteObject permissões** Por exemplo, excluir o arquivo `annual-summary.parquet` requer não apenas uma DeleteObject permissão para o arquivo real. ``` - S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "DeleteObject" - user = "analyst" ``` Também requer uma política que conceda permissões `GetObject` e `PutObject` recursivas para o prefixo. Da mesma forma, modificar o arquivo `annual-summary.parquet` requer não apenas uma permissão `PutObject` para o arquivo real. ``` - S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "PutObject" - user = "analyst" ``` Também requer uma política que conceda a permissão `GetObject` recursiva para o prefixo. ``` - S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True" ``` ### Curingas em políticas Há duas áreas em que é possível especificar caracteres curingas. Ao especificar um recurso do S3, pode-se usar “\$1” e “?”. O “\$1” faz correspondência com um caminho do S3 e corresponde a tudo que está depois do prefixo. Por exemplo, a política a seguir. ``` S3 resource = "sales-reports/americas/*" ``` Isso corresponde aos caminhos do S3 a seguir. ``` 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 ``` O curinga “?” corresponde a apenas um caractere. Por exemplo, para a política. ``` S3 resource = "sales-reports/americas/year=201?/" ``` Isso corresponde aos caminhos do S3 a seguir. ``` sales-reports/americas/year=2019/ sales-reports/americas/year=2018/ sales-reports/americas/year=2017/ ``` ### Curingas em usuários Há dois curingas integrados ao atribuir usuários para fornecer acesso aos usuários. O primeiro é o curinga “\$1USER\$1” que concede acesso a todos os usuários. O segundo caractere curinga é “\$1OWNER\$1”, que concede acesso direto ao proprietário de um objeto específico. No entanto, atualmente não há suporte para o curinga “\$1USER\$1”. ## Limitações Estas são as limitações atuais do plug-in EMRFS S3: + As políticas do Apache Ranger podem conter no máximo três políticas. + O acesso ao S3 deve ser feito pelo EMRFS e pode ser usado com aplicações relacionadas ao Hadoop. Não há suporte para: - Bibliotecas Boto3 - AWS SDK e AWK CLI - Conector de código aberto S3A + Não há suporte para políticas de negação do Apache Ranger. + Atualmente, não há suporte para operações no S3 com chaves com criptografia do CSE-KMS. + O suporte entre regiões não é compatível. + Não há suporte para o atributo de zona de segurança do Apache Ranger. As restrições de controle de acesso definidas usando o atributo Security Zone não são aplicadas aos clusters do Amazon EMR. + O usuário do Hadoop não gera nenhum evento de auditoria, pois o Hadoop sempre acessa o perfil de instância do EC2. + É recomendável desabilitar a visualização consistente do Amazon EMR. O S3 do tem um alto nível de consistência e, portanto, isso não é mais necessário. Para obter mais informações, consulte [Amazon S3 strong consistency](https://aws.amazon.com/s3/consistency/). + O plug-in EMRFS S3 efetua várias chamadas STS. É recomendável fazer testes de carga em uma conta de desenvolvimento e monitorar o volume de chamadas do STS. Também é recomendável que você faça uma solicitação STS para aumentar os limites do AssumeRole serviço. + O servidor Ranger Admin não oferece suporte ao preenchimento automático.