Allow API Keys to be managed for remote clusters

[legrego]

The updated remote cluster security model requires changes to the API Key management screen.
RCS remote clusters will require specialized API keys to work. The specialized API key will be created with a new API endpoint. The request payload will be a simplified version of existing CreateApiKey payload to focus only on the necessary information. The specialized API key will be differentiated from regular API keys by its type. The type information will be returned in Get and Query responses. This is the only way to tell whether an API key is specialized.

High-level requirements

1. The API Key management screen should be updated to allow the different API Key types to be distinguished from one another.
2. Users with the elevated manage_security cluster privilege shall have the ability to create & update RCS API Keys, as described in the technical document provided by ES. This is a different privilege than what the rest of the screen requires today.
3. API Key Invalidation will require the existing manage_api_keys cluster privilege.
   4) RCS API Keys cannot have their privileges limited, so this ability should be hidden when creating/updating these key types.
4. RCS API Keys are (initially?) not available in the serverless offering, so these changes should only be visible for the current offering.
5. RCS API Keys require an enterprise license, and should not be available for deployments with a lesser license level.
6. Any new APIs introduced on the Kibana side should be marked as internal, for consistency with the rest of our API Key endpoints.
7. These RCS API Key changes must not be visible in the UI until support for this is enabled in ES.

Nice-to-haves

1. Elasticsearch can expose the role_descriptors and limited_by_role_descriptors as described here: Support viewing API key privileges elasticsearch#89058. It would be nice to update our screens to show these fields when viewing/editing an existing key, so that users can better understand the capabilities of each of their keys.

[elasticmachine]

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

[legrego]

This work is no longer required

[legrego]

Reopening, as the design for RCS 2.0 has changed to include custom API Keys.

[bytebilly]

RCS API Keys cannot have their privileges limited, so this ability should be hidden when creating/updating these key types.

This sounds wrong. Users can limit what these API keys grant access to, it's actually one of the key features of the new security model 🙂

[bytebilly]

The API Key management screen should be updated to allow the different API Key types to be distinguished from one another.

I'm not sure if this has been discussed or not, but there is also the option to provide this functionality in the "Remote cluster" section instead of the existing API key management panel.
It probably depends if we will list RCS API keys in the same list, or if we introduce a dedicated view.

[legrego]

RCS API Keys cannot have their privileges limited, so this ability should be hidden when creating/updating these key types.

This sounds wrong. Users can limit what these API keys grant access to, it's actually one of the key features of the new security model 🙂

Oops I think you're right, thanks for calling this out. I was confused by this statement:
"The specialized API keys will not use the existing limited-by model. This is a corollary of the manage_security privilege requirement. The ownership model still applies (owner means the user who creates these API keys)."

[legrego]

The API Key management screen should be updated to allow the different API Key types to be distinguished from one another.

I'm not sure if this has been discussed or not, but there is also the option to provide this functionality in the "Remote cluster" section instead of the existing API key management panel.

It probably depends if we will list RCS API keys in the same list, or if we introduce a dedicated view.

Ah that's an interesting thought, I think @thomheymann was trying to tell me this earlier today, too. @alisonelizabeth & @sabarasaba, is this something you've explored?

[bytebilly]

Oops I think you're right, thanks for calling this out. I was confused by this statement:
"The specialized API keys will not use the existing limited-by model.

Oh, I see 🙂 That actually means that they are not limited by privileges of the user creating the API key, that are enforced for the "regular" creation flow, but only by what is specified in the API call payload.

[sabarasaba]

Ah that's an interesting thought, I think @thomheymann was trying to tell me this earlier today, too. @alisonelizabeth & @sabarasaba, is this something you've explored?

We havent explored this idea as just recently we found out that we were going to include custom API Keys. I do like the thought of keeping things closer together, but it feels like the UIs would be quite similar to eachother. What do you think about this @kyrspl?

[thomheymann]

The API Key management screen should be updated to allow the different API Key types to be distinguished from one another.

I'm not sure if this has been discussed or not, but there is also the option to provide this functionality in the "Remote cluster" section instead of the existing API key management panel. It probably depends if we will list RCS API keys in the same list, or if we introduce a dedicated view.

I think we would ideally provide both, the ability to view and manage RCS API keys from within the API Keys screen but also a dedicated experience for configuring remote clusters using RCS API keys from within the Remote Clusters screen.

We could create a few shared components if any of the forms / screens are the same to avoid duplication.

[bytebilly]

Just to clarify further, the API key is created on one cluster and added to the keystore of the other one, so if we make it part of the remote cluster UI it will not interact with the setup flow anyway.

So, under remote cluster it would likely be splitting the view in two areas:

• remote clusters that are configured locally
• api keys that are created to allow other clusters to access

[thomheymann]

Depends on elastic/eui#6900