[Security/APIKey Service] Internal API endpoint do determine if user has API keys #172884

tsullivan · 2023-12-07T20:17:15Z

Summary

This PR enhances the Security server plugin APIKey service with a new method to determine if the user has API keys. The service is integrated into the "No Data Page" server plugin as a new HTTP route. This route is called when needed to direct users effectively through their getting started experience.

Pulled from #172225

Context

...we [sh]ould introduce whatever functionality we required into the security plugin's API Key Service.

Checklist

Delete any items that are not applicable to this PR.

Unit or functional tests were updated or added to match the most common scenarios

tsullivan · 2023-12-14T19:55:55Z

x-pack/plugins/security/server/routes/api_keys/has.ts

+
+        const apiResponse = await esClient.asCurrentUser.security.getApiKey({
+          owner: true,
+        });


I'm not sure the owner field needs any conditions, but perhaps I'm not aware.

Hmm, I'm not aware of any conditions either.

x-pack/test/api_integration/apis/security/api_keys.ts

azasypkin · 2023-12-18T11:38:12Z

ACK: will review today

azasypkin

Looks good! Just left a few comments.

x-pack/plugins/security/server/routes/api_keys/has.ts

azasypkin · 2023-12-18T13:04:17Z

x-pack/plugins/security/server/routes/api_keys/has.ts

+
+        const apiResponse = await esClient.asCurrentUser.security.getApiKey({
+          owner: true,
+        });


Hmm, I'm not aware of any conditions either.

azasypkin · 2023-12-18T13:13:22Z

x-pack/plugins/security/server/routes/api_keys/has.ts

+          owner: true,
+        });
+
+        const validKeys = apiResponse.api_keys.filter(({ invalidated }) => !invalidated);


question: you filter out invalidated keys, but not expired ones - is it intentional? If not, can we use active_only request parameter to avoid this additional filtering?

@azasypkin I see your point, but I don't see the active_only parameter supported in the SecurityGetApiKeyRequest typings.

Hmm, it should be available since 8.10.0 - elastic/elasticsearch#98259 - let me figure this out. In the worst case I'd prefer to do something like this to filter keys on ES side instead:

const apiResponse = await esClient.asCurrentUser.security.getApiKey({ owner: true, // @ts-expect-error @elastic/elasticsearch SecurityGetApiKeyRequest.active_only: boolean | undefined active_only: true, }); return response.ok<HasAPIKeysResult>({ body: { hasApiKeys: apiResponse.api_keys.length > 0, }, });

Okay, we'll get this definition in the client soon (elastic/elasticsearch#103621), let's move forward with active_only and @ts-expect-error (if needed) for now (Client will include the parameter regardless wrong type definition).

x-pack/test_serverless/api_integration/test_suites/common/platform_security/api_keys.ts

Co-authored-by: Aleh Zasypkin <[email protected]>

…sullivan/kibana into security/api-keys-service-has-api-keys

azasypkin · 2023-12-20T12:14:37Z

ACK: will review today

elasticmachine · 2023-12-20T12:15:10Z

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

azasypkin

Left a few final notes, but LGTM otherwise! Let's move forward with active_only even if it requires temporary @ts-expect-error.

x-pack/plugins/security/server/routes/api_keys/has_active.test.ts

azasypkin · 2023-12-20T12:52:57Z

x-pack/plugins/security/server/routes/api_keys/has.ts

+          owner: true,
+        });
+
+        const validKeys = apiResponse.api_keys.filter(({ invalidated }) => !invalidated);


Okay, we'll get this definition in the client soon (elastic/elasticsearch#103621), let's move forward with active_only and @ts-expect-error (if needed) for now (Client will include the parameter regardless wrong type definition).

x-pack/test/security_api_integration/tests/api_keys/has_active_key.ts

x-pack/plugins/security/server/routes/api_keys/has.ts

azasypkin · 2023-12-20T15:31:04Z

x-pack/plugins/security/server/routes/api_keys/has_active.ts

+      } catch (error) {
+        return response.customError(wrapIntoCustomErrorResponse(error));
+      }


nit: just realized, we don't really need a try/catch here, let's let Core to handle and log this error properly (without exposing too much raw error details).

This feedback makes sense. After removing the try/catch I also had to delete a unit test, should forward error from Elasticsearch GET API keys endpoint

Co-authored-by: Aleh Zasypkin <[email protected]>

…_key.ts Co-authored-by: Aleh Zasypkin <[email protected]>

