Service Accounts - cache clear API #71605
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,56 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| package org.elasticsearch.xpack.security.rest.action.service; | ||
|
|
||
| import org.elasticsearch.client.node.NodeClient; | ||
| import org.elasticsearch.common.settings.Settings; | ||
| import org.elasticsearch.license.XPackLicenseState; | ||
| import org.elasticsearch.rest.RestRequest; | ||
| import org.elasticsearch.rest.action.RestActions; | ||
| import org.elasticsearch.xpack.core.security.action.ClearSecurityCacheAction; | ||
| import org.elasticsearch.xpack.core.security.action.ClearSecurityCacheRequest; | ||
| import org.elasticsearch.xpack.security.rest.action.SecurityBaseRestHandler; | ||
|
|
||
| import java.io.IOException; | ||
| import java.util.Arrays; | ||
| import java.util.List; | ||
|
|
||
| import static org.elasticsearch.rest.RestRequest.Method.POST; | ||
|
|
||
| public class RestClearServiceAccountTokenStoreCacheAction extends SecurityBaseRestHandler { | ||
|
|
||
| public RestClearServiceAccountTokenStoreCacheAction(Settings settings, XPackLicenseState licenseState) { | ||
| super(settings, licenseState); | ||
| } | ||
|
|
||
| @Override | ||
| public List<Route> routes() { | ||
| return List.of(new Route(POST, "/_security/service/{namespace}/{service}/credential/token/{name}/_clear_cache")); | ||
| } | ||
|
|
||
| @Override | ||
| public String getName() { | ||
| return "xpack_security_clear_service_account_token_store_cache"; | ||
| } | ||
|
|
||
| @Override | ||
| protected RestChannelConsumer innerPrepareRequest(RestRequest request, NodeClient client) throws IOException { | ||
| final String namespace = request.param("namespace"); | ||
| final String service = request.param("service"); | ||
| String[] tokenNames = request.paramAsStringArrayOrEmptyIfAll("name"); | ||
|
|
||
| ClearSecurityCacheRequest req = new ClearSecurityCacheRequest().cacheName("service"); | ||
| if (tokenNames.length == 0) { | ||
| // This is the wildcard case for tokenNames | ||
| req.keys(namespace + "/" + service + "/"); | ||
| } else { | ||
| req.keys(Arrays.stream(tokenNames).map(name -> namespace + "/" + service + "/" + name).toArray(String[]::new)); | ||
| } | ||
|
There was a problem hiding this comment. This cache clearing URL is different from all the other ones in that the cache key is comprised of three parts, i.e. So for now, I am keep this simple by taking the There was a problem hiding this comment. I think this is fine. If we get to the point where we think something like this is needed, then maybe we actually want to clear all caches for all service accounts. Alternatively, for App Privileges we only support clearing a whole application (not a specific privilege) There was a problem hiding this comment. Cool. I'll leave it as is then. Always clearing all tokens of a service account can provide some simplication, but not a lot. Since I already have things in place, I'd just keep them. Plus even with the clearing applicaiton privileges cache API, the URL format is something like |
||
| return channel -> client.execute(ClearSecurityCacheAction.INSTANCE, req, new RestActions.NodesResponseRestListener<>(channel)); | ||
| } | ||
| } | ||
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.
I made this change so the logic is mostly the same as the one of
CachingUsernamePasswordRealm. Basically the cache now does not cache negative results. I think this is a better choice since service account will be well known and it is easy to cause cache thrashing if negative results are cached. This is probably the similar argument whyCachingUsernamePasswordRealmdoes not cache negative results as well. Note thatApiKeyServicecache is different in that it does cache negative results. But it can afford to do that because the ApiKey ID, unlike username/service account, is not well known.