-
Notifications
You must be signed in to change notification settings - Fork 358
[FEATURE] Create a way to add action oriented APIs to update configuration values #2559
Description
Is your feature request related to a problem?
The security config of OpenSearch covers a lot of surface area. Some of these settings are very sensitive, others operators might want to allow for more control over. There is no clean way to provide granular access to these settings.
Lets take into consideration a recent configuration setting that was added jwt_clock_skew_tolerance_seconds. The legwork required to expose GET / POST / DELETE (restore to default value) is large and difficult.
What solution would you like?
There should be a way to declare that there should be an configuration based action handler to support exposing this setting such as the following:
new ConfigActionDescription().Builder()
.valueType(ConfigActionType.Integer)
.route("_plugins/_security/config/jwt/{auth_domain}/skew_tolerance_seconds")
.permission("securityconfig:admin/config/jwt/skew_tolerance_seconds")
.configPath("config.dynamic.authc.{auth_domain}.http_authenticator.config.jwt_clock_skew_tolerance_seconds")
.onDeleteDefaultValue(DEFAULT_CLOCK_SKEW_TOLERANCE_SECONDS)
.build();- Note; type safety constraints might make this more slightly more complex
After registering the ConfigActionDescription object a handler would be built up that would support integer values following a straight forward convention of retrieve, update and set to default. When attempting to access the endpoint, the permission would would be required to be prefixed with 'securityconfig:' and read from the users roles.
Example REST APIs
Retrieve
Request
GET "_plugins/_security/config/jwt/jwt_auth_domain/skew_tolerance_seconds"
Response
200 OK
{
"value": 30
}
Update
Request
PUT "_plugins/_security/config/jwt/jwt_auth_domain/skew_tolerance_seconds"
{
"value":77
}
Response
200 OK
{
"value": 77
}
Set to default
Request
DELETE "_plugins/_security/config/jwt/jwt_auth_domain/skew_tolerance_seconds"
Response
200 OK
{
"value": 77
}
Do you have any additional context?
I think this would be a good way to work through problems around duplicate data and filtered access for dynamically modifying tenant config. I think using a 'action' oriented framework would help create abstraction layers from being exposed to downstream users, e.g. GET _plugins/_security/config/tenancy/multitenancy_enabled