AWS Load Balancer Controller + Google OIDC ---> Error 500

[LucaSoato]

Describe the bug
Hi, I'm setting up a private ingress and I'd like to protect it with Google OIDC.
The ingress is protected with the Public Hosted zone certificate.
I've followed this guide. When I try to connect though, the server blocks here with an error 500.

https://<HOSTNAME>/oauth2/idpresponse?state=<BIG STRING>&code=<BIG STRING 2>&scope=email+openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&authuser=0&hd=<HOST>&prompt=consent

I'm sure the error isn't returned by the application I'm creating the ingress for, also I've checked hundred times the secret, it is correctly set up with the keys clientID and clientSecret.

Expected outcome
Proceed safely authenticated, without Error 500.

Environment

• AWS Load Balancer controller version 2.8
• Kubernetes/EKS version v1.30.6-eks-7f9249a

Additional Context:

annotations:   alb.ingress.kubernetes.io/auth-idp-oidc: >-
                           {
                             "issuer": "https://accounts.google.com",
                             "authorizationEndpoint": "https://accounts.google.com/o/oauth2/v2/auth",
                             "tokenEndpoint": "https://oauth2.googleapis.com/token",
                             "userInfoEndpoint": "https://openidconnect.googleapis.com/v1/userinfo",
                             "secretName": <SECRET NAME>
                           }
                         alb.ingress.kubernetes.io/auth-on-unauthenticated-request: authenticate
                         alb.ingress.kubernetes.io/auth-scope: email
                         alb.ingress.kubernetes.io/auth-session-cookie: AWSELBAuthSessionCookie
                         alb.ingress.kubernetes.io/auth-session-timeout: 3600
                         alb.ingress.kubernetes.io/auth-type: oidc
                         alb.ingress.kubernetes.io/certificate-arn: <CERTIFICATE ARN>
                         alb.ingress.kubernetes.io/group.name: private
                         alb.ingress.kubernetes.io/healthcheck-interval-seconds: 15
                         alb.ingress.kubernetes.io/healthcheck-port: traffic-port
                         alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
                         alb.ingress.kubernetes.io/healthcheck-timeout-seconds: 5
                         alb.ingress.kubernetes.io/healthy-threshold-count: 2
                         alb.ingress.kubernetes.io/listen-ports: [{"HTTPS":443}, {"HTTP":80}]
                         alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=300
                         alb.ingress.kubernetes.io/scheme: internal
                         alb.ingress.kubernetes.io/ssl-redirect: 443
                         alb.ingress.kubernetes.io/success-codes: 200-399
                         alb.ingress.kubernetes.io/target-type: ip
                         alb.ingress.kubernetes.io/unhealthy-threshold-count: 2
                         external-dns.alpha.kubernetes.io/hostname: &hostname  <HOSTNAME>
                         route53-hosted-zone-type: private
  hosts:
    - host: *hostname
      paths:
        - path: /
          pathType: 

Some of you might say that this error is the same of this one: #2819

But when I try to set the secret values as base64 (without considering that Kubernetes itself already encodes them as base64), I get another issue. During the authentication I get redirected here:

https://accounts.google.com/signin/oauth/error/v2?authError=&client_id=<The client id here is BASE64 Encoded while it shouldn't be>&flowName=GeneralOAuthFlow

I've checked a lot of times not to include any space or new line in the base64 encoding, I'm currently transforming them with the following command, where xc and xp are aliases to xclip. (Also verified that by double checking with an online base64 encoder decoder)
echo -n $(xp) | base64 -w 0 | xc

[shraddhabang]

Hey @LucaSoato , Thanks for bringing this to our attention. This looks like a bug and we will take a look. Meanwhile, could you please try to upgrade the controller version to v2.10.1 to see if its still and issue?

[LucaSoato]

Absolutely, I'll let you know if that fixes the issue.

[LucaSoato]

Hi @shraddhabang, I can confirm that the error persists even in the latest version.
I'm sure it upgraded because we also met the no identity-based policy allows the elasticloadbalancing:DescribeListenerAttributes action error (that we already solved by extending the policy).

[zac-nixon]

Can you drop your account id here (or DM me the ID)? I can look for more information into the reason for the 500 error in our internal systems.