Adding authc.areAPIKeysEnabled which uses _xpack/usage #55255
Conversation
kobelb
added
release_note:skip
|
Thanks for the quick PR :) |
|
@elasticmachine merge upstream |
馃挌 Build SucceededHistory
To update your PR or re-run it, just comment with: |
|
ACK: reviewing... |
| if (hasPrivilegesImpl) { | ||
| mockScopedClusterClient.callAsCurrentUser.mockImplementationOnce(hasPrivilegesImpl); | ||
| } | ||
| if (areAPIKeysEnabledImpl) { |
There was a problem hiding this comment.
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.
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.
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.
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/privilegesroute 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/usageAPI to make this determination. The rest is history 馃摉