Aws-load-balancer-controller: Add actions: authenticate-oidc and authenticate-cognito

[natefox]

The actions annotation supports some but not all of the actions. We'd like to be able to use the authenticate actions. However, I'm not quite sure how to handle the sensitive data properly.

I'm proposing something along these lines:

  annotations:
    alb.ingress.kubernetes.io/actions.authenticate-oidc: >-
      [{
          "Type": "authenticate-oidc",
          "AuthenticateOidcConfig": {
              "Issuer": "https://idp-issuer.com",
              "AuthorizationEndpoint": "https://authorization-endpoint.com",
              "TokenEndpoint": "https://token-endpoint.com",
              "UserInfoEndpoint": "https://user-info-endpoint.com",
              "ClientId": "abcdefghijklmnopqrstuvwxyz123456789",
              "ClientSecret": "123456789012345678901234567890",     //  <--- this is my problem
              "SessionCookieName": "my-cookie",
              "SessionTimeout": 3600,
              "Scope": "email",
              "AuthenticationRequestExtraParams": {
                  "display": "page",
                  "prompt": "login"
              },
              "OnUnauthenticatedRequest": "deny"
          },
          "Order": 1
      },
      {
          "Type": "forward",
          "Order": 2
      }]
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /auth
            backend:
              serviceName: authenticate-oidc
              servicePort: use-annotation

Note that the TargetGroupArn key is missing out of the "Type": "forward" object. I propose this be injected by the controller as the TG ARN is managed/known by the controller.

Ideally, the ClientSecret could be pulled from a volume or env var and not sitting in the annotation itself. Not quite sure how to best handle this as variable expansion doesn't apply to annotations (at least I dont think it does).

Additional example json for authenticate-cognito can be found on AWS site: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html

I'm keen to hear thoughts around this.

[bigkraig]

We could expand variables inside of the annotation. That might make the most sense.

The controller should also inject the ARN.

WRT those configurations not being supported, that was due to https://github.com/aws/aws-sdk-go/blob/master/service/elbv2/api.go#L3395-L3396. It shouldn't take much effort to support authenticate-oidc and authenticate-cognito though.

[JakubJecminek]

Hi is there any roadmap or plan for bringing this feature, so you can specify authenticate-oidc through annotations?
Thanks
Jakub

[eschu21]

Would love to see this feature, we are actively blocked by not being able to setup OIDC auth on our alb.

Thanks!!

[d-nishi]

/sig aws

[d-nishi]

/assign @M00nF1sh

[JakubJecminek]

It should also be possible to have multiple of these authentication annotations. And specify for which service should annotation be used. For example you can have multiple services and each is secured using different oidc provider. Therefore you need to somehow create mapping between authentication-oidc annotation and service.

[sebastianvoss]

This feature would be highly appreciated. We tried to set auth manually using the console but the aws-alb-ingress-controller refresh unfortunately removes these setting after a while.

[JakubJecminek]

I see that this feature is not part of 1.0.0 release. It seems to me quite important to have this feature in it because without possibility to specify authentication action for rule, the actual usage of this ingress controller is quite limited. Is there some roadmap for this feature?

[AdeOpe]

+1
this would be super useful to have

[sc14aec]

This would be very much appreciated - this resource would be really useful, but we're using Cognito for auth which means it's essentially unusable until this feature is implemented

[M00nF1sh]

Hi all, i have created an design proposal for possible implementation for this feature: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/pull/754
Would you help review it and vote for the alternatives 😄 . Implementation should be straight forward once choose

[AdeOpe]

@M00nF1sh - definitely Alternative 1.

I have smashed a 👍 on the ticket.

thank you for progressing this demand

[M00nF1sh]

resolving since it's already implemented