Issue working with v0.9 and up

[thamudi]

Hello.

Recently we decided to upgrade to from v0.8.54 to v0.9.5. After reading and following the BREAKING.md guidelines on the major changes we are still unable to install the chart due to the following error:

level=error msg="Configuration: storage: postgres: option 'username' and 'password' are required"                                                                                        
level=error msg="Configuration: storage: option 'encryption_key' is required"                                                                                                            
level=error msg="Configuration: identity_validation: reset_password: option 'jwt_secret' is required when the reset password functionality isn't disabled"

The error message shows that the username and the password are not being detected for the postgres configuration. This could be for multiple reasons:

1. The Chart is not able to map the secrets to the pod. However after checking the pod the secrets are being mounted as expected to /secrets/authelia-secrets
2. The path to the secret is not being propagated properly or it doesnt have the proper permission policy to it.
3. Wrong configuration on our end. And this is where I am hoping if you can shed some light since we followed everything possible in your documentation and the breaking changes note.

---

Here are the configuration for these storage section:

 storage:

        encryption_key:
          ## Disables this secret and leaves configuring it entirely up to you.
          disabled: false

          ## The secret name. The ~ name is special as it is the secret we generate either automatically or via the
          ## secret_value option below.
          secret_name: authelia-secrets

          ## The value of a generated secret when using the ~ secret_name.
          value: ''

          ## The path to the secret. If it has a '/' prefix it's assumed to be an absolute path within the pod. Otherwise
          ## it uses the format '{mountPath}/{secret_name}/{path}' where '{mountPath}' refers to the 'secret.mountPath'
          ## value, '{secret_name}' is the secret_name above, and '{path}' is this value.
          path: 'storage.encryption.key'
        local:
          enabled: false
          path: /config/db.sqlite3
        ##
        ## PostgreSQL (Storage Provider)
        ##
        postgres:
          enabled: true
          deploy: false
          address: 'tcp://postgresql-db-do-user-0000000-0.b.db.ondigitalocean.com:22222'
          timeout: '5 seconds'
          database: 'authelia'
          schema: 'public'
          username: 'authelia_admin'
          password:
            ## Disables this secret and leaves configuring it entirely up to you.
            disabled: true

            ## The secret name. The ~ name is special as it is the secret we generate either automatically or via the
            ## secret_value option below.
            secret_name: authelia-secrets

            ## The value of a generated secret when using the ~ secret_name.
            value: ''

            ## The path to the secret. If it has a '/' prefix it's assumed to be an absolute path within the pod. Otherwise
            ## it uses the format '{mountPath}/{secret_name}/{path}' where '{mountPath}' refers to the 'secret.mountPath'
            ## value, '{secret_name}' is the secret_name above, and '{path}' is this value.
            path: 'storage.postgres.password.txt'
          tls:
            enabled: false

            ## The server subject name to check the servers certificate against during the validation process.
            ## This option is not required if the certificate has a SAN which matches the host option.
            server_name: ''

            ## Skip verifying the server certificate entirely. In preference to setting this we strongly recommend you add the
            ## certificate or the certificate of the authority signing the certificate to the certificates directory which is
            ## defined by the `certificates_directory` option at the top of the configuration.
            ## It's important to note the public key should be added to the directory, not the private key.
            ## This option is strongly discouraged but may be useful in some self-signed situations where validation is not
            ## important to the administrator.
            skip_verify: false

            ## Minimum TLS version for the connection.
            minimum_version: 'TLS1.2'

            ## Maximum TLS version for the connection.
            maximum_version: 'TLS1.3'

And the secrets are applied and mapped properly as well.

    ##
    ## Authelia Secret Configuration.
    ##
    secret:
      disabled: true
      existingSecret: 'authelia-secrets'
      annotations: {}
      labels: {}
      mountPath: '/secrets'
      additionalSecrets:
        authelia-secrets: {}

authelia-secrets

apiVersion: v1
kind: Secret
metadata:
    name: authelia-secrets
    namespace: test
