failed to load alpha options: unable to load config file: read /etc/oauth2_proxy/oauth2_proxy.yml: is a directory

[fabio-s-franco]

In AKS, Pod fails to start with the error mention in the tittle:

[main.go:41] ERROR: failed to load alpha options: unable to load config file: read /etc/oauth2_proxy/oauth2_proxy.yml: is a directory

It is installed via terraform, but should work the same with helm command as I use a custom values file for override:

values file:

config:
  configFile: |-
    email_domains = [ "*" ]        # Restrict to these E-Mail Domains, a wildcard "*" allows any email

extraVolumes: ${jsonencode(extra_volumes)} # CSI driver volume
extraVolumeMounts: ${jsonencode(extra_volume_mounts)} #Mounts to /mnt/secret
alphaConfig:
  enabled: true
  existingSecret: ${oauth2_secret}
  configData:
    providers:
    - id: oicd-azure
      provider: oidc
      azureConfig:
        tenant: ${tenant_id}
      oidcConfig:
        issuerURL: https://login.microsoftonline.com/${tenant_id}/v2.0
        jwksURL: https://login.microsoftonline.com/common/discovery/v2.0/keys
        userIDClaim: oid
        audienceClaims: [aud]
        emailClaim: email
        groupsClaim: groups
    upstreamConfig:
      upstreams:
        - id: static_200
          path: /
          static: true
          staticCode: 200
    injectResponseHeaders:
      - name: X-Auth-Request-Preferred-Username
        values:
          - claim: preferred_username
      - name: X-Auth-Request-Email
        values:
          - claim: email
      - name: X-Auth-Request-Id-Token
        values:
          - claim: id_token
      - name: X-Auth-Request-Groups
        values:
          - claim: groups

extraArgs:
  reverse-proxy: true
  skip-provider-button: true 
  silence-ping-logging: true
  cookie-refresh: "15m"
  cookie-expire: "24h"

redis:
  enabled: false

sessionStorage:
  type: redis
  redis:
    existingSecret: redis-settings
    standalone:
        connectionUrl:  "<redacted>"

This started to happen after I upgraded from 6.23.1 to the more recent 7.6.0
I have also ensured it is using the latest chart version (7.7.9) and verified the structure of values.yaml to match with the latest chart version.

If I omit configFile from config section, I get:

 failed to load core options: failed to load config: error unmarshalling config: 1 error(s) decoding:
* '' has invalid keys: upstreams

So, config.configFile.upstreams = [ "file:///dev/null" ] seems to be invalid. It breaks when configFile is not overriden.

I am still unable to upgrade oauth2-proxy to use latest chart and image versions. But still investigating if I can workaround the issue. I suspect this has something to do with how newer versions treat multiple provider configurations that may not be reflected in the chart, even though I am only using a single provider in alphaConfiguration.

[fabio-s-franco]

It seems the problem is that I can't have client-id, client-secret and cookie-secret being loaded separately from a secret. It's either alphaconfig from values file, from a configmap our from a secret in its entirety.

I find it a bit strange that it is not possible to use a secret directly. I will try to set it up in extraEnv as it seems to be set as a template so I can make secretkeyref and load it as environment variables. It may also be useful to have it as an example in README, and perhaps some clarification on the behavior of existingSecret. It is a bit confusing.

[pierluigilenoci]

@fabio-s-franco

The configFile inside the values.yaml file has been the same for five years, so that's certainly not the problem.
https://github.com/oauth2-proxy/manifests/blame/main/helm/oauth2-proxy/values.yaml#L49

I confirm that proxyVarsAsSecrets works like this: a single secret with all three values.
https://github.com/oauth2-proxy/manifests/blob/main/helm/oauth2-proxy/templates/deployment.yaml#L176C24-L192

You can try to use envFrom.
https://github.com/oauth2-proxy/manifests/blob/main/helm/oauth2-proxy/values.yaml#L97-L108

I hope I helped you in some way.

[fabio-s-franco]

Hi @pierluigilenoci, this somewhat got lost from my feed. as I noted earlier, it is not possible to use these values if using alphaConfig. Found that somewhere in the documentation. Thanks for trying to help, but I did not find a way around it.

If I use azure or oidc, but need settings (client-id/secret), it is only possible to define them within alphaconfig (wherever is the source of it), so separately loading these from env variables do not work, they need to be explcicitly set in alphaconfig, which is not secure, if I don't want to put the whole of alphaconfig inside a vault.

I had to stop using oauth2-proxy for the solutions that required the alphaconfig settings, so that I could load these values using CSI Driver (takes these from a key vault).

Not sure whether this should be closed or not. The issue can be closed in case there is no plan to support this scenario.

[EvanCarroll]

If I omit configFile from config section, I get:

 failed to load core options: failed to load config: error unmarshalling config: 1 error(s) decoding:
* '' has invalid keys: upstreams

this is a major error guys, also seeing this. fixing it now

https://devops.stackexchange.com/q/20275/18965

---

notes the bug is in the configmap.yaml it seems the config file template is generated when alphaauth is set, it looks like this oauth2_proxy.cfg: {{ tpl .Values.config.configFile $ | quote }}

data:
  oauth2_proxy.cfg: "email_domains = [ \"*\" ]\nupstreams = [ \"file:///dev/null\" ]"

That's what's causing us the problem. That's not a valid AlphaConfig now though it may have worked previously.

• The upstreams options are listed as status removed
• The email_domains option seems to still be valid.

---

This is a really award API decision to

• have the option --alphaconfig disable different commands from the config.
• to require the config for the commands that aren't available in alphaConfig.

I've submitted a patch it's up now as a PR.

• This add a new legacyOption default in values.yaml, and simply puts it the top of the configFile but only if alphaConfig.true.
• It adds to the alphaConfig defaults the now available upstreams

better implementation It would seem so much easier to just have alphaConfig override the config commands as you implemented the functionality. And, then to have the alphaconfig option conflict with any old config commands after the code for the transition was finished.

[EvanCarroll]

@fabio-s-franco you've also brought up a really major architectural problem imho. you should open that separately.

I'm going to go ahead do that so it's not lost, i think the core issue here is resolved with my patch.