Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Connection Details] Check if user has permissions to manage own API keys #183286

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

vadimkibana
Copy link
Contributor

@vadimkibana vadimkibana commented May 13, 2024

Summary

Closes #181288

  • Exposes from security plugin ability to check if use can manage own API keys, through security.authz.getCurrentUserApiKeyPrivileges().
  • Checks if user has permissions, and displays "No permissions" screen, if user does not have permissions in the Connection Details flyout.

How to test

Add these Cloud settings to your config/kibana.dev.yml as a mock data:

elasticsearch.hosts: ["http://localhost:9200"]
xpack.cloud.id: my-cluster-id:dXMtZWFzdC0xLmF3cy5zdGFnaW5nLmZvdW5kaXQubm8kZjY3ZDZiZjFhM2NmNDA4ODhlODg2M2Y2Y2IyY2RjNGMkOWViYzEzYjRkOTU0NDI2NDljMzcwZTNlZjMyZWYzOGI=

This will expose the "Setup guides" button in the top nav and the "Connect to the Elasticsearch API" card:

image

Create a new user. The lowest level of API key permissions is manage_own_api_key. Toggle that permission on user settings to see the changes in the Connection Details flyout.

Screenshot 2024-05-13 at 15 27 41

When the user does not have a permission to edit own API keys, the connection details flyout should show this message:

image

When user has permissions, it should allow to create a new API key:

image

Checklist

Delete any items that are not applicable to this PR.

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk Probability Severity Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space. Low High Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. High Low Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled. Medium High Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

@vadimkibana vadimkibana requested review from a team as code owners May 13, 2024 13:07
@vadimkibana
Copy link
Contributor Author

@elasticmachine merge upstream

@vadimkibana vadimkibana changed the title [wip] Connection details permissions [Connection Details] Check if user has permissions to manage own API keys May 15, 2024
@vadimkibana vadimkibana added review release_note:skip Skip the PR/issue when compiling release notes Team:SharedUX Team label for AppEx-SharedUX (formerly Global Experience) v8.15.0 labels May 15, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/appex-sharedux (Team:SharedUX)

2 similar comments
@elasticmachine
Copy link
Contributor

Pinging @elastic/appex-sharedux (Team:SharedUX)

@elasticmachine
Copy link
Contributor

Pinging @elastic/appex-sharedux (Team:SharedUX)

@vadimkibana
Copy link
Contributor Author

@elasticmachine merge upstream

@vadimkibana
Copy link
Contributor Author

@elasticmachine merge upstream

getCurrentUserApiKeyPrivileges: () => Promise<AuthorizationCurrentUserApiKeyPrivilegesResponse>;
}

export interface AuthorizationCurrentUserApiKeyPrivilegesResponse {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use GetAPIKeysResult interface here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is in a package, but GetAPIKeysResult is the server-side plugin. I'm thinking this would create a circular dependency problem, no?

The GetAPIKeysResult would need to be moved to shared package to be reused? Happy to move it somewhere, if you could please tell me what is the right place in the security code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have plugin_types_common, but I would probably ask for second opinion also before moving things around.
cc @jeramysoucy

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the ping! I added my feedback here

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
home 149.4KB 149.6KB +221.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
@kbn/security-plugin-types-public 0 1 +1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
cloudLinks 26.7KB 26.9KB +221.0B
security 69.1KB 69.3KB +262.0B
total +483.0B
Unknown metric groups

API count

id before after diff
@kbn/security-plugin-types-public 39 40 +1
security 413 414 +1
total +2

History

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

Comment on lines +23 to +32
const getCurrentUserApiKeyPrivileges = async () => {
const { canManageApiKeys, canManageCrossClusterApiKeys, canManageOwnApiKeys } =
(await http.get(
'/internal/security/api_key'
)) as AuthorizationCurrentUserApiKeyPrivilegesResponse;

return { canManageApiKeys, canManageCrossClusterApiKeys, canManageOwnApiKeys };
};

return { isRoleManagementEnabled, getCurrentUserApiKeyPrivileges };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GET /internal/security/api_key returns all API keys, which if there are many could make this slow. Additionally, this endpoint is being dropped and replaced with a query endpoint. See #168970

I'd suggest instead augmenting our authentication service to include the functionality that you want. This is where we already expose API key functions. See

You could add a getCurrentUserApiKeyPrivileges function in the authentication service that calls a new internal endpoint that ONLY returns the three flags you are looking for (canManageApiKeys, canManageCrossClusterApiKeys, canManageOwnApiKeys), e.g. GET /internal/security/api_key/_check_privileges

Additionally, this would be exposed on the server side as well here:

Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment

@@ -22,5 +22,7 @@
"@kbn/cloud-plugin",
"@kbn/share-plugin",
"@kbn/security-plugin-types-server",
"@kbn/security-plugin-types-public",
"@kbn/core",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not import from core's "plugin entry point" from package code. Imports from @kbn/core/server|public should be replaced with imports from core's corresponding domain packages instead.

Looking at the changes in this package, it seems this was added because of this import:

import { coreMock } from '@kbn/core/public/mocks';

used for

coreMock.createStart(),

Please use

import { coreLifecycleMock } from '@kbn/core-lifecycle-browser-mocks';

//...

coreLifecycleMock.createCoreStart()

instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes review Team:SharedUX Team label for AppEx-SharedUX (formerly Global Experience) v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Connection Details] Check if user has permissions to create API key
7 participants