Decision: Configure the OpenSearch security plugin

[siegfriedweber]

Description

The OpenSearch security plugin stores its configuration in a system index on the OpenSearch cluster. The initial configuration is taken from configuration files. Afterwards, the administrators can decide if they want to manage the configuration index via the OpenSearch API or overwrite it with updated configuration files. This decision can be made per configuration file.

The configuration files are (see also https://docs.opensearch.org/latest/security/configuration/yaml/):

• action_groups.yml: groups permissions, e.g. the action group cluster_monitor could contain all actions which are required to monitor a cluster.
• allowlist.yml: lists accessible API endpoints
• audit.yml: contains the audit log configuration
• config.yml: contains the configuration for authentication and authorization
• internal_users.yml: contains "reserved" users like admin and kibanaserver (used by OpenSearch Dashboards)
• nodes_dn.yml: can contain DNs of OpenSearch node certificates
• roles_mapping.yml: maps OpenSearch roles to backend roles (e.g. LDAP roles) and users
• roles.yml: assigns permissions to OpenSearch roles
• tenants.yml: adds OpenSearch Dashboards tenants to OpenSearch

For instance, administrators probably want to use the operator to only apply the initial roles_mapping.yml but afterwards use the security plugin in OpenSearch Dashboards to manage it. On the other hand, the config.yml should probably be managed completely by the operator.

Part of #43

Proposal

This proposal contains a general approach like configOverrides to cover all use cases. However, the current implementation of configOverrides is not sufficient because the mentioned YAML files contain deep structures. The security configuration only makes sense at the cluster level (not role or role-group level).

---
apiVersion: opensearch.stackable.tech/v1alpha1
kind: OpenSearchCluster
spec:
  clusterConfig:
    securityConfig:
      enabled: <boolean> # Enables or disables the security plugin; defaults to `true`
      actionGroups: # optional; defaults to an "empty" configuration file which only contains the necessary
                    # header
        managedBy: <string> # one of ["API", "operator"]; defaults to "API" for all configuration files
                            # because this is the default in OpenSearch, see
                            # https://docs.opensearch.org/latest/security/configuration/security-admin/#a-word-of-caution
        content: # one of ["value", "valueFrom"] similar to
                 # https://kubernetes.io/docs/concepts/configuration/configmap/#configmaps-and-pods
          value: <string> # file content
          valueFrom: # one of ["configMapKeyRef", "secretKeyRef"]
            configMapKeyRef:
              name: <string>
              key: <string>
            secretKeyRef: # Secrets are especially useful for `internal_users.yml` because it contains the
                          # bcrypted admin password
              name: <string>
              key: <string>
      allowList: <struct> # same structure as in `actionGroups`
      audit: <struct> # same structure as in `actionGroups`
      config: <struct> # same structure as in `actionGroups`
      internalUsers: <struct> # same structure as in `actionGroups`
      nodesDn: <struct> # same structure as in `actionGroups`
      rolesMapping: <struct> # same structure as in `actionGroups`
      roles: <struct> # same structure as in `actionGroups`
      tentants: <struct> # same structure as in `actionGroups`

It is not necessary to define the contents of all configuration files, because the "empty" default is already useful for actionGroups, allowList, audit, nodesDn, roles and tenants, and not so useful for config, internalUsers and rolesMapping. If nothing is configured, OpenSearch will start but it will not be accessible.

If the operator has the option to provide arbitrary security configurations, then it will be hard to integrate AuthenticationClasses later. If such an option is not provided, then the operator would probably be not useful in a lot of setups. Perhaps a solution could be to extend the structure for config.yml as follows:

spec:
  clusterConfig:
    securityConfig:
      config:
        enabled: <boolean>
        managedBy: <string> # one of ["API", "operator"]
        content: # one of ["value", "valueFrom"]
          value: <string>
          valueFrom: # one of ["configMapKeyRef", "secretKeyRef", "authenticationClasses"]
            configMapKeyRef:
              name: <string>
              key: <string>
            secretKeyRef:
              name: <string>
              key: <string>
            authenticationClasses: <list>
              - authenticationClass: <string>
                <additionalProperties>: ...

[soenkeliebau]

The initial configuration is taken from configuration files.
[...]
If nothing is configured, OpenSearch will start but it will not be accessible.

Would the operator need to do some magic in order to provision a fresh cluster that can be managed via the api? i.e. would it need to provide some files on the first start and then revert to not providing those on subsequent starts, or is that covered by implicit defaults/something similar somehow?

[siegfriedweber]

The initial configuration is taken from configuration files.
[...]
If nothing is configured, OpenSearch will start but it will not be accessible.

Would the operator need to do some magic in order to provision a fresh cluster that can be managed via the api? i.e. would it need to provide some files on the first start and then revert to not providing those on subsequent starts, or is that covered by implicit defaults/something similar somehow?

This is covered by the configuration setting plugins.security.allow_default_init_securityindex: true. If the security index does not exist, it is created with the provided files. If it exists, nothing is updated.