-
Notifications
You must be signed in to change notification settings - Fork 8k
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
base: main
Are you sure you want to change the base?
[Connection Details] Check if user has permissions to manage own API keys #183286
Conversation
@elasticmachine merge upstream |
Pinging @elastic/appex-sharedux (Team:SharedUX) |
2 similar comments
Pinging @elastic/appex-sharedux (Team:SharedUX) |
Pinging @elastic/appex-sharedux (Team:SharedUX) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
packages/cloud/connection_details/kibana/kibana_connection_details_provider.tsx
Show resolved
Hide resolved
getCurrentUserApiKeyPrivileges: () => Promise<AuthorizationCurrentUserApiKeyPrivilegesResponse>; | ||
} | ||
|
||
export interface AuthorizationCurrentUserApiKeyPrivilegesResponse { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
packages/cloud/connection_details/kibana/kibana_connection_details_provider.tsx
Show resolved
Hide resolved
…ails_provider.tsx Co-authored-by: elena-shostak <165678770+elena-shostak@users.noreply.github.com>
…tion_details_provider.tsx" This reverts commit 9b66af5.
💚 Build Succeeded
Metrics [docs]Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: |
const getCurrentUserApiKeyPrivileges = async () => { | ||
const { canManageApiKeys, canManageCrossClusterApiKeys, canManageOwnApiKeys } = | ||
(await http.get( | ||
'/internal/security/api_key' | ||
)) as AuthorizationCurrentUserApiKeyPrivilegesResponse; | ||
|
||
return { canManageApiKeys, canManageCrossClusterApiKeys, canManageOwnApiKeys }; | ||
}; | ||
|
||
return { isRoleManagementEnabled, getCurrentUserApiKeyPrivileges }; |
There was a problem hiding this comment.
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
const areAPIKeysEnabled = async () => |
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:
apiKeys: { |
There was a problem hiding this 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", |
There was a problem hiding this comment.
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
Summary
Closes #181288
security
plugin ability to check if use can manage own API keys, throughsecurity.authz.getCurrentUserApiKeyPrivileges()
.How to test
Add these Cloud settings to your
config/kibana.dev.yml
as a mock data:This will expose the "Setup guides" button in the top nav and the "Connect to the Elasticsearch API" card:
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.When the user does not have a permission to edit own API keys, the connection details flyout should show this message:
When user has permissions, it should allow to create a new API key:
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:
For maintainers