API key owner

[mcosta]

Hi all,

Using Elastic Cloud V8.10.2

I need to create several API keys to be used on logstash.

When API key is created on Kibana -> Security -> API Keys, it ends with the owner being my user.
When API key is created on Deployment portal -> Elasticsearch -> API console, it ends with the owner being "elastic-userconsole-proxy".

Can someone clarify who should be the owner?
What is the difference between these two API keys if created with same privileges?

Thank you.

[stephenb (Stephen Brown)]

@mcosta

Great question!!

When you're in Kibana and you create that API key (and make sure you get the right format for logstash). That is an API key to read and write resources within the elastic cluster like writing indices.

When you're in the elastic cloud console, that API key can actually be used to run terraform or actually create, update and delete clusters. So think of it on the outside of the cluster.

So one is working within the cluster and the other is for managing clusters.

Hope that helps

[mcosta]

Hi Stephen

Thank you for your reply!

I'm now confused

Besides creating an API key using Kibana -> Security -> API Keys and then click "Create API key" blue button at top right (and of course Dev Tools console), there are two more options where one can create an API key :

1- https://cloud.elastic.co/home -> Manage -> Elasticsearch API console

2- https://cloud.elastic.co/account/keys
(You can create and manage deployments, configure remote clusters, set up traffic filters, manage extensions, and much more.)

From your reply I think you mean this option 2, but on my initial post I was referring option 1.

What's the difference between option 1 and 2?
Is option 1 same as creating an API key from Kibana button? But API key owner ends being not the same...

[stephenb (Stephen Brown)]

Ok lets use Screenshots

So #1:

That is just running the Elasticsearch REST APIs (so that is the Within Cluster API) but it is running them from the Cloud Console (so yeah kinda weird but it can be used when say there are Kibana issues etc) .

This is the Equivalent to Running API Calls from Kibana - Dev Tools or directly via the Elasricsearch REST API Endpoint

The key is you can always run this command to see what user you are

GET /_security/user

In this case this is a special users from the cloud console it is effectively superuser

If you are saying you are creating API Keys from this API Console you are just creating Elasitcsearch API Keys within the cluseter just like you would from Kibana - Dev Tools or Kibana - Stack Management -> API Keys

And #2 Correct create and manage deployments, configure remote clusters, set up traffic filters, manage extensions, and much more.)

[mcosta]

Once again, thank you for your prompt reply. I'm not confused anymore

But some question remains:

We have several application using logstash to ingest data into elastic. Each one has it's own pipeline and therefore we want to have one API key for each application.

As you can see bellow, "logs-airflw-dev" key, created on Kibana, have b10628 user (me) as owner. "dev-oshplt-oca-be-v2" key also created my be, but on API console, ended with "elastic-userconsole-proxy" as owner.

Q1: As best practice, should those applicational API keys be owned by "elastic-userconsole-proxy"?

Q2: What happen to API keys if they are created on Kibana by an user, say b10628, and that user is deleted from cluster? Are keys deleted too?

[stephenb (Stephen Brown)]

@mcosta

Q2: What happen to API keys if they are created on Kibana by an user, say b10628, and that user is deleted from cluster? Are keys deleted too?

No API keys are not deleted when the user that created them are deleted.

API Keys outlive the owners that created them as far as I understand..
That is pretty easy to test if you want

Be carefull though as stated in the documents.... the API key is an intersection of the User Creating the API with the Roles defined in the API key (otherwise this would allow and exploit / privilege escalation)

role_descriptors

(Optional, object) The role descriptors for this API key. This parameter is optional. When it is not specified or is an empty array, then the API key will have a point in time snapshot of permissions of the authenticated user. If you supply role descriptors then the resultant permissions would be an intersection of API keys permissions and authenticated user’s permissions thereby limiting the access scope for API keys.

Personally, I like creating API for the cluster Directly Through Kibana or Dev Tools, NOT through the Elastic Cloud Console , but that is just my personal preference.

[mcosta]

Concluding, I guess the best way is to have an user per application, that own all API keys needed for that application. This way, every member of the admin team can update the keys if necessary, as long as we keep the user's password in a shared vault.

API keys owned by "elastic-userconsole-proxy" cannot be updated.

BTW, "No API Keys outlive the owners that created them" seams not true.
After removing the user "test", the key (also named "test") is apparently active.

Thank you!

[stephenb (Stephen Brown)]

@mcosta

Are keys deleted too?

@mcosta

BTW, "No API Keys outlive the owners that created them" seams not true.
After removing the user "test", the key (also named "test") is apparently active.

Just poor writing on my side....

You asked

@mcosta

Are keys deleted too?

I answered: No

Then I should have separated the next sentence

API Keys outlive the owners that created them as far as I understand..
That is pretty easy to test if you want

So we are in agreement... I'll fix the wording above in case anyone else reads this topic.

[mcosta]

I'm sorry, you were perfectly clear.
It's my fault as I mix both sentences in one