Passer au contenu

Comment résoudre les erreurs 403 ou 401 que je reçois lorsque je me connecte à mon cluster ou à mes tableaux de bord OpenSearch sans serveur ?

Lecture de 6 minute(s)
0

Lorsque j'exécute les commandes de l'API OpenSearch sur mon cluster Amazon OpenSearch sans serveur ou que j'essaie d'accéder aux tableaux de bord, je reçois des erreurs 403 ou 401.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'interface.

Erreurs 403 Interdit

Un message d’erreur 403 Interdit apparaît généralement lorsque l'identité Gestion des identités et des accès AWS (AWS IAM) ne dispose pas des autorisations appropriées ou qu’elle inclut une requête incorrectement signée.

Lorsque vous activez la journalisation détaillée dans votre client ou que vous choisissez l'onglet Réseau sur la console IAM, le message d'erreur « x-aoss-response-hint': x-aoss-response-hint': » peut s’afficher.

Pour l'accès aux API de plan de données OpenSearch Dashboards et OpenSearch sans serveur, incluez les actions aoss:DashboardsAccessAll et aoss:APIAccessAll dans la politique d'autorisations de l'identité IAM. Pour consulter un exemple de politique, consultez la section Utilisation des opérations de l'API OpenSearch.

Pour l'accès aux API de plan de données OpenSearch sans serveur, une requête incorrectement signée peut également provoquer une erreur 403 Interdit. Après avoir vérifié que vos autorisations IAM sont correctes, examinez la manière dont votre client interagit avec les API OpenSearch.

Pour écrire une version simple de votre code, consultez la section Ingestion de données dans des collections Amazon OpenSearch sans serveur.

Utilisez curl pour tester votre point de terminaison à partir d'une instance Amazon Elastic Compute Cloud (Amazon EC2).

Exemple de commande curl qui ingère un enregistrement dans un index :

curl -XPOST \
    —user "$AWS_ACCESS_KEY_ID":"$AWS_SECRET_ACCESS_KEY" \
    —aws-sigv4 "aws:amz:us-east-1:aoss" \
    —header "x-amz-content-sha256: $REQUEST_PAYLOAD_SHA_HASH" \
    —header "x-amz-security-token: $AWS_SESSION_TOKEN" \
    "https://my-collection-endpoint.us-east-1.aoss.amazonaws.com/movies-index/_doc" \
    -H "Content-Type: application/json" -d '{"title": "Shawshank Redemption"}'

Remarque : Remplacez les exemples d'ID de clé d'accès, de clé secrète et de jeton de session par vos valeurs. Pour obtenir ces valeurs, exécutez la commande get-session-token de l'AWS CLI.

Si vous envoyez des données utiles, exécutez la commande suivante pour générer un algorithme de hachage sécurisé 256 bits (SHA-256) des données utiles dans les en-têtes :

echo -n '{"title": "Shawshank Redemption"}' | shasum -a 256

Vous pouvez également utiliser awscurl sur le site Web de GitHub. awscurl utilise vos informations d'identification par défaut, telles que votre profil d'instance EC2, de sorte que vous n'avez pas besoin de hacher les données utiles en tant qu'en-tête.

Exemples de requêtes awscurl :

awscurl --service aoss --region us-east-1 -XPOST \
    "https://my-collection-endpoint.us-east-1.aoss.amazonaws.com/movies-index/_doc" \
    -H "Content-Type: application/json" -d '{"title": "Shawshank Redemption"}'
awscurl --service aoss --region us-east-1 -XGET \
    "https://my-collection-endpoint.us-east-1.aoss.amazonaws.com/_cat/indices"

Remarque : Remplacez us-east-1 par votre région AWS et l'exemple de point de terminaison par votre point de terminaison.

Utilisez une journalisation détaillée pour confirmer que les en-têtes précédents font partie de la requête envoyée au service.Des signatures incorrectes se produisent en raison de valeurs d'en-tête incorrectes. Vous pouvez également utiliser la journalisation détaillée pour confirmer que votre point de terminaison de collecte, votre région et votre service sont corrects.

