API key does or does not rely on permissions from user that created it

Elastic Stack Elasticsearch
,
1

We had previously been creating API keys with our SSO user accounts. Then we found that after an SSO IdP provider change our users were effectively “different” such that we could no longer edit API keys (e.g. to add or remove permissions) and had to recreate a lot of them.

Because of that, we have created a shared user with very limited permissions, only to manage api keys, with the thought that even a future SSO change won't render our API keys orphaned (not editable). When I login with that user and create an API key - we get mixed results when then calling APIs with that key.

Index permissions seem to work ok. The code using the API key succeeds to post new documents to indices.

Cluster permissions are not working. Trying to call /_ingest/pipeline/my-pipeline and getting 403 response

action [cluster:admin/ingest/pipeline/get] is unauthorized for API key id [6w5rvZoByBvH2vsLbT-1] of user [fusion-apikeys-dev], this action is granted by the cluster privileges [read_pipeline,manage_ingest_pipelines,manage_pipeline,manage,all]"

API is created with this, which I understand with “role_desriptors” does NOT leverage anything about the user that created the API key.

POST /_security/api_key
{
  "name": "ingest-pipeline-apikey-dev-333",
  "role_descriptors": {
    "ingest_pipeline_apikey_role_333": {
      "cluster": ["manage_pipeline", "read_pipeline", "manage_ingest_pipelines"]
    }
  }
}

Can you help sort me out?
Are cluster permissions treated differently with API keys and the user that created them?

2

Hi @qd-danh

I am not sure I am following so lets define what privileges are applied to a created API Key

In short a user can not create an API Key with greater / more privileges than that use has at that point in time they create API Key.

The privileges that the API key results in in an intersection of the Current Users PIT privileges with the Roles defined in the API Key.

As far as I know that applies to all privileges, cluster, indices, renote_indicies, applications etc

This is documented here in the Roles section

This approach keeps users from creating API Keys with more privileges than they currently have .. AKA does not allow privilege escalation which would be a security flaw.