…sullivan/kibana into security/api-keys-service-has-api-keys

kibana-ci · 2023-12-21T01:45:04Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: c6461cf

Failed CI Steps

FTR Configs #56

Test Failures

[job] [logs] FTR Configs #56 / aiops log pattern analysis loads the log pattern analysis page and filters in patterns in discover

Metrics [docs]

✅ unchanged

History

💚 Build #184451 succeeded 83ea4c9
💛 Build #184119 was flaky 474ed25
💚 Build #183826 succeeded 9fd5b10
💔 Build #183724 failed a469842

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

azasypkin

LGTM, thanks!

## Summary This PR offers customizations to the "Getting Started" experience for users of Serverless Elasticsearch projects. The changes involve checking Elasticsearch if the currently-logged-in user has created API Keys, and to use that information to customize the getting started messaging (destination of the call-to-action of the "no data" prompt) in the UI. ### Screenshots | | Before | After | |-|-|-| | Data Views Mgmt | <img width="1646" alt="before - serverless es data views mgmt empty state" src="https://github.com/elastic/kibana/assets/908371/b5c28dda-9ff8-40de-af89-71587bdbbe54"> | <img width="1646" alt="after - serverless es data views mgmt empty state" src="https://github.com/elastic/kibana/assets/908371/13aae073-9fef-407a-bdb1-e09d6ea1d168"> | | Analytics | <img width="1646" alt="before - serverless es discover empty state" src="https://github.com/elastic/kibana/assets/908371/ac0e70e5-9a73-4de3-8182-51350099ae87"> | <img width="1646" alt="after - serverless es discover empty state" src="https://github.com/elastic/kibana/assets/908371/6f9231e0-d2fb-480b-a5a2-79cc9f853a9b"> | Elasticsearch documentation on API Key listing: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-get-api-key.html Depends on: #172884 Closes: elastic/search-team#5974 Closes: elastic/search-team#5975 ### Other changes * Created a React hook to send and track a request to the Kibana server to ask whether the user has access to API Keys * Added unit test for this * See discussion, this hook may be [re-organized eventually](#172225 (comment)) * Enable lazy loading for the "Analytics No Data" page within analytics apps. ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]>

## Summary This PR offers customizations to the "Getting Started" experience for users of Serverless Elasticsearch projects. The changes involve checking Elasticsearch if the currently-logged-in user has created API Keys, and to use that information to customize the getting started messaging (destination of the call-to-action of the "no data" prompt) in the UI. ### Screenshots | | Before | After | |-|-|-| | Data Views Mgmt | <img width="1646" alt="before - serverless es data views mgmt empty state" src="https://github.com/elastic/kibana/assets/908371/b5c28dda-9ff8-40de-af89-71587bdbbe54"> | <img width="1646" alt="after - serverless es data views mgmt empty state" src="https://github.com/elastic/kibana/assets/908371/13aae073-9fef-407a-bdb1-e09d6ea1d168"> | | Analytics | <img width="1646" alt="before - serverless es discover empty state" src="https://github.com/elastic/kibana/assets/908371/ac0e70e5-9a73-4de3-8182-51350099ae87"> | <img width="1646" alt="after - serverless es discover empty state" src="https://github.com/elastic/kibana/assets/908371/6f9231e0-d2fb-480b-a5a2-79cc9f853a9b"> | Elasticsearch documentation on API Key listing: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-get-api-key.html Depends on: elastic#172884 Closes: elastic/search-team#5974 Closes: elastic/search-team#5975 ### Other changes * Created a React hook to send and track a request to the Kibana server to ask whether the user has access to API Keys * Added unit test for this * See discussion, this hook may be [re-organized eventually](elastic#172225 (comment)) * Enable lazy loading for the "Analytics No Data" page within analytics apps. ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]>

tsullivan mentioned this pull request Dec 7, 2023

[Serverless Search] Update the "empty state" screens #172225

Merged

2 tasks

tsullivan force-pushed the security/api-keys-service-has-api-keys branch 3 times, most recently from ad2335c to 12f4747 Compare December 14, 2023 18:38

tsullivan added 2 commits December 14, 2023 12:38

Extend Security APIKey service

24b53e9

backing out of sprawling test updates

b730c9f

tsullivan force-pushed the security/api-keys-service-has-api-keys branch from cb840c9 to d6ebe83 Compare December 14, 2023 19:42

Tests

89a92fd

tsullivan force-pushed the security/api-keys-service-has-api-keys branch from d6ebe83 to 89a92fd Compare December 14, 2023 19:44

