[FEATURE] Types for users and roles in opensearchapi

[defesteban]

Hello,

As I can see, currently there is no support for the users/roles API in opensearchapi. Could you please include this API to the client?

[wbeckler]

At the moment there are no clients with first-class support for the OpenSearch security plugin, which is where the users/roles live. This would be a good project for anyone to start working on.

Does anyone have any concerns with this functionality in the client?

[Jakob3xD]

@dblock @VachaShah Are there any requirements given for implementing the security plugin to the opensearch-go lib?
I would make it an extra package as security is a plugin with a custom API and it also has a different error response.
I also created a first Draft on how this could look like for USERS (missing PATCH).

I am not quite sure if I should return the full response like in the opensearchapi package in addition to the custom type for folks that want to do special/custom stuff.

[dblock]

I think that's a good start. We want support for all these plugins here.

Please note that eventually we'd like to generate the client code from API specs, and support multiple versions of the server (s) in the same client without hard-coding all this stuff. @Xtansia care to copy-paste some interesting links about what you're doing in java here?

[sesheffield]

Here is a draft for security role mappings.
I added it to the opensearchapi directory, but could follow the same path of @Jakob3xD and create a new directory.

[jgillich]

I used the OpenAPI spec to generate a client that supports the security plugin: https://github.com/jgillich/opensearch-client-go

Example:

ctx = context.WithValue(context.Background, opensearch.ContextBasicAuth, opensearch.BasicAuth{
    UserName: "admin",
    Password: "password",
})

client := opensearch.NewAPIClient(&opensearch.Configuration{
    Servers: opensearch.ServerConfigurations{
        {
            URL: "http://yourserver:9200",
        },
    },
}).DefaultAPI

hash, err := bcrypt.GenerateFromPassword("example", bcrypt.DefaultCost)
if err != nil {
    return  err
}

if _, _, err := client.CreateUser(ctx, indexPrefix.Name).User(opensearch.User{
    Hash: pointer.String(string(hash)),
}).Execute(); err != nil {
    return fmt.Errorf("create user: %w", err)
}

I am running into an issue with creating roles though, the payload is exactly what's in the docs but the server returns:

{"status":"error","reason":"Invalid configuration","invalid_keys":{"keys":"index_permission,cluster_permission"}}

All the relevant code to generate this is at .github/workflows/generate.yaml if someone wants to take this as a basis for an official client

[dblock]

@davidlago or @peternied do you know anything about these? ^

[thethir13en]

@jgillich

Hello, seems like you're using singular form of key names:

• index_permission
• cluster_permission

But them must be plural:

• index_permissions
• cluster_permissions

Example in docs: https://opensearch.org/docs/latest/security/access-control/api/#roles

[jgillich]

Yup, I've already fixed these and a few other issues in the OpenAPI spec repo (opensearch-project/opensearch-api-specification#153), it's working great now.

[Jakob3xD]

@dblock I am currently writing code to implement the security plugin and had issue with testing.

Right now we have a matrix of opensearch versions and secure plugin enabled or disabled. Handling this with build tags is annoying as every integration tests that currently exists would need the additional tag !secure, as we only test the opensearchapi functions against opensearch without security.

So to prevent this my suggestion is to create a helper function that creates a client depending on security enabled or not, and skipping security tests when running opensearch without security. So all opensearchapi test would also run on a secure opensearch in addition with security tests and if security is disabled they get skipped and are displayed as skipped by go.

Any concerns with that?

[dblock]

Any concerns with that?

No concerns.

Generally I prefer declarative ways of doing things in the configuration rather than code, but that's a high level handwavy statement ;)