Skip to main content

Utilizar un almacén de objetos en la nube en AWS

La práctica recomendada para permitir que las cargas de trabajo de su clúster EKS accedan a servicios en la nube es utilizar roles de IAM. Para ArcGIS Enterprise, es posible permitir el acceso al almacén de objetos en la nube de la organización y a los almacenes de copias de seguridad en buckets de AWS S3 mediante la identidad del pod o un rol de IAM basado en un grupo de nodos.

Se recomienda que su organización utilice la identidad de pod para gestionar la autenticación de cargas de trabajo de Kubernetes, ya que permite el control más detallado de los permisos concedidos a los pods. Si su organización utiliza un rol de IAM basado en grupos de nodos para controlar los permisos, se recomienda que migre al uso de identidades de pod cuando actualice o realice una mejora.

Usar la identidad del pod de EKS

ArcGIS Enterprise on Kubernetes utiliza diferentes cuentas de servicio para cargas de trabajo según los permisos necesarios para el servidor API de Kubernetes. Estas cuentas de servicio también requieren diferentes permisos al acceder a servicios en la nube integrados. Es posible utilizar la identidad del pod para crear una asociación entre cada cuenta de servicio y un rol de IAM con los permisos necesarios.

Importante:

Antes de implementar ArcGIS Enterprise on Kubernetes o crear otras dependencias en AWS, el complemento agente de identidad del pod de EKS se debe instalar en el clúster. Para las instrucciones, consulte Configurar el agente de identidad del pod de Amazon EKS.

Roles y políticas de IAM

Antes de implementar y configurar ArcGIS Enterprise on Kubernetes con un almacén de objetos en la nube AWS S3 y un almacén de copias de seguridad, configure los siguientes roles y políticas de IAM:

  • Acceso de lectura y escritura al almacenamiento de objetos en la nube y almacenes de copias de seguridad

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetLifecycleConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:ListMultipartUploadParts",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>",
                "arn:aws:s3:::<backupStoreBucket>/*",
                "arn:aws:s3:::<backupStoreBucket>"
            ]
        }
    ]
}

  • Acceso de lectura y escritura al almacenamiento de objetos en la nube

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetLifecycleConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:ListMultipartUploadParts",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>"
            ]
        }
    ]
}

  • Acceso de solo lectura al almacenamiento de objetos en la nube

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>"
            ]
        }
    ]
}
Nota:

Se pueden crear políticas adicionales bajo cada rol de IAM para permitir el acceso a los depósitos de almacenamiento de usuario además de los almacenes de objetos del sistema y de copia de seguridad.

Asociaciones de identidad de pod

Dentro del clúster EKS, agregue asociaciones de identidad de pod para asignar cada cuenta de servicio al rol de IAM apropiado. Para las instrucciones, consulte el tema de documentación de AWS Asignar un rol de IAM a una cuenta de servicio de Kubernetes.

La siguiente tabla muestra el rol de IAM requerido para cada cuenta de servicio:

Cuenta de servicio Rol de IAM
arcgis-admin-serviceaccount Acceso de lectura y escritura a objetos en la nube y almacenes de copias de seguridad
arcgis-disasterrecovery-serviceaccount Acceso de lectura y escritura a objetos en la nube y almacenes de copias de seguridad
arcgis-spatiotemporalindex-serviceaccount Acceso de lectura y escritura a objetos en la nube y almacenes de copias de seguridad
arcgis-cloudservice-readwrite-serviceaccount Acceso de lectura y escritura al almacenamiento de objetos en la nube
arcgis-cloudservice-readonly-serviceaccount Acceso de solo lectura al almacenamiento de objetos en la nube

Los nombres de cuentas de servicio en la tabla reflejan el nombre predeterminado del sitio, arcgis. Si configuró otro nombre de sitio, ese nombre se utilizará como prefijo de la cuenta de servicio en lugar de arcgis. Consulte la configuración actual de su organización si no está seguro del nombre del sitio de su organización.

Utilice un rol de IAM basado en grupos de nodos

Si no puede usar la identidad del pod, ArcGIS Enterprise en Kubernetes también puede usar un rol IAM asignado al grupo de nodos del clúster Kubernetes para obtener permisos para acceder a servicios en la nube.

Precaución:

Cuando se utiliza un rol de IAM basado en un grupo de nodos, todas las cargas de trabajo que se ejecutan en esos nodos tienen permisos equivalentes. Esto hace que algunas cargas de trabajo tengan permisos que no requieren.

Para utilizar el rol de IAM basado en grupos de nodos, cree una única política combinada de lectura y escritura:

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Effect": "Allow",
         "Action": [
             "s3:PutObject",
             "s3:GetObject",
             "s3:ListBucket",
             "s3:DeleteObject",
             "s3:GetLifecycleConfiguration",
             "s3:PutLifecycleConfiguration",
             "s3:ListMultipartUploadParts",
             "s3:GetBucketLocation",
             "s3:AbortMultipartUpload"
         ],
         "Resource": [
             "arn:aws:s3:::<systemObjectStoreBucket>/*",
             "arn:aws:s3:::<systemObjectStoreBucket>",
             "arn:aws:s3:::<backupStoreBucket>/*",
             "arn:aws:s3:::<backupStoreBucket>"
         ]
     }
 ]
}

Migrar a la identidad del pod de EKS

Las organizaciones que usan un rol de IAM basado en grupos de nodos deben planificar migrar a la identidad del pod EKS durante una actualización o una mejora de la organización. Con ello, se minimiza la interrupción porque todos los pods requieren un reinicio después de crear las asociaciones de identidad del pod. Los pods se reinician automáticamente durante las mejoras y actualizaciones de la organización.

Complete los siguientes pasos para migrar a usar la identidad del pod para controlar los permisos:

  1. Instale el complemento agente de identidad del pod de EKS.

  2. Cree los roles de IAM necesarios y las asociaciones de identidad de los pods.

  3. Actualice ArcGIS Enterprise.

  4. Verifique que los servicios y los flujos de trabajo críticos estén funcionando.

  5. Elimine la política de IAM del rol de IAM del grupo de nodos que permite el acceso al almacenamiento de S3.

  6. Vuelva a verificar que los servicios y las cargas de trabajo críticas estén funcionando.

    Si se detecta un problema en este paso, vuelva a agregar la política de IAM original al rol de IAM del grupo de nodos. Esto le permitirá recuperar la funcionalidad mientras consulta más a fondo el estado del complemento, los roles de IAM de la identidad del pod y las políticas, así como las asociaciones de la identidad del pod.