type: Opaque
data:
    identity_validation.reset_password.jwt.hmac.key: UXVpc3F1ZSBhbGlxdWV0IHBsYWNlcmF0IG9yY2kgdXQgdWx0cmljZXMuIFBoYXNlbGx1cyBldSBuZXF1ZSBsb3JlbS4gRnVzY2UgZmluaWJ1cyBhbnRlIGF0IG1hZ25hIGVmZmljaXR1ciwgdm9sdXRwYXQgZGljdHVtIHF1YW0gbWFsZXN1YWRhLiBBZW5lYW4gdmVoaWN1bGEgcGVsbGVudGVzcXVlIG1pIHZlbCBmYXVjaWJ1cy4gTWF1cmlzIGxhY2luaWEgZXUgZmVsaXMgYXVjdG9yIGVsZWlmZW5kLiBEb25lYyBwcmV0aXVtIHRlbXBvciBkaWN0dW0uIFByYWVzZW50IGEgbG9yZW0gdml0YWUgZGlhbSBtb2xsaXMgdGluY2lkdW50LiBDbGFzcyBhcHRlbnQgdGFjaXRpIHNvY2lvc3F1IGFkIGxpdG9yYSB0b3JxdWVudCBwZXIgY29udWJpYSBub3N0cmEsIHBlciBpbmNlcHRvcyBoaW1lbmFlb3MuIEN1cmFiaXR1ciBpZCB2dWxwdXRhdGUgbnVuYy4gRG9uZWMgZWdldCBtYWduYSBhcmN1LiBJbnRlZ2VyIHZpdGFlIG5pYmggbm9uIG1hc3NhIGVsZW1lbnR1bSB2ZW5lbmF0aXMu
    session.redis.password.txt: YWRtaW5Vc2VyaGVsbG8=
    storage.postgres.password.txt: YWRtaW5Vc2VyaGVsbG8=
    storage.encryption.key: UXVpc3F1ZSBhbGlxdWV0IHBsYWNlcmF0IG9yY2kgdXQgdWx0cmljZXMuIFBoYXNlbGx1cyBldSBuZXF1ZSBsb3JlbS4gRnVzY2UgZmluaWJ1cyBhbnRlIGF0IG1hZ25hIGVmZmljaXR1ciwgdm9sdXRwYXQgZGljdHVtIHF1YW0gbWFsZXN1YWRhLiBBZW5lYW4gdmVoaWN1bGEgcGVsbGVudGVzcXVlIG1pIHZlbCBmYXVjaWJ1cy4gTWF1cmlzIGxhY2luaWEgZXUgZmVsaXMgYXVjdG9yIGVsZWlmZW5kLiBEb25lYyBwcmV0aXVtIHRlbXBvciBkaWN0dW0uIFByYWVzZW50IGEgbG9yZW0gdml0YWUgZGlhbSBtb2xsaXMgdGluY2lkdW50LiBDbGFzcyBhcHRlbnQgdGFjaXRpIHNvY2lvc3F1IGFkIGxpdG9yYSB0b3JxdWVudCBwZXIgY29udWJpYSBub3N0cmEsIHBlciBpbmNlcHRvcyBoaW1lbmFlb3MuIEN1cmFiaXR1ciBpZCB2dWxwdXRhdGUgbnVuYy4gRG9uZWMgZWdldCBtYWduYSBhcmN1LiBJbnRlZ2VyIHZpdGFlIG5pYmggbm9uIG1hc3NhIGVsZW1lbnR1bSB2ZW5lbmF0aXMu
    session.encryption.key: SW4gc2l0IGFtZXQgZXggbG9yZW0uIFN1c3BlbmRpc3NlIHBvdGVudGkuIE1hdXJpcyBzZWQgdmFyaXVzIG5pc2wuIFV0IGhlbmRyZXJpdCB0dXJwaXMgdml0YWUgdGVtcG9yIGZldWdpYXQuIFBoYXNlbGx1cyBwdWx2aW5hciBldSBzYXBpZW4gZWdldCBjb25kaW1lbnR1bS4=
    notifier.smtp.password.txt: YWRtaW5Vc2VyaGVsbG8=
    authentication.ldap.password.txt: YWRtaW5Vc2VyaGVsbG8=

[james-d-elliott]

You have disabled the management of the postgres password secret entirely. You'd need to either enable that or set the volume mount and relevant env vars manually.

[thamudi]

I have just tried enabling the postgres password secret management. And disabled the secret mounting. Same issues remains.

I took a look at the templates and I couldn't find any references of Values.configMap.storage.postgres.password.disabled

[james-d-elliott]

The authelia.secret.generate template handles this logic.

Why did you change values additional to what was requested?

[thamudi]

Ah okay, it makes sense now.

I only changed what is needed in order provide secrets to run my postgres RDS.

EDIT: I am still missing what is needed in order establish a connection with postgres using my secrets.

[laurayco]

I'm also experiencing issues with the secrets changes - IME the:

• secret is generated correctly (I can see the relevant keys in base 64 in the secret)
• environment variables are set to the file names of these secrets in the scheduled pod. I can't sh into the pod to confirm the files contain the correct values as the program crashes before I have the opportunity.

