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
Update
Request
PUT "_plugins/_security/config/jwt/jwt_auth_domain/skew_tolerance_seconds"
{
"value":77
}
Response
Set to default
Request
DELETE "_plugins/_security/config/jwt/jwt_auth_domain/skew_tolerance_seconds"
Response
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
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:
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
Response
Update
Request
Response
Set to default
Request
Response
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