Stratégie d'accès basée sur les rôles IAM d'AWS Elasticsearch Service
J'ai eu du mal à comprendre comment communiquer avec le service Amazon ES à partir de mes instances EC2.
La documentation indique clairement que le service Amazon ES prend en charge les stratégies d'accès basées sur les utilisateurs et les rôles IAM. http://docs.aws.Amazon.com/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-access-policies
Cependant, lorsque j'ai cette politique d'accès pour mon domaine ES:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789:role/my-ec2-role"
},
"Action": "es:*",
"Resource": "arn:aws:es:us-west-2:123456789:domain/myDomain/*"
}
]
}
Je ne peux pas me connecter à une instance ec2 et exécuter une boucle pour atteindre mon cluster elasticsearch.
Essayer de faire une boucle simple de l'API _search:
curl "http://search-myDomain.es.amazonaws.com/_search"
Produit une réponse d'erreur d'authentification:
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: arn:aws:es:us-west-2:123456789:domain/myDomain/_search"}
Juste pour être plus sûr, j'ai mis la politique AmazonESFullAccess sur mon rôle IAM, ne fonctionne toujours pas.
Je dois manquer quelque chose, car être capable d'interagir par programmation avec Elasticsearch à partir d'instances ec2 qui utilisent un rôle IAM est essentiel pour que tout soit accompli avec Amazon ES Service.
Je vois également cette déclaration contradictoire dans les documents.
Exemple de stratégie basée sur IAM Vous créez des stratégies d'accès basées sur IAM en utilisant la console AWS IAM plutôt que la console Amazon ES. Pour plus d'informations sur la création de stratégies d'accès basées sur IAM, consultez la documentation IAM.
Ce lien vers la documentation IAM se trouve sur la page d'accueil d'IAM et contient exactement zéro information sur la façon de le faire. Quelqu'un a une solution pour moi?
Lorsque vous utilisez le service IAM avec AWS, vous devez signer vos demandes. curl ne prend pas en charge les demandes signées (qui consiste à hacher la demande et à ajouter un paramètre à l'en-tête de la demande). Vous pouvez utiliser l'un de leurs SDK avec l'algorithme de signature intégré, puis soumettre cette demande.
Vous pouvez trouver les SDK pour les langues populaires ici: http://aws.Amazon.com/tools/
Tout d'abord, vous avez dit que vous ne pouvez pas vous connecter à une instance EC2 pour boucler l'instance ES? Vous ne pouvez pas vous connecter? Ou vous ne pouvez pas le boucler depuis EC2?
J'ai mon instance Elasticsearch (Service) ouverte sur le monde (sans rien dessus) et je peux la boucler très bien, sans signer. J'ai changé la politique d'accès pour tester, mais malheureusement, il faut une éternité pour revenir après l'avoir changé ...
Ma politique ressemble à ceci:
{ "Version": "2012-10-17", "Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "es:*",
"Resource": "arn:aws:es:us-east-1:843348267853:domain/myDomain/*"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "es:*",
"Resource": "arn:aws:es:us-east-1:843348267853:domain/myDomain"
}
]
}
Je réalise que ce n'est pas exactement ce que vous voulez, mais commencez par cela (ouvert sur le monde), détendez-vous de l'extérieur d'AWS et testez-le. Ensuite, limitez-le, de cette façon, vous pouvez isoler les problèmes.
De plus, je pense que vous avez un problème avec le "Principal" dans votre politique d'accès. Vous avez votre rôle EC2. Je comprends pourquoi vous faites cela, mais je pense que le directeur a besoin d'un UTILISATEUR, pas d'un rôle.
Voir ci-dessous:
Principal
Spécifie le compte AWS ou l'utilisateur IAM qui est autorisé ou refusé l'accès à une ressource. La spécification d'un caractère générique (*) permet un accès anonyme au domaine, ce qui n'est pas recommandé. Si vous activez l'accès anonyme, nous vous recommandons fortement d'ajouter une condition basée sur IP pour restreindre les adresses IP qui peuvent envoyer des demandes au domaine Amazon ES.
EDIT 1
Pour être clair, vous avez ajouté la stratégie AmazonESFullAccess au rôle my-ec2? Si vous allez utiliser des stratégies d'accès IAM, je ne pense pas que vous puissiez avoir une stratégie basée sur les ressources qui lui est attachée (ce que vous faites).
http://docs.aws.Amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html
Pour certains services AWS, vous pouvez accorder un accès entre comptes à vos ressources. Pour ce faire, vous attachez une stratégie directement à la ressource que vous souhaitez partager, au lieu d'utiliser un rôle en tant que proxy. La ressource que vous souhaitez partager doit prendre en charge les stratégies basées sur les ressources. Contrairement à une stratégie basée sur l'utilisateur, une stratégie basée sur les ressources spécifie qui (sous la forme d'une liste de numéros d'identification de compte AWS) peut accéder à cette ressource.
Essayez peut-être de supprimer complètement la politique d'accès?
Pourquoi vous ne créez pas de proxy avec une IP élastique et autorisez votre proxy à accéder à votre ES? Fondamentalement, il existe trois formulaires dont vous pouvez limiter l'accès dans votre ES:
- Autoriser tout le monde
- Liste IP blanche
- Signature de la clé d'accès et de la clé secrète fournies par AWS.
J'utilise deux formulaires, dans mes applications php, je préfère utiliser un proxy derrière la connexion à ES et dans mon application nodejs, je préfère signer mes demandes en utilisant le module de nœud http-aws-es. Il est utile de créer un environnement proxy car mes utilisateurs doivent accéder à l'interface kibana pour voir certains rapports et c'est possible car ils ont configuré le proxy dans leurs navigateurs =)
Je dois vous recommander de fermer l'accès à vos index ES, car il est assez facile de les supprimer, curl -XDELETE https: // your_es_address/index tout le monde peut le faire mais vous pouvez dire: "comment le d'autres utilisateurs obtiendront mon adresse ES? " et je vous répondrai: "La sécurité basée sur la noirceur n'est pas une vraie sécurité"
Ma politique d'accès de sécurité est essentiellement quelque chose comme ça:
J'ai rencontré ce problème récemment et le problème racine est qu'aucun des SDK Amazon ne prend en charge les appels à des opérations Elasticsearch comme la recherche, la mise, etc.
La seule solution de contournement pour le moment consiste à exécuter des demandes directement sur le point de terminaison à l'aide de demandes signées: http://docs.aws.Amazon.com/general/latest/gr/sigv4-signed-request-examples.html
L'exemple ici est pour appeler EC2, mais il peut être modifié pour appeler à la place contre Elasticsearch. Modifiez simplement la valeur "service" en "es". De là, vous devez remplir des valeurs pour
- le point de terminaison (qui est l'URL complète de votre cluster, y compris l'opération sans paramètres de demande)
- l'hôte (la partie entre https: // et votre URI canonique comme/_status
- l'URI canonique qui est l'URI après le premier/inclusif (comme/_status) mais sans la chaîne de requête
- les paramètres de la demande (tout après? inclus)
Notez que je n'ai réussi à faire fonctionner cela jusqu'à présent qu'en utilisant les informations d'identification AWS car l'hypothèse est que vous transmettez une clé d'accès et une clé secrète aux différents appels de signature (access_key et secret_key dans l'exemple). Il devrait être réalisable en utilisant des rôles IAM mais vous devrez d'abord appeler le service de jeton de sécurité pour obtenir des informations d'identification temporaires qui peuvent être utilisées pour signer la demande. . Jusqu'à ce que vous fassiez cela, assurez-vous de modifier votre stratégie d'accès sur le cluster Elasticsearch pour autoriser les crédits utilisateur (utilisateur /