用于CodeBuild集成的AWS Elastisearch访问策略使用Hibernate搜索使用ElasticSearch进行索引存储搜索

Question

我想启动一个CodeBuild项目来运行我的集成测试。我的应用程序使用AWS ElasticSearch服务作为Hibernate Search索引存储。

我已经向我的ES域添加了一个策略，允许私有EC2实例通过NAT网关访问ES。不幸的是，我无法想出允许CodeBuild访问ES的正确策略。当我运行CodeBuild项目时，当Hibernate尝试检查索引存在时，我得到一个403错误。

Caused by: org.hibernate.search.exception.SearchException: HSEARCH400007: Elasticsearch request failed. 
Request: 
Operation: IndicesExists 
URI:com.mycompany.myproject.model.tenant 
Data: 
null 
Response: 
========= 
Status: 403 
Error message: 403 Forbidden 
Cluster name: null 
Cluster status: null 

我试图配置ES访问策略，以允许开放接入域，然后测试运行正常（“AWS”：“*”）。

这是ES访问策略

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "arn:aws:iam::AWS_ACCOUNT_ID:role/CodeBuildRole-XXXXXXXX" 
     }, 
     "Action": "es:*", 
     "Resource": "arn:aws:es:eu-west-1:AWS_ACOUNT_ID:domain/elastic-search-domain/*"  
    }, 
    { 
    "Effect": "Allow", 
    "Principal": { 
     "AWS": "*" 
    }, 
    "Action": "es:*", 
    "Resource": "arn:aws:es:eu-west-1:AWS_ACCOUNT_ID:domain/elastic-search-domain/*", 
    "Condition": { 
     "IpAddress": { 
     "aws:SourceIp": "NAT_GW_IP" 
     } 
    } 
    } 
    ] 
} 

为主要我也试过如下：

"arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/CodeBuildRole-XXXXXXXXX/*" "arn:aws:iam::AWS_ACCOUNT_ID:role/CodeBuildRole-XXXXXXXXX" "arn:aws:iam::AWS_ACCOUNT_ID:root" "arn:aws:iam::AWS_ACCOUNT_ID:user/MI_USER_ADMIN"

任何帮助将是非常赞赏。

谢谢

Answer 1

可能您需要签署您的ES请求。

我对CodeBuild并不熟悉，但通常规则是：当使用IAM角色访问Elasticsearch时，您的请求需要使用该IAM角色进行签名。

E.g.对于Python你会使用这样的工具：https://github.com/DavidMuller/aws-requests-auth

更多信息：http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html

Answer 2

我想延长VME答案更精确。

要使用角色访问ElasticSearch，必须对请求进行签名。

此解决方案通常是正确的，但在我的特殊情况下，这不适合，因为对AWS ES的请求是由Hibernate Search ElasticSearch生成的。 （我们是否可以找到另一种使用AOP的解决方案？）

我终于想出了解决此问题的解决方法。在CodeBuild构建规范中，我添加了以下步骤：

• 使用具有允许他读取和更新ES域的策略的用户配置AWS CLI。
• 读取并存储当前ES域访问策略
• 我得到的CodeBuild EC2 IP
• 更新ES域策略的访问，以允许从CodeBuild IP接入
• 等待改变应用（15分钟aprox的）
• 运行测试
• 恢复以前的配置

我不喜欢这种解决方案非常多，因为域策略更新时间过LON G。这一步是持续集成CodePipeline的一部分，执行时间不应超过15或20分钟。

有关如何改进这一点的任何想法？