Elasticsearch is logging sensitive infrastructure information

Elastic Search
1

Hello,

I’m using Java Elastic 8 and would like to know if there is a way to prevent its logs from displaying sensitive data, such as its address. Example:

request [POST http://address:9200/5ddebbc7ec887eb5567af63c.5d657edd79275e2ddd2d675b/_search] returned 4 warnings:  
[299 Elasticsearch-8.17.1-d4b391d925c31d262eb767b8b2db8f398103f909 "Deprecated field [include_lower] used, this field is unused and will be removed entirely"],  
[299 Elasticsearch-8.17.1-d4b391d925c31d262eb767b8b2db8f398103f909 "Deprecated field [include_upper] used, this field is unused and will be removed entirely"],  
[299 Elasticsearch-8.17.1-d4b391d925c31d262eb767b8b2db8f398103f909 "Deprecated field [from] used, this field is unused and will be removed entirely"],  
[299 Elasticsearch-8.17.1-d4b391d925c31d262eb767b8b2db8f398103f909 "Deprecated field [to] used, this field is unused and will be removed entirely"]

I noticed that there are ways to configure the log level, but nothing beyond that. I searched the documentation and couldn’t find anything that addresses this issue.

Could someone help me? I appreciate it in advance.

1 Like
2

Can you provide more context from where is this log from? Is it from your application?

I don't think that the address of the cluster is considered sensitive.

1 Like
3

You can configure field level access control in Elasticsearch if you want certain fields with "sensitive" values to be excluded from the search results.

4

Of course! We have a platform where users can develop code. We use Elastic as a search engine, and they can perform queries, request object reindexing, among other actions. The issue is that we need to display certain logs to them since they need insights to understand potential issues in code execution. However, some logs end up exposing the Elastic address to the end user, which could compromise our security.

In this specific case, the user is using these fields in searches, which is generating the log and exposing our infrastructure. There are other similar cases as well, such as the following:

method [POST], host [http://address:9200/], URI [/5aa99e9e62edb97e8ca44888.638f55b514d6f675dce3d176/_search], status line [HTTP/1.1 500 Internal Server Error]  
{"error":{"root_cause":[{"type":"null_pointer_exception","reason":"Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.elasticsearch.search.aggregations.bucket.composite.CompositeValuesCollectorQueue.top()" is null"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"idx.10.5aa99e9e62edb97e8ca44888.638f55b514d6f675dce3d176","node":"NH0bnj57RhiC5g2yTBQa8Q","reason":{"type":"null_pointer_exception","reason":"Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.elasticsearch.search.aggregations.bucket.composite.CompositeValuesCollectorQueue.top()" is null"}}],"caused_by":{"type":"null_pointer_exception","reason":"Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.elasticsearch.search.aggregations.bucket.composite.CompositeValuesCollectorQueue.top()" is null","caused_by":{"type":"null_pointer_exception","reason":"Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.elasticsearch.search.aggregations.bucket.composite.CompositeValuesCollectorQueue.top()" is null"}}},"status":500}.

It's a situation similar to the one in the link below, but with the difference that I would like to mask our address in some way. We are using Elastic 7 and 8 at the same time while migrating to version 8.

Thank you very much for your attention. (Legal ver um brasileiro aqui)

5

Thank you for your response, but that’s not the case. My problem is more related to Elasticsearch error or warning logs that, in some way, expose its address, allowing end users to access its URL.

6

I am not sure if there is a way to filter the logs, at least not that I know of.
Instead of giving access to the log file, how about if get the Elasticsearch logs ingested back into the cluster and let the user to query Elasticsearch instead?

You may then be able to use ingest pipeline to "filter"/remove "sensitive" content in your logs.

7

This seems unusual. Your developers have access to the actual elasticsearch log files? Er, how ?

And all developers can see all the log files? But you don’t want the developers to know the IP addresses/ names of the elasticsearch servers ?

8

We have a low-code platform developed in Java, where users develop using JavaScript. Some exceptions thrown in our backend must be visible to users, such as those from Elastic. However, the issue with warnings is that their log content does not go through the backend—they are logged directly from within the Elastic code.

So, it's not that users have access to the log files, but rather that the system displays the logs, as shown in the image below. We don’t want developers to see the address because they are our clients, they don't use the Elastic itself.

Screenshot from 2025-04-04 12-05-05
Screenshot from 2025-04-04 12-05-05356×426 30.3 KB

9

Thanks for clarification. I think you are stretching things a little to claim the logs containing the address a request was sent to is divulging “sensitive information”. The index name was in same warning, and the http method, etc - where would you stop ? But others may take a different view.

I don’t use the Java High Level REST client so maybe someone else might be able to suggest another way / setting.

I still think this is unusual use case, but you can certainly open a feature request. If you are paying customer, you could also reach out to your elastic contacts.

1 Like