Skip to main content

Utiliser le stockage d’objets Cloud sur AWS

La meilleure pratique pour permettre aux charges de travail de votre cluster EKS d’accéder aux services Cloud est d’utiliser des rôles IAM. Pour ArcGIS Enterprise, vous pouvez permettre l’accès au Cloud Object Store et aux Backup Stores de l’organisation dans les buckets AWS S3 via l’identité du pod ou le rôle IAM basé sur un groupe de nœuds.

Il est recommandé que votre organisation utilise l’identité des pods pour gérer l’authentification des charges de travail Kubernetes, car cela permet un contrôle très précis des autorisations accordées aux pods. Si votre organisation utilise un rôle IAM basé sur un groupe de nœuds pour contrôler les autorisations, il est recommandé de migrer vers l’utilisation d’identités de pod lors de la mise à jour ou de la mise à niveau.

Utiliser l’identité du pod EKS

ArcGIS Enterprise on Kubernetes utilise différents comptes de service pour les charges de travail en fonction des autorisations requises pour le serveur API Kubernetes. Ces comptes de service nécessitent également des autorisations différentes lors de l’accès aux services Cloud intégrés. Vous pouvez utiliser l’identité du pod pour créer une association entre chaque compte de service et un rôle IAM avec les autorisations requises.

Important :

Avant de déployer ArcGIS Enterprise on Kubernetes ou de créer d’autres dépendances dans AWS, l’extension EKS Pod Identity Agent doit être installée dans le cluster. Pour des instructions, reportez-vous à la rubrique Configurer Amazon EKS Pod Identity Agent.

Rôles et stratégies IAM

Avant de déployer et de configurer ArcGIS Enterprise on Kubernetes avec un Cloud Object Store et un Backup Store AWS S3, configurez les rôles et stratégies IAM suivants :

  • Accès en lecture-écriture à l’Object Store et aux Backup Stores

    {
    "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>"
            ]
        }
    ]
}

  • Accès en lecture-écriture au Cloud Object Store

    {
    "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>"
            ]
        }
    ]
}

  • Accès en lecture seule au Cloud Object Store

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

Des stratégies supplémentaires peuvent être créées sous chaque rôle IAM pour permettre l’accès aux buckets de stockage utilisateur en plus des Object et Backup Stores du système.

Associations d’identité de pod

Dans le cluster EKS, ajoutez des associations d’identité de pod pour associer chaque compte de service au rôle IAM approprié. Pour obtenir des instructions, reportez-vous à la rubrique de la documentation AWS Assigner un rôle IAM à un compte de service Kubernetes.

La table suivante répertorie le rôle IAM requis pour chaque compte de service :

Compte de service Rôle IAM
arcgis-admin-serviceaccount Accès en lecture-écriture à l’Object Store et aux Backup Stores
arcgis-disasterrecovery-serviceaccount Accès en lecture-écriture à l’Object Store et aux Backup Stores
arcgis-spatiotemporalindex-serviceaccount Accès en lecture-écriture à l’Object Store et aux Backup Stores
arcgis-cloudservice-readwrite-serviceaccount Accès en lecture-écriture au Cloud Object Store
arcgis-cloudservice-readonly-serviceaccount Accès en lecture seule au Cloud Object Store

Les noms de comptes de service dans la table reflètent le nom par défaut du site, arcgis. Si vous avez configuré un autre nom de site, ce nom sera utilisé comme préfixe de compte de service au lieu de arcgis. Consultez les paramètres actuels de votre organisation si vous n’êtes pas sûr du nom du site.

Utiliser le rôle IAM basé sur un groupe de nœuds

Si vous ne pouvez pas utiliser l’identité du pod, ArcGIS Enterprise on Kubernetes peut également utiliser un rôle IAM attribué au groupe de nœuds du cluster Kubernetes pour obtenir l’autorisation d’accéder aux services Cloud.

Attention :

Lorsque vous utilisez un rôle IAM basé sur un groupe de nœuds, toutes les charges de travail exécutées sur ces nœuds ont des autorisations équivalentes. Dans ce cas, certaines charges de travail disposeront d’autorisations dont elles n’ont pas besoin.

Pour utiliser le rôle IAM basé sur un groupe de nœuds, créez une stratégie combinée de lecture-écriture :

{
 "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>"
         ]
     }
 ]
}

Migrer vers l’identité du pod EKS

Les organisations qui utilisent un rôle IAM basé sur un groupe de nœuds devraient prévoir de migrer vers l’identité de pod EKS lors d’une mise à niveau ou d’une mise à jour de l’organisation. Cela minimise les perturbations, car tous les pods nécessitent un redémarrage après la création des associations d’identité de pod. Les pods sont redémarrés automatiquement lors des mises à jour et mises à niveau jour de l’organisation.

Pour migrer vers l’utilisation de l’identité de pod afin de contrôler les autorisations, procédez comme suit :

  1. Installez l’extension EKS Pod Identity Agent.

  2. Créez les rôles IAM requis et les associations d’identité de pod.

  3. Mettez à niveau ArcGIS Enterprise.

  4. Vérifiez que les services et les processus critiques sont fonctionnels.

  5. Supprimez la stratégie IAM du rôle IAM du groupe de nœuds qui permet l’accès au stockage S3.

  6. Vérifiez à nouveau que les services et les charges de travail critiques sont fonctionnels.

    Si un problème est détecté à cette étape, réajoutez la stratégie IAM d’origine au rôle IAM du groupe de nœuds. Vous retrouverez ainsi un système fonctionnel, tout en effectuant une révision approfondie du statut de l’extension, des rôles et stratégies IAM d’identité de pod, ainsi que des associations d’identité de pod.