用於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分鐘。

有關如何改進這一點的任何想法？