tsullivan changed the title ~~[Security/APIKey Service] Add functionality to determine if user has created API keys~~ [Security/APIKey Service] Internal API endpoint do determine if user has API keys Dec 14, 2023

tsullivan marked this pull request as ready for review December 14, 2023 19:46

tsullivan requested a review from a team as a code owner December 14, 2023 19:46

tsullivan added the release_note:skip Skip the PR/issue when compiling release notes label Dec 14, 2023

tsullivan commented Dec 14, 2023

View reviewed changes

x-pack/test/api_integration/apis/security/api_keys.ts Outdated Show resolved Hide resolved

tsullivan and others added 3 commits December 14, 2023 13:08

fix test

a469842

Merge branch 'main' into security/api-keys-service-has-api-keys

1a332f6

remove non-trivial test

9fd5b10

azasypkin self-requested a review December 18, 2023 11:38

azasypkin reviewed Dec 18, 2023

View reviewed changes

tsullivan and others added 8 commits December 18, 2023 12:14

Merge branch 'main' into security/api-keys-service-has-api-keys

bdf8987

use naming consistent with _enabled

09496b5

Update x-pack/plugins/security/server/routes/api_keys/has.ts

c0fb932

Co-authored-by: Aleh Zasypkin <[email protected]>

Merge branch 'security/api-keys-service-has-api-keys' of github.com:t…

f39999c

…sullivan/kibana into security/api-keys-service-has-api-keys

fix path of the new endpoint

598f141

Merge branch 'main' into security/api-keys-service-has-api-keys

5b51b06

Move new test outside of serverless area

474ed25

Merge branch 'main' into security/api-keys-service-has-api-keys

83ea4c9

azasypkin self-requested a review December 20, 2023 12:14

azasypkin added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Users/Roles/API Keys labels Dec 20, 2023

azasypkin reviewed Dec 20, 2023

View reviewed changes

tsullivan and others added 7 commits December 20, 2023 17:18

Merge branch 'main' into security/api-keys-service-has-api-keys

423037a

Update x-pack/plugins/security/server/routes/api_keys/has_active.test.ts

c1aeb86

Co-authored-by: Aleh Zasypkin <[email protected]>

Update x-pack/test/security_api_integration/tests/api_keys/has_active…

27a823a

…_key.ts Co-authored-by: Aleh Zasypkin <[email protected]>

Add active_only param

eeb8e10

Merge branch 'security/api-keys-service-has-api-keys' of github.com:t…

7640ed4

…sullivan/kibana into security/api-keys-service-has-api-keys

Allow core to handle error thrown from route handler

d15c932

update test per removal of error catching in the route handler

c6461cf

azasypkin approved these changes Dec 21, 2023

View reviewed changes

tsullivan merged commit b13974c into elastic:main Dec 21, 2023
37 checks passed

tsullivan deleted the security/api-keys-service-has-api-keys branch December 21, 2023 18:33

kibanamachine added v8.13.0 backport:skip This commit does not require backporting labels Dec 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security/APIKey Service] Internal API endpoint do determine if user has API keys #172884

[Security/APIKey Service] Internal API endpoint do determine if user has API keys #172884

tsullivan commented Dec 7, 2023 •

edited

Loading

tsullivan Dec 14, 2023

azasypkin Dec 18, 2023

azasypkin commented Dec 18, 2023

azasypkin left a comment

azasypkin Dec 18, 2023

azasypkin Dec 18, 2023

tsullivan Dec 18, 2023

azasypkin Dec 20, 2023

azasypkin Dec 20, 2023

azasypkin commented Dec 20, 2023

elasticmachine commented Dec 20, 2023

azasypkin left a comment

azasypkin Dec 20, 2023

azasypkin Dec 20, 2023

tsullivan Dec 21, 2023

kibana-ci commented Dec 21, 2023

azasypkin left a comment

[Security/APIKey Service] Internal API endpoint do determine if user has API keys #172884

[Security/APIKey Service] Internal API endpoint do determine if user has API keys #172884

Conversation

tsullivan commented Dec 7, 2023 • edited Loading

Summary

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin commented Dec 18, 2023

azasypkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin commented Dec 20, 2023

elasticmachine commented Dec 20, 2023

azasypkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kibana-ci commented Dec 21, 2023

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

History

azasypkin left a comment

Choose a reason for hiding this comment

tsullivan commented Dec 7, 2023 •

edited

Loading