-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Expose ability to check if API Keys are enabled #63454
Changes from all commits
5b7695c
ccdd46d
4c93afc
2489634
71c88cf
4ccbf44
9f33dab
6b5a98f
98bcdc4
91f468c
1f78e8c
6a65e6e
5daaf30
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -125,6 +125,35 @@ export class APIKeys { | |
this.license = license; | ||
} | ||
|
||
/** | ||
* Determines if API Keys are enabled in Elasticsearch. | ||
*/ | ||
async areAPIKeysEnabled(): Promise<boolean> { | ||
if (!this.license.isEnabled()) { | ||
return false; | ||
} | ||
|
||
const id = `kibana-api-key-service-test`; | ||
|
||
this.logger.debug( | ||
`Testing if API Keys are enabled by attempting to invalidate a non-existant key: ${id}` | ||
); | ||
|
||
try { | ||
await this.clusterClient.callAsInternalUser('shield.invalidateAPIKey', { | ||
body: { | ||
id, | ||
}, | ||
}); | ||
return true; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: what does it mean if ES replies with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, thanks for confirming. Just out of curiosity, @jkakavas is there any valid reason to return different status codes for "unknown" api keys and access tokens during invalidation or we just didn't have chance to unify that yet? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's the latter. I just opened elastic/elasticsearch#55671 to keep track of the work needed for the invalidate api keys API |
||
} catch (e) { | ||
if (this.doesErrorIndicateAPIKeysAreDisabled(e)) { | ||
return false; | ||
} | ||
throw e; | ||
} | ||
} | ||
|
||
/** | ||
* Tries to create an API key for the current user. | ||
* @param request Request instance. | ||
|
@@ -247,6 +276,11 @@ export class APIKeys { | |
return result; | ||
} | ||
|
||
private doesErrorIndicateAPIKeysAreDisabled(e: Record<string, any>) { | ||
const disabledFeature = e.body?.error?.['disabled.feature']; | ||
return disabledFeature === 'api_keys'; | ||
} | ||
|
||
private getGrantParams(authorizationHeader: HTTPAuthorizationHeader): GrantAPIKeyParams { | ||
if (authorizationHeader.scheme.toLowerCase() === 'bearer') { | ||
return { | ||
|
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.
note previously, the API Keys app had a dual purpose for
areApiKeysEnabled
: It was true if and only if both of the following were true:This separates those two concerns into dedicated properties