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.
EMRFSComplemento S3
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 EMRFS de ellos. Puede permitir el acceso a los recursos de usuarios y grupos de S3.
Para ello, cuando la aplicación intenta 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 está autorizada, el agente secreto asume el IAM papel de Apache Ranger Engines con una política restringida para generar credenciales que solo tienen acceso a la política de Ranger que permitió el acceso. Luego, las credenciales se devuelven para acceder EMRFS a S3.
Temas
Características admitidas
EMRFSEl complemento S3 proporciona autorización a nivel 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 solo en contraEMRFS.
Instalación de la configuración del servicio
Para instalar la definición de EMRFS servicio, debe configurar el servidor Ranger Admin. Para configurar el servidor, consulteConfiguración del servidor de Ranger Admin.
Siga estos pasos para instalar la definición EMRFS de servicio.
Paso 1: SSH en el servidor Apache Ranger Admin.
Por ejemplo:
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
Paso 2: Descargar la definición del EMRFS servicio.
En un directorio temporal, descarga la definición del EMR servicio de Amazon. 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 del servicio 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 interfaz de usuario de Ranger Admin llamado «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 EMRFS aplicación AMAZON - EMR -.
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 amazonemrspark. Anote el nombre de este servicio, ya que será necesario al crear una configuración EMR de seguridad.
Nombre público: el nombre que se muestra para este servicio. El valor sugerido es amazonemrspark.
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 TLS certificado que se creó para el complemento.
nota
El TLS certificado de este complemento debería haberse registrado en el almacén de confianza del servidor Ranger Admin. Consulte TLScertificados 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 EMRFSNotas de uso de las políticas de 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. EMR Al agregar más de tres políticas, se muestra un recordatorio sobre el límite de la política.
EMRFSNotas de uso de las políticas de 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 todas ellas 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
EMRFSEs preciso prestar especial atención a la redacción de políticas PutObject y DeleteObject permisos para los archivos, ya que, a diferencia de GetObject los permisos, es necesario conceder 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 permite el 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 se debe realizar a través de aplicaciones relacionadas con Hadoop EMRFS y se puede utilizar con ellas. No se admite lo siguiente:
― Bibliotecas Boto3
- y AWS SDK AWK CLI
― Conector de código abierto S3A
-
No se admiten las políticas de denegación de Apache Ranger.
-
Actualmente, no se admiten las CSE operaciones en S3 con claves KMS cifradas.
-
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 función Zona de seguridad no se aplican a tus EMR clústeres de Amazon.
-
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 Amazon EMR Consistency View. 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 STS llamadas. Se recomienda realizar pruebas de carga en una cuenta de desarrollo y controlar el volumen de STS llamadas. También se recomienda que realices una STS solicitud para aumentar los límites AssumeRole del servicio.
-
El servidor Ranger Admin no admite la función de autocompletar.
