Add enabled status for token and api key service#38687
Add enabled status for token and api key service#38687bizybot merged 4 commits intoelastic:masterfrom
Conversation
Right now there is no way to determine whether the token service or API key service is enabled or not. This commit adds the enabled status for token and API key service to security feature set usage API `/_xpack/usage`.
|
Pinging @elastic/es-security |
| realmsUsage = in.readMap(); | ||
| rolesStoreUsage = in.readMap(); | ||
| sslUsage = in.readMap(); | ||
| if (in.getVersion().onOrAfter(Version.V_7_1_0)) { |
There was a problem hiding this comment.
If I got it right should be Version.CURRENT and do the dance 😢 : commit to master, change to Version.V_7_1_0 in the backport commit, disable bwc tests, commit to 7.x, wait for green intake, then change to Version.V_7_1_0 in the master, and enable bwc tests . If you learn of an easier method lemme know please! I'll admit it, in the past I cut a few corners on this...
There was a problem hiding this comment.
I think you are right, I have changed this to CURRENT with a TODO, will address it on backport to 7.x.
Thank you for your comment.
| realmsUsage = in.readMap(); | ||
| rolesStoreUsage = in.readMap(); | ||
| sslUsage = in.readMap(); | ||
| if (in.getVersion().onOrAfter(Version.CURRENT)) { // TODO change the version to V_7_1_0 on backporting |
There was a problem hiding this comment.
I think you should use V_8_0_0 instead of current but it doesn't matter much since it will change later on
| final boolean transportSSLEnabled = randomBoolean(); | ||
| settings.put("xpack.security.transport.ssl.enabled", transportSSLEnabled); | ||
|
|
||
| boolean configureEnabledFlagForTokenAndApiKeyServices = randomBoolean(); |
There was a problem hiding this comment.
I think it would be best to separate these two services enabled in the test. That way we wouldn't miss a bug that mistakenly reports the wrong value if one service is enabled and the other is not
|
Hi @jaymode, I have addressed your review comments, please take a look when you get some time. Thank you. |
Right now there is no way to determine whether the token service or API key service is enabled or not. This commit adds support for the enabled status of token and API key service to the security feature set usage API `/_xpack/usage`. Closes elastic#38535
Right now there is no way to determine whether the token service or API key service is enabled or not. This commit adds support for the enabled status of token and API key service to the security feature set usage API `/_xpack/usage`. Closes #38535
* elastic/master: Remove immediate operation retry after mapping update (elastic#38873) Remove mentioning of types from bulk API docs (elastic#38896) SQL: change JDBC setup URL in the documentation (elastic#38564) Skip BWC tests in checkPart1 and checkPart2 (elastic#38730) Enable silent FollowersCheckerTest (elastic#38851) Update TESTING.asciidoc with platform specific instructions (elastic#38802) Use consistent view of realms for authentication (elastic#38815) Stabilize RareClusterState (elastic#38671) Increase Timeout in UnicastZenPingTests (elastic#38893) Do not recommend installing vagrant-winrm elastic#38887 _cat/indices with Security, hide names when wildcard (elastic#38824) SQL: fall back to using the field name for column label (elastic#38842) Fix LocalIndexFollowingIT#testRemoveRemoteConnection() test (elastic#38709) Remove joda time mentions in documentation (elastic#38720) Add enabled status for token and api key service (elastic#38687)
|
Unless I am missing something, I don't think this change needed to disable all BWC testing. I think a targeted subset of BWC tests could have been disabled. |
|
You are probably right; it was an oversight on my part since this API is only called from a few tests. |
| out.writeMap(realmsUsage); | ||
| out.writeMap(rolesStoreUsage); | ||
| out.writeMap(sslUsage); | ||
| out.writeMap(tokenServiceUsage); |
There was a problem hiding this comment.
@bizybot I missed this in my review but there is a bug here; we write the map always without checking the version. We need the same guards on both reading and writing
There was a problem hiding this comment.
True I missed this as well, Thanks for addressing this.
This change makes the writing of new usage data conditional based on the version that is being written to. A test has also been added to ensure serialization works as expected to an older version. Relates elastic#38687, elastic#38917
Right now there is no way to determine whether the
token service or API key service is enabled or not.
This commit adds support for the enabled status of
token and API key service to security feature set
usage API
/_xpack/usage.Closes #38535