Skip to content

[FEATURE] Create a way to add action oriented APIs to update configuration values #2559

@peternied

Description

@peternied

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttriagedIssues labeled as 'Triaged' have been reviewed and are deemed actionable.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions