Enterprise Search Native Credentials Required Privileges

Elastic Search
1

Our elastic cluster is on-premise. We deploy the different components (kibana, logstash, enterprise search) to different nodes and configure them to connect / talk to the Elasticsearch cluster.

What I see in the documentation (Configuration | Elastic Enterprise Search Documentation [8.2] | Elastic) is that we no longer have to put the basic auth credentials to connect to Elasticsearch in the configuration file (or in a keystore). Saving them as environment variables is a marginal improvement -- I would prefer to use an API Key or service account token like the other components can -- but the question I have is about cluster and index privileges required for this connection.

Is there documentation someplace (or does anyone know) what privileges are required for the connection between enterprise search and the Elasticsearch cluster? I will create an account that can only be used for this connection, and I want to grant it the least amount of privileges required to do the work.

Does this list exist someplace?

Thanks!

2

Hi Tony,

If this list exists, I haven't heard about it. I believe almost everyone uses these fields to set up the connection to Elasticsearch:

elasticsearch.username: elastic
elasticsearch.password: ELASTIC_USER_PASSWORD

or sets them via environment variables as you mentioned.

That said, maybe I just don't know that this possibility exists. I'll repost your question to the team, maybe someone else knows about it.

1 Like
3

I got some guidance from the team.

Please note that it's not a supported way of connecting Enterprise Search, and the guide below is not guaranteed to work or may cause issues down the road.

With that said, try using the same permissions that the current Service Account for Enterprise Search uses:

  • Cluster privileges: manage_security

  • manage , read and write privileges for the following indices:

    • .ent-search-*
    • .monitoring-ent-search-*
    • metricbeat-ent-search-*
    • enterprise-search-*
    • logs-app_search.analytics-default
    • logs-enterprise_search.api-default
    • logs-enterprise_search.audit-default
    • logs-app_search.search_relevance_suggestions-default
    • logs-crawler-default
    • logs-workplace_search.analytics-default
    • logs-workplace_search.content_events-default

  • Read and view_index_metadata for the search-* index pattern

You might also need to assign the following roles to that user: enterprise-search-workplace-search-admin and enterprise-search-app-search-owner.

4

Thanks @Vadim_Yakhin So to be clear, the team is saying that the "supported" way to do this is to use the built-in elastic, super-user account? So if I try to do something with less privileges it will not be supported (or is certainly not guaranteed to work)?

5

So to be clear, the team is saying that the "supported" way to do this is to use the built-in elastic, super-user account?

Yes

So if I try to do something with less privileges it will not be supported (or is certainly not guaranteed to work)?

Yes, we haven't heard of that need before so we never tried it.

6

I will make sure I have a case open with support on the topic, but here's my concern and some context.

It would seem to me it is really bad practice to put a superuser's credentials in plain text in a configuration file (or even stored as environment variables). So the "need" is not to get the product to run but to use the least amount of privileges to do the work... This is a fundamental secure coding practice, right? :slight_smile:

My issue is not that I can't get the product to run. We have 7.x configured this way right now and have had it in production for nearly a couple of years now. But in current state, we only index fully-public, non-confidential data. In our next iteration, we want to start indexing more highly confidential data.

I was hoping with 8.x that A) I could use an API Key instead of end user credentials, and B) the API Key would have only the limited amount of permissions required to make the application work. At the very least I'd like to store the credentials more securely (though I don't relish the thought of having to manage another local keystore).

I'm sure I don't have to point out the kind of damage a bad actor could do to a cluster with super user credentials. Our environment is a highly-regulated (hyper-secure) environment, so we have sometimes have to go through some gymnastics to lock things down as tightly as possible.

Anyway, that's the "need" I'm trying to fill, not a functional one. Thanks for looking into it for me. Do very much appreciate it!

1 Like
7

Hey there Tony!

Just to be sure, it sounds as if you are attempting to use the API authentication mechanism within your Enterprise Search configuration to securely (but limited in scope with privileges) to interact with Elasticsearch?

Here is the Elasticsearch documentation around the generation of API keys (Security settings in Elasticsearch | Elasticsearch Guide [8.2] | Elastic), but looking at the Enterprise Search configuration options this is not yet available (Configuration | Elastic Enterprise Search Documentation [8.2] | Elastic).

Is this what you would like to have submitted as a feature request?

Thank you,

8

Yes, that would be great! Along with it it would be good to document (and support) what the more limited list of privileges is... @Vadim_Yakhin has pulled together what looks like a credible list, but we don't want to go off into "unsupported" territory. :slight_smile:

9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.