使用Cloudfront以只读方式公开ElasticSearch REST API(GET/HEAD)

ssc*_*zio 15 rest http amazon-web-services elasticsearch amazon-cloudfront

我想让我的客户直接与ElasticSearch REST API对话,显然阻止他们执行任何数据或配置更改.

我看了一下ElasticSearch REST接口,我注意到了这种模式:HTTP GET请求非常安全(无害查询和集群状态).

所以我认为我可以将Cloudfront用作仅允许GET/HEAD方法的CDN /代理(您可以将其限制在主配置中).

到目前为止一切都很好,一切都已成立.但事情不起作用,因为我需要向全世界开放我的EC2安全组才能从Cloudfront访问!我真不想要这个!

当我将EC2与RDS一起使用时,我可以简单地允许访问RDS安全组中的EC2安全组.为什么我不能使用CloudFront执行此操作?或者我可以吗?

想法?

编辑:它没有记录,但ES接受facets查询,它涉及(JSON)主体,不仅使用POST,还使用GET.这通过不忽略GET请求()的主体来简单地破坏HTTP建议(对于RFC3616 ).这是因为,正如所指出的那样,直接暴露ES REST接口可能导致使用复杂查询的轻松DOS攻击.我仍然相信,少一个代理仍然值得.

编辑:我另一个选项是跳过CloudFront的并增加了安全层作为ElasticSearch插件,如图点击这里

ssc*_*zio 32

我用我自己的插件结束编码.令人惊讶的是,周围没有任何相似之处.没有代理,没有Jetty,没有Tomcat.

只是一个原始的ES休息模块和我的RestFilter.使用最少的反射来获取请求的远程地址.

请享用:

https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin

  • 伟大的工作需要更多的可见性! (2认同)

Vic*_*ing 5

请注意,即使是GET请求也可能在Elasticsearch中有害.简单地占用太多资源来进行计算的查询会降低您的群集.分面是一个很好的方法.

我建议您在ES前面编写一个简单的REST API,这样您就可以更好地控制搜索群集的内容.如果这不是一个选项,您可以考虑在ES框上运行Nginx作为本地反向代理,这将为您提供与CloudFront相同的控制(以及更多).那么你只需要向全世界开放Nginx,而不是ES.

  • 谢谢Victor,这正是我的计划B.无论是Nginx还是Varnish.我不愿意这样做,因为它会增加技术堆栈的另一个动作部分. (2认同)