New AuthenticationClass provider: static

[sbernauer]

We have multiple products (e.g. Trino) that can take a list of usernames + passwords and authenticate users against that list (see https://trino.io/docs/current/security/password-file.html)
Trino e.g. takes a list of bcrypt passwords.

We need an standardized way to express such list of usernames + passwords. We already have the standardized AuthenticationClass, so we want a new provider 'static'

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: simple-trino-users
spec:
  provider:
    static:
      userCredentialsSecret:
        name: simple-trino-users-secret # mandatory, needs to be in same Namespace as product
---
apiVersion: v1
kind: Secret
metadata:
  name: simple-trino-users-secret
  namespace: default
type: kubernetes.io/opaque
stringData:
  admin: admin
  alice: superpass
  bob: secret

The only possible problem is that the AuthenticationClass is cluster-scoped and Secrets are namespaced.
It might be the case that the current solution has the downside that the userCredentialsSecret needs to be in the same Namespace as the Product using it (Secrets can't be mounted cross-namespace). A solution could be the cluster-scoped SecretClass but that introduces complexity

• We store the credentials as plain text within the Secret. Some products need the credentials as plain text, others hashed. To achieve a commons mechanism we need to store the credentials in plain text.
• The secret gets mounted as files. The entrypoint of the product Pod collects them together in the format accepted by the product. If hashing is need it hashes as well. If it makes sense, parts are moved to operator-rs.
• Restart-controller is enabled and should work as normal
• OPTIONAL: Some product allow hot-reloading the credentials (e.g. Trino). In this case no restart shut be done, i think the secret should update automatically. This would need additional functionality in restart controller to white- or blacklist certain volumes.
• If hot-reloading is not implemented, follow-up ticket is created.
• Documentation exists (ideally also for tls, see this comment but if that becomes too much we can split this in an extra ticket

[nightkr]

This is tricky... Ideally we'd only store the passwords in a hashed form, but that assumes that every service uses the same hashing scheme. Additionally, PBKDFs are nondeterministic and slow, so we'd need a strategy of some kind to figure out when to regenerate downstream credential files...

[sbernauer]

Yeah, i think we have multiple products such as Superset admin user that need the credentials in plain text.

[sbernauer]

The problem with consistent hashing remains. I see the following (non-exhausting) options:

1. Mount the secrets as files and hash stuff in the product entrypoint. Restart controller should work normally. Code to generate entrypoint command should be moved into operator-rs.
   • Actually e.g. Trino can hot-reload this lists, so no restart needed
     • Maybe this needs new functionality in restart controller, because we want it to restart when ldap credentials change, but not if user credentials change. Something like restarter.stackable.tech/volumeBlacklist or similar
2. Commons operator watches the credentials secret and automatically creates a new secret or adds keys to the secret containing the hashed variants. This might make things easier, but the commons-op needs to handle user credentials which we try to avoid.

[lfrancke]

Just to keep it in mind: One result of your refinement could be to just not do it now
If this turns out to be much more effort than expected (more than 1 week) we might skip it for now as we have more important things to work on.

[sbernauer]

Further refined the ticket, would present it after daily (thus blocking it).
I think this ticket only introduces things in operator-rs (and subsequentially commons-operator). Should be easily doable in a week (don't quote me on that :D).

[sbernauer]

Presented after daily