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.
Tópicos
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.
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 *<admin users login>*:*_<_**_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://*<RANGER SERVER ADDRESS>*:6182/service/public/v2/api/servicedef'
Se esse comando for executado com êxito, você verá um novo serviço na interface do usuário do Ranger Admin chamado "AMAZON-EMR-S3“, conforme mostrado na imagem a seguir (a versão 2.0 do Ranger é mostrada).
Etapa 4: Crie uma instância do AMAZON-EMR-EMRFS aplicativo.
Crie uma instância da definição de serviço.
-
Clique no + 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.
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 para obter mais detalhes.
Quando o serviço é criado, o Service Manager inclui "AMAZON-EMR-EMRFS“, conforme mostrado na imagem a seguir.
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 para obter informações sobre práticas recomendadas. Os recursos no servidor Ranger Admin não devem conter s3://, s3a:// ou s3n://.
É possível especificar usuários e grupos para conceder permissões. Você também pode especificar exclusões para condições de permissão.
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.
exemplo 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.
exemplo 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 “*” e “?”. O “*” 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 “{USER}” que concede acesso a todos os usuários. O segundo caractere curinga é “{OWNER}”, que concede acesso direto ao proprietário de um objeto específico. No entanto, atualmente não há suporte para o curinga “{USER}”.
Limitações
Estas são as limitações atuais do plug-in EMRFS S3:
-
As políticas do Apache Ranger podem ter no máximo três recursos.
-
O acesso ao S3 deve ser feito por meio do EMRFS e pode ser usado com aplicativos. Hadoop-related 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 CSE-KMS criptografadas.
-
Cross-Region o suporte não é suportado.
-
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
. -
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.
