Automated Reporting triggered using Apikey because authorization fails

[lucabelluccini]

Kibana version: 7.8.1, 7.9.0

Elasticsearch version: aligned

Describe the bug:

It is not possible to trigger an automated PDF report using the POST URL and using the Apikey authentication (which should be enabled by default as per https://www.elastic.co/guide/en/kibana/master/kibana-authentication.html#http-authentication)

Steps to reproduce:

1. Login in Kibana as elastic (superuser)
2. Generate an ApiKey, which will inherit the permissions of elastic
3. Install the sample data (any)
4. Go in a dashboard and get the Share / PDF / POST URL
5. Submit a curl request as follows:

curl --request POST \
  --url 'https://...:9243/api/reporting/generate/printablePdf?jobParams=...' \
  --header 'authorization: ApiKey <base64(id:api_key)>' \
  --header 'kbn-version: 7.8.1' \
  --header 'kbn-xsrf: kibana'

Response:

{
  "statusCode": 403,
  "error": "Forbidden",
  "message": "Sorry, you don't have access to Reporting"
}

Expected behavior:

Start the generation of the PDF report.

Comments:

• Given the Api Key Creation API design, it is not possible to "reuse" the reporting_user role, as it expects role descriptions, not role names.
• Issuing the same request with other Kibana APIs using ApiKey are inconsistent:
  • /api/saved_objects/_find?type=index-pattern&search_fields=title&search=* > Response 403

    {
    "statusCode": 403,
    "error": "Forbidden",
    "message": "Unable to find index-pattern"
    }
    

  • /api/security/role > Response OK

    [
    {
    "name": "apm_system",
    "metadata": {
      "_reserved": true
    },
    "transient_metadata": {
      "enabled": true
    }, ...
    

• I tried to repeat those steps with a native custom user (toto), instead of a reserved user (elastic) and I get the same behavior.
  This is the output when I request my authentication info from Elasticsearch using GET _security/_authenticate (user toto logged in in Basic auth):

{
  "username" : "toto",
  "roles" : [
    "reporting_user",
    "kibana_admin",
    "x" # Grants access to the data in the indices involved in the report
  ],
  "full_name" : "toto",
  "email" : "toto@toto.toto",
  "metadata" : { },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "native1",
    "type" : "native"
  },
  "lookup_realm" : {
    "name" : "native1",
    "type" : "native"
  }
}

The output when hitting the same API using an API key generated from toto (apikey auth):

{
  "username": "toto",
  "roles": [],
  "full_name": null,
  "email": null,
  "metadata": {},
  "enabled": true,
  "authentication_realm": {
    "name": "_es_api_key",
    "type": "_es_api_key"
  },
  "lookup_realm": {
    "name": "_es_api_key",
    "type": "_es_api_key"
  }
}

The output when hitting the same API using an API key generated from elastic (apikey auth):

{
  "username": "elastic",
  "roles": [],
  "full_name": null,
  "email": null,
  "metadata": {
    "_reserved": true
  },
  "enabled": true,
  "authentication_realm": {
    "name": "_es_api_key",
    "type": "_es_api_key"
  },
  "lookup_realm": {
    "name": "_es_api_key",
    "type": "_es_api_key"
  }
}

Given such results, it seems the ApiKey authentication is not handled in a uniform way across the APIs.
Please let me know if we should open a more generic issue (instead of focusing on Reporting).

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Hey @lucabelluccini,

I see the same results as you in terms of the /_security/_authenticate APIs, but I am able to successfully hit the /api/saved_objects/_find?type=index-pattern&search_fields=title&search=* API:

I created the toto user in the native realm:

{
  "username" : "toto",
  "roles" : [
    "reporting_user",
    "kibana_admin",
    "key"
  ],
  "full_name" : "",
  "email" : "",
  "metadata" : { },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "native1",
    "type" : "native"
  },
  "lookup_realm" : {
    "name" : "native1",
    "type" : "native"
  },
  "authentication_type" : "realm"
}

I created an API key using the toto user:

POST /_security/api_key
{
  "name": "my-api-key"
}

Which gave me:

{
  "id" : "3g3MSXQBVO8PKDtGp5QH",
  "name" : "my-api-key",
  "api_key" : "gle3H2e-Rr6ghOMm6_3azw"
}

Base64 encoding {id}:{api_key} gives me a credential string of YWczS1NYUUJWTzhQS0R0R1paUm86NFI2cHY4aDlRRGlSVzhMUzU3S09rQQ==, which I in turn used in the api request to Kibana:

curl -H "Authorization: ApiKey YWczS1NYUUJWTzhQS0R0R1paUm86NFI2cHY4aDlRRGlSVzhMUzU3S09rQQ==" -k "https://localhost:5601/foo/api/saved_objects/_find?type=index-pattern&search_fields=title&search=*" | jq .
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    53  100    53    0     0   1325      0 --:--:-- --:--:-- --:--:--  1325
{
  "page": 1,
  "per_page": 20,
  "total": 0,
  "saved_objects": []
}

I was also able to do this with the elastic superuser account, so it appears to me that API Keys generally work for authenticating & authorizing access to Kibana APIs.

The error you received (Unable to find index-pattern) is returned by Kibana if the authorization check fails, so this tells me that the API Key (and/or the user who created the API Key) was not authorized to search for index patterns within Kibana. Can you share the command you ran to generate the API Key?

I agree that there is an issue with how Reporting authorizes access - since it relies on role names, and authentication via API Keys does not return the set of roles from the backing user.

[tsullivan]

I agree that there is an issue with how Reporting authorizes access - since it relies on role names, and authentication via API Keys does not return the set of roles from the backing user.

This is the reason that Reporting shows that the user is "unable to generate reports." As you say, we rely on finding the role names of the user, and matching them against the allowed roles.

@legrego any suggestions on how we can move forward with this? Is it at all possible to get back the original role names in the authenticate API when it is ApiKey auth?

[tvernum]

I don't think there's any way to make this work while still relying on role names. If we want reporting to work with API keys then it really needs to move to a Kibana Application privilege.
API Keys don't have roles. There is no way to work out "the original role names" because they don't exist.

[legrego]

any suggestions on how we can move forward with this? Is it at all possible to get back the original role names in the authenticate API when it is ApiKey auth?

I agree with Tim - moving to a Kibana Application privilege is likely the way forward here

[tsullivan]

We should fix the documentation and any mention we can find that suggests to use API Key authorization to run a report.

I filed a separate issue to decide how to move away from the role-based authorization model: #76964

[Aloshi]

+1 to this issue - I was trying to add snapshots to some code that already uses API keys and was very surprised to find my superuser's API key doesn't have permission to generate reports. It sounds like the work-around in the mean time is to switch to user-based authentication / basic auth?

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[tsullivan]

Depends on #19914