-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
Adding authc.areAPIKeysEnabled which uses _xpack/usage #55255
Conversation
Thanks for the quick PR :) |
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.
Look goods to me 👍
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
ACK: reviewing... |
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.
LGTM
if (hasPrivilegesImpl) { | ||
mockScopedClusterClient.callAsCurrentUser.mockImplementationOnce(hasPrivilegesImpl); | ||
} | ||
if (areAPIKeysEnabledImpl) { |
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.
optional nit: new line between if
's
@@ -164,4 +164,19 @@ export class APIKeys { | |||
|
|||
return result; | |||
} | |||
|
|||
async areEnabled(): Promise<boolean> { |
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.
nit: I believe : Promise<boolean>
isn't necessary and should be automatically inferred
path: '/_xpack/usage', | ||
}); | ||
|
||
return result.security?.api_key_service?.enabled === true; |
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: the only thing that worries me a bit here is that we don't have a proper ES documentation on the format of this response and it's not clear what BWC guarantees this API has. If format changes this line will "silently" start always returning false
.
Ideally I'd have an API integration test (e.g. via plugin-fixture that depends on security
plugin, luckily we can have NP plugin fixtures now), but it seems we don't have any integration tests for the API keys functionality so it's not a blocker for this PR, up to you.
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.
That's a great point, let me add API integrations tests specifically for this.
I spoke to @tvernum about this, and relying upon @nchaulet the other options we're exploring rely on parsing the response correctly from calling one of the API Key APIs, can you make this work with your use-case? |
Would a status code of |
I definitely think that'd help. We'd likely still have to do some parsing on the response body itself to ensure we don't mistake a 503 being caused by something else, for example a mis-configured reverse-proxy between Kibana and Elasticsearch. |
The ES JSON response includes the status, so you could easily check that the body status code and the HTTP status code were aligned. |
That'd work beautifully then :) |
@kobelb for me as a consumer the part that interest me is Just relaying on the status code seems a bit unreliable but it it's coupled with another code in the response body, seems good. Also not sure 503 is the best status code for that a 4x seems more suitable, I already saw people using 403 for a feature not activated. |
@nchaulet Unfortunately, we don't have an Elasticsearch API which we can use to definitively answer this question. As long as Fleet is able to rely on deriving this information from an API call to create/get/update an API Key, the security plugin can expose a consistent way to determine whether or not the error indicates that API Keys are disable or not. |
@kobelb We can do a call to |
Closing in favor of a different approach outlined in #59576 |
Previously, this was being done within the
/internal/security/api_key/privileges
route by checking the error that was throw by trying to get all API keys. @nchaulet requested that we expose this functionality, and @legrego brought up using the_xpack/usage
API to make this determination. The rest is history 📖