Set replicas if local storage file enabled

[Gyzes]

Hi!
I am using authelia in "Deployment" mode. The users file is mounted to each pod as a ConfigMap. But since .Values.configMap.authentication_backend.file.enabled is set to "true", the number of replicas is automatically set to 1 (code).
Is it possible to modify the check for the case when we are sure that the file will be identical on each pod?

Now after every update I have to run kubectl scale --replicas=xxx

[james-d-elliott]

This was due to thinking this was a stateful choice, but users can probably get around this by ensuring all pods are restarted (thus we can disable the forced replica count), and we can probably look to making the user DB reload a thing.

[fogninid]

I am also trying to use an externally-managed file authentication-backend, but the chart is ignoring .Values.pod.replicas and overriding it to 1.

My understanding of the statelessness#authentication-provider documentation is that the following values should allow pods to be stateless:

# helm .Values
configMap:
  authentication_backend:
    file:
      enabled: true
      path: /secrets/authelia-users/users.yaml
      watch: true
    password_change:
      disable: true
    password_reset:
      disable: true
  session:
    cookies:
    - domain: example.com
      subdomain: auth
    redis:
      enabled: true
  storage:
    local:
      enabled: false
    postgres:
      enabled: true
secret:
  additionalSecrets:
    authelia-users: {}
pod:
  kind: Deployment
  replicas: 2

[james-d-elliott]

The documentation for stateful nature of the chart is in the documentation for the chart here.

[fogninid]

The documentation for stateful nature of the chart is in the documentation for the chart here.

right, but why is it so? I do not see the reason why the chart should be more restrictive than authelia-the-application

The authelia documentation I linked above currently says:

Solution [for stetefulness of authentication_provider]: Use an authentication provider other than file (LDAP), or distribute the file and disable password reset.

Are the values I posted above not doing that? If yes, I would appreciate at least an override flag in the chart that allows me to run with multiple replicas.

[james-d-elliott]

right, but why is it so? I do not see the reason why the chart should be more restrictive than authelia-the-application

It's not?

We do not support using the file type in these scenarios.

[james-d-elliott]

I'll make it crystal clear in the docs.

[fogninid]

well, agree to disagree

I'll make it crystal clear in the docs.

I suppose you mean also the app docs, not only the chart?

I still do not understand what is the intention of writing "partially supported" and giving a recommendation there

Severity: MEDIUM (limiting).
Solution: Use an authentication provider other than file (LDAP), or distribute the file and disable password reset.
Use of the file authentication provider (YAML) is only partially supported with high availability setups. It’s recommended if you don’t use a stateless provider that you disable password reset and make sure the file is distributed to all instances. We do not support using the file type in these scenarios.

[james-d-elliott]

well, agree to disagree

You can configure anything you want with the chart, just use the configMap.existingConfigMap which is what it's for and gives you the same restrictions as the application itself. If you want a curated experience free from footguns then use the other values.

I can update the docs on this value to be more clear on the intention behind it.

I suppose you mean also the app docs, not only the chart?

Yeah docs have been clarified. In summary we're not going out of our way to support footguns, it's supported as so far as it "may work if everything is perfectly setup and implemented correctly by the party performing distribution", but issues will need replication with a single instance using a local file to be supported.

[fogninid]

You can configure anything you want with the chart, just use the configMap.existingConfigMap which is what it's for and gives you the same restrictions as the application itself. If you want a curated experience free from footguns then use the other values.

Thanks, this option is what I was looking for.

Yeah docs have been clarified. In summary we're not going out of our way to support footguns, it's supported as so far as it "may work if everything is perfectly setup and implemented correctly by the party performing distribution", but issues will need replication with a single instance using a local file to be supported.

Appreciate it! It is now clear to me what is meant with "support" there and how to operate the chart accordingly.

I am not the original reported of this github issue, but should it then be closed?
My understanding is now that the answer to the original question would be: "you can do it by using you own configMap, taking ownership that it will work correctly only if you did everything right there."