对我们的一个k8s集群进行的安全扫描在一个Elasticsearch主pod的文件夹/usr/share/elasticsearch/data/nodes/0/_state/下发现了一个名为“pending_segments_runc”的文件。扫描软件将此报告为容器已篡改“runc”二进制文件的可能迹象，并可能导致容器逃逸。
我需要找到证据来证明这是真阳性还是假阳性。我已经在其他ES集群中的其他ES Pod中查看过了，在相应的文件夹中。他们没有任何以“pending_segments”开头的文件，也没有任何以“runc”结尾的文件。所有的Elasticoptics集群都是7.17版本，并且由ECK操作员部署。
所以问题是，任何了解Elasticsearch内部机制的人都可以指出在该文件夹下可以创建一个名为“pending_segements_runc”的文件的可能性吗？或者，请确认Elasticsearch本身不可能生成一个名为“pending_segements_runc”的文件？
2条答案
按热度按时间rkttyhzu1#
看看Elasticsearch source code和Lucene source code，绝对有可能编写这样的文件。
然而，从代码中注意到后缀应该是numeric，而不是像
runc这样的字母数字，所以这仍然不清楚。如果不检查里面的内容很难判断。它可能是一个淘气的段文件，等待与其他合法的段合并。由于runC是一个容器执行器，我会非常小心，因为这可能是some bad code伪装成一个合法命名的段文件等待合并。lkaoscv72#
在@瓦尔的回答中，我找到了具体的证据，证明文件名可以由Elasticsearch / Lucene创建。首先，ES在编写“pending_segements”文件名时向
IndexFileNames.fileNameFromGeneration传递了一个数字生成参数：https://github.com/elastic/elasticsearch/blob/96184ddb133829b7d87eadaf5a7b087aef2001f2/x-pack/plugin/core/src/main/java/org/elasticsearch/snapshots/sourceonly/SourceOnlySnapshot.java#L129这个方法又调用
Long.toString(gen, Character.MAX_RADIX))将生成号转换为字符串。https://github.com/apache/lucene/blob/ea272d0eda140a76c70f2d3befbe85e9e74a74e1/lucene/core/src/java/org/apache/lucene/index/IndexFileNames.java#L69。由于第二个参数Character.MAX_RADIX，结果不是十进制而是字母数字。