and I (wasn't) adjusting any other secrets settings in the configmap, as reading the values.yaml indicates that the defaults behavior is to reference the k8s secret object & files.

tangentially, I'm also not seeing an ingress get generated despite, ingress.enabled and the relevant traefik specific properties set, but that may be more appropriate for a separate issue (could also absolutely be user error)

[abelfodil]

I encountered the same issue and ended up simply using the env vars to define secrets:

arch-anes/self-hosted-services@cb020f7

[elaurensx]

I encountered the same issue and ended up simply using the env vars to define secrets:

arch-anes/self-hosted-services@cb020f7

Also going down this path as figuring how secrets work with the chart has become too complex since the v0.9 changes. Downside is that all pods in the namespace now have access to the secrets.

[james-d-elliott]

This can't really be considered a secret, they're being set as environment variables; it kind of defeats the purpose of setting things like this as secrets to some degree. The environment variables can be dumped by external processes trivially and are generally more accessible.

I'm quite surprised since no one during the 4 months of the announced beta tests mentioned issues like this. I'll figure out the cause, the only thing that may help going forward is full values examples.

[elaurensx]

This can't be considered a secret, they're being set as environment variables. The environment variables can be dumped by external processes trivially and are generally more accessible.

True but risk can be alleviated by deploying authelia in its own namespace and poking just the couple needed holes in a deny-all-egress network policy.

I'm quite surprised since no one during the 4 months of the announced beta tests mentioned issues like this. I'll figure out the cause, the only thing that may help going forward is full values examples.

Personally I have a 100+ apps running in my lab and since authelia is only used internally it gets thrown in the "upgrade once a year" bucket. I will say that while I can see and appreciate the work you put into this, I had a much simpler time navigating the pre v0.9 chart and it took me less time to set things up initially on v0.8 than it did upgrading to v0.9.

[abelfodil]

Unrelated to this issue, but would it be possible to make the chart flexible enough to use multiple external secrets?

For instance, I'm using 3 others secrets for SMTP, Redis and PostgreSQL because it's shared with other manifests. Right now, I'd have to copy them to the Authelia secret which isn't the most flexible way.

Appreciate your work btw!

[james-d-elliott]

True but risk can be alleviated by deploying authelia in its own namespace and poking just the couple needed holes in a deny-all-egress network policy.

This is not the case. The environment variables can potentially be read by processes either within the same k8s node or on the host OS. The manner in which they are read is substantially easier than files. The main reason we implemented the _FILE variation on environment variables was to mitigate this potential exfiltration path.

Personally I have a 100+ apps running in my lab and since authelia is only used internally it gets thrown in the "upgrade once a year" bucket. I will say that while I can see and appreciate the work you put into this, I had a much simpler time navigating the pre v0.9 chart and it took me less time to set things up initially on v0.8 than it did upgrading to v0.9.

I can somewhat understand this, however that was why the beta process was undertaken with this chart it had substantial changes around secrets and I wanted to ensure they made more sense than before. Nearly all the feedback suggested they were, probably all of it in fact until now.

I suppose I can't really convince anyone to come around to a more beneficial approach for everyone including themselves, I can only just hope and not let it concern me if it doesn't occur. C'est la vie.

Unrelated to this issue, but would it be possible to make the chart flexible enough to use multiple external secrets?

This is one of the elements that the new secret config should support. Feel free to open a discussion and I'll try to find some time to help or you can keep an eye on developments here.

[elaurensx]

Personally I have a 100+ apps running in my lab and since authelia is only used internally it gets thrown in the "upgrade once a year" bucket. I will say that while I can see and appreciate the work you put into this, I had a much simpler time navigating the pre v0.9 chart and it took me less time to set things up initially on v0.8 than it did upgrading to v0.9.

I can somewhat understand this, however that was why the beta process was undertaken with this chart it had substantial changes around secrets and I wanted to ensure they made more sense than before. Nearly all the feedback suggested they were, probably all of it in fact until now.

I suppose I can't really convince anyone to come around to a more beneficial approach for everyone including themselves, I can only just hope and not let it concern me if it doesn't occur. C'est la vie.

Obviously it's your chart and I see that a lot of effort has been made going to v0.9. Glad to hear feedback around the secret changes were positives in general, which must mean that people saw the added value of the new setup. From my perspective I went from setting secret.existingSecret and adding a section with options key, value and filename for each secret to a values.yaml file (which contained 32 occurrences of the word secret) to now having to jump all around that same file, which now contains 138 occurrences of the word. All for no perceivable improvement to the way I want Authelia deployed, and without getting something, which used to be so simple, to work.

I'll give a simple example. I set secret.disabled: true and secret.existingSecret: 'example', deploy the helm chart and see that an empty secret 'authelia' has been created. Why?

As I said I've got a whole bunch of apps running, all deployed using helm charts. None of them have such a convoluted setup to get keys and values referenced from a single secret.

Sorry if I'm sounding harsh, I just wanted to give my perspective as a dumb user and do appreciate being able to use your chart.

and FYI, the beta process also didn't catch that the deployment template pulls in .Values.pod.securityContext.container in the template.spec section and .Values.pod.securityContext.pod in the template.spec.containers` section. I'll raise an issue for this.

[laurayco]

This can't really be considered a secret, they're being set as environment variables; it kind of defeats the purpose of setting things like this as secrets to some degree. The environment variables can be dumped by external processes trivially and are generally more accessible.

I'm quite surprised since no one during the 4 months of the announced beta tests mentioned issues like this. I'll figure out the cause, the only thing that may help going forward is full values examples.

pod:
  kind: Deployment
  replicas: 1
domain: SNIP
image:
  pullPolicy: Always
configMap:
  log:
    level: trace
    keep_stdout: true
  session:
    redis:
      enabled: false
    cookies:
      - domain: SNIP
        subdomain: auth
        authelia_url: 'https://auth.SNIP'
        default_redirection_url: 'https://immich.SNIP'
        name: 'authelia_session'
        same_site: 'lax'
        inactivity: '5m'
        expiration: '1h'
        remember_me: '1d'
  access_control:
    default_policy: deny
    rules:
      - domain: "*.SNIP"
        policy: two_factor
      - domain: "metube.SNIP"
        policy: one_factor
  storage:
    postgres:
      enabled: true
      address: tcp://database.lan.SNIP:5432
      database: authelia
      schema: public
      username: authelia
  authentication_backend:
    ldap:
      enabled: true
      implementation: custom
      address: ldap://lldap-service.default.svc.cluster.local:3890
      timeout: 15s
      start_tls: false
      base_dn: dc=SNIP
      username_attribute: uid
      additional_users_dn: ou=people
      users_filter: "(&({username_attribute}={input})(objectClass=person))"
      addditional_groups_dn: ou=groups
      groups_filter: "(member={dn})"
      group_name_attribute: cn
      mail_attribute: mail
      display_name_attribute: displayName
      user: uid=admin,ou=people,dc=SNIP
  notifier:
    disable_startup_check: false
    filesystem:
      enabled: false
    smtp:
      enabled: true
      enabledSecret: true
      startup_check_address: "SNIP"
      address: smtp.gmail.com:587
      username: SNIP
      sender: SNIP
  identity_providers:
    oidc:
      enabled: true
      jwks: ## I am thoroughly confused on how to use secrets to set JWKS keys. I would need to read the chart much more fully than I did to figure it out.
        - use: sig
          key:
            value: SNIP
      clients:
        - client_id: immich
          description: Immich
          authorization_policy: one_factor
          public: false
          client_secret: SNIP
          redirect_uris:
            - "app.immich:/"
            - "https://immich.SNIP/auth/login"
            - "https://immich.SNIP/user-settings"
          scopes:
            - openid
            - profile
            - email
ingress:
  enabled: true
  subdomain: auth
  tls:
    enabled: true
    secret-name: 'authelia-tls'
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  traefikCRD:
    enabled: true
    disableIngressRoute: true
secret:
  storage:
    value: SNIP
  smtp:
    value: SNIP
  jwt:
    value: SNIP
  ldap:
    value: SNIP
# storageEncryptionKey also did not seem to get taken up? not sure what to make of that.
#  storageEncryptionKey:
#    value: SNIP
  oidcHMACSecret:
    value: SNIP

This did create the secret, and set the ${SECRET_NAME}_FILE variables appropriately. The main process just didn't seem to pick that up for some reason or other.

IMO, I don't think forcing secret values to be stored in secrets and mounted as files is the wrong move - this is in line with what I do at my job - I think this might be more of an issue with documentation for the chart specifically?

if any addtl information would help figure this out I'm happy to provide.

[james-d-elliott]

I think potentially this is just lacking documentation. The secret values have moved similar to this for everything: https://github.com/authelia/chartrepo/blob/master/charts/authelia/values.yaml#L1361-L1383

I'll make a better response and fix the docs in a few days to a week, as well as make some adjustments to make debugging this kind of thing easier.

[laurayco]

Ah, if I'm understanding you correctly then the .secret section should be considered removed entirely?

[james-d-elliott]

Yes correct. I will double check the docs it's possibly something I didn't explain or didn't explain properly. I'm also adding the ability to adjust the container command so that we can adjust it to just sleep so we can interactively debug this in the future.

I'll also add a validation case if it's not provided, I think.

[james-d-elliott]

Can I confirm that #269 clarifies this better?

[laurayco]

left a comment with feedback; I think what you added is good, but ambiguity around the term "configuration" might be confusing with the example being generic and general purpose.

[james-d-elliott]

Thanks a lot. If there is anything else ambiguous in general we'd like to clear it up or make it more obvious where practical.