[FEATURE] Support configuring auth_failure_listeners through Dashboards

[cwperks]

Is your feature request related to a problem?

The OpenSearch Security plugin has a useful feature called auth_failure_listeners that allows cluster administrators to block requests after a certain number of requests fail authentication in a window of time. Currently, there are 2 types of auth_failure_listeners: 1) IP-based and 2) username-based.

See example below, for configuring an auth_failure_listener based on username that will block requests for 60 seconds if 3 requests fail authentication within a 60 second window:

auth_failure_listeners:
  internal_authentication_backend_limiting:
    type: username
    authentication_backend: internal
    allowed_tries: 3
    time_window_seconds: 60
    block_expiry_seconds: 60
    max_blocked_clients: 100000
    max_tracked_clients: 100000

Currently, cluster administrators can only configure these rate limiters through the config.yml file meaning they either need to configure it 1) Before cluster initialization, 2) Using securityadmin.sh or 3) through the security API using an admin cert

This feature of the Security plugin should have associated UX to make the feature more discoverable and to make it easy to configure for administrators.

[stephen-crawford]

[Triage] Hi @cwperks, thanks for filing this issue. This seems like a nice feature request.

[derek-ho]

Thanks for this request @cwperks ! I had a few questions:

• As it seems like this is a yaml setting, do we have APIs exposed by the backend to revise these settings/pull the values?
• Do we need specific permissions (i.e. admin cert or admin credentials) to read/update these values?

[cwperks]

@derek-ho There are APIs to update the securityconfig, but we do not allow usage of those by default and they allow you to update any portion of the securityconfig. To build UX for these rate limiters, I think it makes sense to add APIs where the purpose of the API is to enable or disable a rate limiter and allow any user with security REST Api privileges to ability to use those APIs.

For the second question, the answer is yes and no. In general, the way that permission to granted to use security apis is through a role that has security API privileges: plugins.security.restapi.roles_enabled.

That being said, there is a feature where security APIs can be granted individually through restapi:admin/... permissions like restapi:admin/internalusers. The API should be individually permissable like other security APIs.

[derek-ho]

Cool, I will create an issue in the security repo to build those APIs. That will help too with the individual permissioning which makes more sense in this situation I think, for example I wouldn't want a person with access to the security plugin pages to be able to start throttling the admin, does that make sense?

[cwperks]

When using roles based access for the security APIs, anyone mapped to one of the security API roles should be regarded as an administrator.