Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Complemento EMRFS S3 para la integración de Ranger con Amazon EMR
Para facilitar los controles de acceso a los objetos de S3 en un clúster multiusuario, el complemento EMRFS S3 proporciona controles de acceso a los datos de S3 cuando se accede a ellos a través de EMRFS. Puede permitir el acceso a los recursos de usuarios y grupos de S3.
Para ello, cuando su aplicación intente acceder a los datos de S3, EMRFS envía una solicitud de credenciales al proceso del agente secreto, donde la solicitud se autentica y autoriza mediante un complemento de Apache Ranger. Si la solicitud se autoriza, el agente secreto asume el rol de IAM para los motores Apache Ranger con una política restringida para generar credenciales que solo tienen acceso a la política de Ranger que permitió el acceso. A continuación, las credenciales se devuelven a EMRFS para acceder a S3.
Temas
Características admitidas
El complemento EMRFS S3 proporciona autorización de almacenamiento. Se pueden crear políticas para proporcionar acceso a los usuarios y grupos a los buckets y prefijos de S3. La autorización se realiza únicamente para EMRFS.
Instalación de la configuración del servicio
Para instalar la definición del servicio EMRFS, debe configurar el servidor Ranger Admin. Para configurar el servidor, consulte Configure un servidor Ranger Admin para integrarlo con Amazon EMR.
Siga estos pasos para instalar la definición de servicio de EMRFS.
Paso 1: inicie sesión mediante SSH en el servidor de Apache Ranger Admin.
Por ejemplo:
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
Paso 2: descargue la definición del servicio de EMRFS.
En un directorio temporal, descargue la definición de servicio de Amazon EMR. Esta definición de servicio es compatible con las versiones 2.x de Ranger.
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json
Paso 3: registre la definición de servicio de 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'
Si este comando se ejecuta correctamente, verá un nuevo servicio en la IU de Ranger Admin denominado “AMAZON-EMR-S3”, como se muestra en la siguiente imagen (se muestra la versión 2.0 de Ranger).
Paso 4: Crea una instancia de la AMAZON-EMR-EMRFS aplicación.
Cree una instancia de la definición de servicio.
-
Haga clic en el signo + situado junto a AMAZON-EMR-EMRFS.
Rellene los siguientes campos:
Nombre del servicio (si se muestra): el valor sugerido es amazonemrs3. Anote el nombre de este servicio, ya que será necesario al crear una configuración de seguridad de EMR.
Nombre público: el nombre que se muestra para este servicio. El valor sugerido es amazonemrs3.
Nombre común del certificado: el campo CN (Nombre común) del certificado que se utiliza para conectarse al servidor de administración desde un complemento cliente. Este valor debe coincidir con el campo CN del certificado TLS que se creó para el complemento.
nota
El certificado TLS de este complemento debería haberse registrado en el almacén de confianza del servidor Ranger Admin. Consulte Certificados TLS para la integración de Apache Ranger con Amazon EMR para obtener más detalles.
Cuando se crea el servicio, el administrador de servicios incluye “AMAZON-EMR-EMRFS”, como se muestra en la siguiente imagen.
Creación de políticas de EMRFS S3
Para crear una nueva política en la página Crear política del administrador de servicios, rellene los siguientes campos.
Nombre de la política: el nombre de la política.
Etiqueta de la política: una etiqueta que puede poner en esta política.
Recurso de S3: un recurso que comienza con el bucket y el prefijo opcional. Consulte Notas de uso de las políticas de EMRFS S3 para obtener más información sobre las prácticas recomendadas. Los recursos del servidor Ranger Admin no deben contener s3://, s3a:// ni s3n://.
Puede especificar los usuarios y grupos a los que conceder permisos. También puede especificar exclusiones para las condiciones de autorización y denegación.
nota
Se permite un máximo de tres recursos para cada política. Agregar más de tres recursos puede provocar un error cuando se usa esta política en un clúster de EMR. Al agregar más de tres políticas, se muestra un recordatorio sobre el límite de la política.
Notas de uso de las políticas de EMRFS S3
Al crear políticas de S3 en Apache Ranger, hay que tener en cuenta algunas consideraciones de uso.
Permisos para varios objetos de S3
Puede utilizar políticas recursivas y expresiones comodín para conceder permisos a varios objetos de S3 con prefijos comunes. Las políticas recursivas otorgan permisos a todos los objetos con un prefijo común. Las expresiones comodín seleccionan varios prefijos. En conjunto, otorgan permisos a todos los objetos con varios prefijos comunes, como se muestra en los ejemplos siguientes.
ejemplo Uso de una política recursiva
Supongamos que desea obtener permisos para enumerar todos los archivos Parquet de un bucket de S3 organizados de la siguiente manera.
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
En primer lugar, considere los archivos Parquet con el prefijo s3://sales-reports/americas/year=2000. Puede conceder GetObject permisos a todos ellos de dos maneras:
Uso de políticas no recursivas: una opción es utilizar dos políticas no recursivas independientes, una para el directorio y otra para los archivos.
La primera política concede permiso al prefijo s3://sales-reports/americas/year=2020 (no hay ningún / final).
- S3 resource = "sales-reports/americas/year=2000" - permission = "GetObject" - user = "analyst"
La segunda política utiliza una expresión comodín para conceder permisos a todos los archivos con prefijo sales-reports/americas/year=2020/ (tenga en cuenta el / final).
- S3 resource = "sales-reports/americas/year=2020/*" - permission = "GetObject" - user = "analyst"
Uso de una política recursiva: una alternativa más práctica consiste en utilizar una única política recursiva y conceder permisos recursivos al prefijo.
- S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True"
Hasta ahora, solo se han incluido los archivos Parquet con el prefijo s3://sales-reports/americas/year=2000. Ahora también puede incluir los archivos Parquet con un prefijo diferente, s3://sales-reports/americas/year=2020, en la misma política recursiva introduciendo una expresión comodín como la siguiente.
- S3 resource = "sales-reports/americas/year=20?0" - permission = "GetObject" - user = "analyst" - is recursive = "True"
Políticas PutObject y DeleteObject permisos
La redacción de políticas PutObject y DeleteObject permisos para los archivos en EMRFS requiere un cuidado especial porque, a diferencia de GetObject los permisos, requieren la concesión de permisos recursivos adicionales al prefijo.
ejemplo Políticas y permisos PutObject DeleteObject
Por ejemplo, para eliminar el archivo no solo se annual-summary.parquet requiere un DeleteObject permiso para acceder al archivo real.
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "DeleteObject" - user = "analyst"
También requiere una política que conceda permisos PutObject y GetObject recursivos a su prefijo.
Del mismo modo, modificar el archivo annual-summary.parquet no solo requiere un permiso PutObject para ese archivo concreto.
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "PutObject" - user = "analyst"
También requiere una política que conceda permisos GetObject recursivos a su prefijo.
- S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True"
Comodines en las políticas
Hay dos áreas en las que se pueden especificar los caracteres comodín. Al especificar un recurso de S3, los caracteres “*” y “?” se puede utilizar. El asterisco “*” sustituye una ruta de S3 y coincide con todo lo que aparece después del prefijo. Tome la siguiente política como ejemplo:
S3 resource = "sales-reports/americas/*"
Esto coincide con las siguientes rutas de 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
El comodín “?” coincide con cualquier carácter individual. Tome la siguiente política como ejemplo:
S3 resource = "sales-reports/americas/year=201?/"
Esto coincide con las siguientes rutas de S3.
sales-reports/americas/year=2019/ sales-reports/americas/year=2018/ sales-reports/americas/year=2017/
Comodines en los usuarios
Hay dos caracteres comodín integrados al asignar usuarios para proporcionar acceso a los usuarios. El primero es el comodín “{USER}”, que proporciona acceso a todos los usuarios. El segundo comodín es “{OWNER}”, que proporciona acceso al propietario de un objeto concreto o directamente. Sin embargo, actualmente no se admite el comodín “{USER}”.
Limitaciones
Las siguientes son las limitaciones actuales del complemento EMRFS S3:
-
Las políticas de Apache Ranger pueden tener como máximo tres políticas.
-
El acceso a S3 debe realizarse a través de EMRFS y se puede utilizar con aplicaciones relacionadas con Hadoop. No se admite lo siguiente:
― Bibliotecas Boto3
- AWS SDK y CLI de AWK
― Conector de código abierto S3A
-
No se admiten las políticas de denegación de Apache Ranger.
-
Actualmente, no se admiten las operaciones en S3 con claves con cifrado CSE-KMS.
-
No se admite la compatibilidad entre regiones.
-
La característica Zona de seguridad de Apache Ranger no es compatible. Las restricciones de control de acceso definidas mediante la característica Zona de seguridad no se aplican a los clústeres de Amazon EMR.
-
El usuario de Hadoop no genera ningún evento de auditoría, ya que Hadoop siempre accede al perfil de la instancia. EC2
-
Se recomienda deshabilitar la visión de consistencia de Amazon EMR. S3 de tiene un alto grado de consistencia, por lo que ya no es necesario. Consulte Amazon S3 strong consistency
para obtener más información. -
El complemento EMRFS S3 realiza numerosas llamadas STS. Se recomienda realizar pruebas de carga en una cuenta de desarrollo y supervisar el volumen de llamadas STS. También se recomienda realizar una solicitud de STS para aumentar los límites del servicio. AssumeRole
-
El servidor Ranger Admin no admite la característica de autocompletar.