Autres erreurs 403

Selon l'action que vous effectuez, il est possible que vous receviez un message d'erreur 403 différent.

Pour les opérations d'ingestion spécifiques à un index, un message d'erreur similaire à « Authorization failure for the following indices: [index/collectionname/indexname] » (Échec d'autorisation pour les index suivants : [index/collectionname/indexname]) peut s'afficher.

Pour les demandes de recherche, un message d'erreur du type « all shards failed » (échec de toutes les partitions) ou « Bad Authorization » (Autorisation incorrecte) peut s'afficher.

Pour les opérations non spécifiques à l'index, un message d'erreur similaire au message « User does not have permissions for the requested resource » (L'utilisateur ne dispose pas des autorisations nécessaires pour la ressource demandée) peut s'afficher.

Pour résoudre ces erreurs, assurez-vous que la politique d'accès aux données de la collection contient les autorisations appropriées pour les ressources de collection et d'index. Assurez-vous également que la politique contient l'identité IAM correcte dans la section Principal.

Pour plus d'informations sur la syntaxe des politiques d'accès aux données, consultez la section Syntaxe de politique.

Erreurs 401 Non autorisé

Un message d'erreur 401 apparaît généralement lorsque la politique réseau refuse l'accès aux API OpenSearch sans serveur ou au tableau de bord.

Lorsque vous activez la journalisation détaillée dans votre client ou que vous consultez l'onglet Réseau de la console des développeurs du navigateur, le message d'erreur « x-aoss-response-hint': 'X01:network-policy-deny » peut s’afficher.

Pour accéder aux API OpenSearch sans serveur et au tableau de bord depuis Internet public, activez l'accès public dans la politique réseau.

Exemple de politique réseau au format JSON :

[
  {
    "Rules": [
      {
        "Resource": [
          "collection/collectionname"
        ],
        "ResourceType": "dashboard"
      },
      {
        "Resource": [
          "collection/collectionname"
        ],
        "ResourceType": "collection"
      }
    ],
    "AllowFromPublic": true
  }
]

Remarque : Remplacez collectionname par le nom de votre collection.

Pour un accès privé aux API et au tableau de bord, créez un point de terminaison de VPC dans le VPC client pour OpenSearch sans serveur.

Exemple de politique réseau au format JSON :

[
  {
    "Rules": [
      {
        "Resource": [
          "collection/collectionname"
        ],
        "ResourceType": "dashboard"
      },
      {
        "Resource": [
          "collection/collectionname"
        ],
        "ResourceType": "collection"
      }
    ],
    "AllowFromPublic": false,
    "SourceVPCEs": [
      "vpce-0c9xxxxxxxxxxa680"
    ]
  }
]

Remarque : Remplacez collectionname par le nom de votre collection.

Pour d'autres exemples de politiques réseau, consultez la section Accès réseau pour Amazon OpenSearch sans serveur.

Pour accéder à n'importe quel domaine OpenSearch sans serveur depuis un autre VPC, créez un point de terminaison de VPC OpenSearch sans serveur dans le VPC. Pour plus d’informations, consultez la section Accéder à Amazon OpenSearch sans serveur à l'aide d'un point de terminaison d'interface (AWS PrivateLink)

Remarque : Vous pouvez, si vous le souhaitez, demander à vos clients d'appeler les points de terminaison de l'API OpenSearch sans serveur depuis un VPC. Vous pouvez accéder aux tableaux de bord à partir de navigateurs qui utilisent l'Internet public.

Pour accéder en privé aux tableaux de bord depuis votre réseau d'entreprise, utilisez un point de terminaison de résolveur DNS entrant. La requête DNS renvoie l'adresse IP privée correcte. Pour plus d'informations, consultez la section Accéder à des collections Amazon OpenSearch sans serveur à l'aide d'un point de terminaison de VPC.

Informations connexes

Comment puis-je résoudre les problèmes d'accès aux tableaux de bord OpenSearch sans serveur pour consulter ma collection ?

AWS OFFICIELA mis à jour il y a un an