[Fleet] API Key application privilege

[nchaulet]

Description

Currently fleet use api keys to enroll agent, and for agent checkin.

This API Key do not have any particular roles and to make the link between agent and api key we saved objects with the id of the api key saved on it.

Could we use application privilege and ressources for api keys? What are the pro and cons to do that

Proposal

For checkin

GET /_security/user/_has_privileges
{
  "application": [
    {
      "application": "fleet",
      "privileges" : [ "action:checkin" ],
      "resources" : [ "agent/1852563" ]
    }
  ]
}

For enrollment

GET /_security/user/_has_privileges
{
  "application": [
    {
      "application": "fleet",
      "privileges" : [ "action:enroll" ],
      "resources" : [ "policy/default" ]
    }
  ]
}

[ruflin]

+1 on using application privileges for the API Keys. This will narrow down what the users can actually do with an API key and increases security.

@nchaulet @kobelb Are there any disadvantages in using it?

[kobelb]

Conceptually, using application privileges for this makes sense. However, there are some practical limitations...

A user with the manage_security cluster privilege is required to edit a role's application privileges. The kibana_system reserved role, which is used as the Kibana server identity, does not have the manage_security cluster privilege intentionally. This limits the privileges which an attacker has if they happen to compromise the Kibana server's identity. Instead, we rely on the end-user themselves to have the manage_security cluster privilege to be able to do things like create/edit/delete Elasticsearch users and roles.

It also requires that we know which specific role should have the application privileges. I'm not too familiar with the conceptual "Fleet workflows" which the users will be following within Kibana to know whether or not this is a complication or not.

[ruflin]

@kobelb We want to limit the scope / user permissions the API key has that is used in the agent to talk to Fleet. Everything you list above sound beneficial for what we need it for.

Question for the following configs:

      "privileges" : [ "action:checkin" ],
      "resources" : [ "agent/1852563" ]

Are we able to define these privileges in our Fleet app? Meaning we can create new ones?

[kobelb]

The "privileges" from above correspond to the privileges associated with Elasticsearch's application privileges. Kibana currently creates Elasticsearch application privileges for the kibana-${kibanaIndex} application at startup using the Elasticsearch create or update application privileges API. The kibana_system role is currently constrained to only manage application privileges for applications which start with kibana-. So, it's definitely possible to allow Fleet to create its own application privilege within some constraints, or with some additional changes.

The "resources" don't have to be created up-front, and are completely dynamic when a role is created/updated; or when an API Key is created and role_descriptors are specified.

It's worth noting that the Kibana UI and APIs for managing roles only support the kibana-${kibanaIndex} application privileges. At one point, there was a discussion about creating a separate application for Fleet and the following issue was created: #42881. However, nothing came of it, and last I heard we were planning to treat Fleet as a feature within Kibana itself, which would treat it as a subset of the kibana-${kibanaIndex} application.

[nchaulet]

Discussed by email, we are going to use Kibana privileges in Fleet,

Fleet is mostly using kibana features so using Kibana Privileges simplifies things on our end and we will get OLS out of the box when this is ready.