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á.
EMRFSPlug-in S3
Para facilitar o fornecimento de controles de acesso contra objetos no S3 em um cluster multilocatário, o plug-in do EMRFS S3 fornece controles de acesso aos dados no S3 ao acessá-los por meio dele. EMRFS Você pode permitir acesso aos recursos do S3 em nível de usuário e grupo.
Para conseguir isso, quando seu aplicativo tenta acessar dados no S3, EMRFS envia uma solicitação de credenciais para o 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 assume a IAM função de Apache Ranger Engines com uma política restrita para gerar credenciais que só têm acesso à política Ranger que permitiu o acesso. As credenciais são então repassadas EMRFS para acessar o S3.
Tópicos
Atributos compatíveis
EMRFSO plug-in S3 fornece 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 contraEMRFS.
Instalação da configuração de serviço
Para instalar a definição do EMRFS serviço, você deve configurar o servidor Ranger Admin. Para configurar o servidor, consulteConfigurar o servidor do Ranger Admin.
Siga estas etapas para instalar a definição EMRFS de serviço.
Etapa 1: SSH no servidor Apache Ranger Admin.
Por exemplo:
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
Etapa 2: Baixe a definição do EMRFS serviço.
Em um diretório temporário, baixe a definição de EMR serviço da Amazon. 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 do serviço EMRFS S3.
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 EMRFS aplicativo AMAZON EMR - -.
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 é amazonemrspark. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração EMR de segurança.
Nome de exibição: o nome exibido para o serviço. O valor sugerido é amazonemrspark.
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 TLS certificado que foi criado para o plug-in.
nota
O TLS certificado desse plug-in deveria ter sido registrado no armazenamento confiável do servidor Ranger Admin. Consulte TLScertificados para obter mais detalhes.
Quando o serviço é criado, o Service Manager inclui "AMAZON- EMR - EMRFS “, conforme mostrado na imagem a seguir.
Criação de EMRFS políticas do 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 EMRFSNotas de uso das políticas do 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. Também é possível especificar exclusões para condições de permissão e negação.
nota
São permitidos no máximo três recursos por política. Adicionar mais de três recursos pode resultar em um erro quando essa política é usada em um EMR cluster. Adicionar mais de três políticas exibirá um lembrete sobre o limite da política.
EMRFSNotas de uso das políticas do 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 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 caractere curinga “{USER}” que fornece acesso a todos os usuários. O segundo caractere curinga é “{OWNER}”, que fornece acesso direto ao proprietário de um objeto específico. No entanto, o caractere curinga “{USER}” não é suportado atualmente.
Limitações
A seguir estã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 por meio de aplicativos relacionados ao Hadoop EMRFS e pode ser usado com eles. 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.
-
Operações no S3 com chaves com KMS criptografia CSE - atualmente não são suportadas.
-
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 recurso Security Zone não são aplicadas aos seus EMR clusters da Amazon.
-
O usuário do Hadoop não gera nenhum evento de auditoria, pois o Hadoop sempre acessa o Perfil da Instância. EC2
-
É recomendável que você desative o Amazon EMR Consistency View. 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 faz várias STS chamadas. É recomendável que você faça testes de carga em uma conta de desenvolvimento e monitore o volume de STS chamadas. Também é recomendável que você faça uma STS solicitação para aumentar os limites do AssumeRole serviço.
-
O servidor Ranger Admin não oferece suporte ao preenchimento automático.
