Aws-load-balancer-controller: configure ALB ingress controller to authenticate against CognitoUserPool with Authorization header in the request as key

[chsaiimannoj]

Hi, I'm trying to configure alb.ingress.kubernetes.io/auth-type: cognito annotation in an ingress resource, Is it possible to configure alb (through the above annotation) to look for the Authorization header in the request and validate against the Cognito user pool.

[rustysys-dev]

@chsaiimannoj I just finished doing this.

I had an issue that you might want to look at. #871

I am also preparing templates for contribution to the project, but that might take a day or so to publish.
The templates are built off of the research from the issue linked above.

[chsaiimannoj]

@procyclinsur thank you for the pointer, just to confirm, are you passing the jwt token in the request within 'Authorization' header? and is it getting validated against CognitoUserPool? because in your configuration I don't see any attribute saying ALB to use "Authorization" header. Sry if I'm asking you a wrong question.

[rustysys-dev]

@chsaiimannoj unfortunately I am less versed in this aspect of the system than I would like to be, so I cannot say for sure.

That being said, and @M00nF1sh correct me if I am wrong, but it seems the way I have things setup creates a cookie managed session between the the webapp and the ALB.

The JWT token does end up being transferred to the backend and can be seen in the headers accepted at my backend test client as below.

10.20.204.109 - - [22/Feb/2019 10:36:24] "GET / HTTP/1.1" 200 - 
ERROR:root:X-Forwarded-For: 27.110.27.236 
X-Forwarded-Proto: https 
X-Forwarded-Port: 443 
Host: ≤URL≥ 
X-Amzn-Trace-Id: Root=1-5c6fd0a9-188d0fc5b0e305d5d6e8ef4a 
X-Amzn-Oidc-Data: <encoded data>
X-Amzn-Oidc-Identity: <encoded identity information>
X-Amzn-Oidc-Accesstoken: <encoded access token>
user-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0 
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
accept-language: en-US,en;q=0.5 
accept-encoding: gzip, deflate, br 
upgrade-insecure-requests: 1 
if-modified-since: Fri, 22 Feb 2019 10:20:50 GMT 
cache-control: 
max-age=0 
cookie:

[M00nF1sh]

@chsaiimannoj
Currently the ALB saves an auth session information into cookie named "AWSELBAuthSessionCookie", and pass auth-information to backend via X-Amzn headers. The AWSELBAuthSessionCookie name can be adjusted by alb.ingress.kubernetes.io/auth-session-cookie annotation.

Do you want to achieve to only authenticate via OIDC/Cognito when specific header like Authorization=cognito exists in client request? If so, it's not supported by now since ALB only support path/hostname based routing rule. However, header based routing rule will be released very soon.

[chsaiimannoj]

@M00nF1sh, I'm sry if I'm only able to convey Authorization=cognito but what I mean is that my client app gets bearer token from Cognito(not via ALB), adds it in the Authorization header and sends the request to ALB, then the ALB should look into the Authorization header and Authorize against the Cognito Authorizer configured for ALB.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nicholasgcoles]

@chsaiimannoj did you get anywhere with this?

[nicholasgcoles]

/remove-lifecycle stale

[GaryAult]

Was this resolved? If not, I think this needs to be kept open. ALB should accept a bearer token provided by the IDP as authentication. We are using a different IDP (not Cognito) and have the same problem. There is a good chance we will abandon the use of the ALB for several projects that need to support REST API's from moble because of this issue.

Actually it's an ALB problem, more so than ingress controller. Still it's a problem.

[M00nF1sh]

@GaryAult
Hi, do you mean your client should get bearer token from somewhere else outside of ALB, and require ALB to get userInfo from that token to IDP?

1. why you cannot use ALB to authenticate your client, is it due to your client cannot understand ALB's redirection, like an app?
2. why you want ALB to get userInfo from IDP instead of doing that from your backend app?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[marcust]

@M00nF1sh @GaryAult
Sorry to comment on a closed issue, but I am wondering (again) if it is actually possible, coming back to the original title of the issue here:

Given that I get an (access, or maybe even Id) token somewhere else (e.g. in my native mobile app native login, talking directly to Cognito) can I still offload the authorization to an ALB (which is in front of my API Server), either by _faking_ the AWSELBAuthSessionCookie or by sending a Authorization header?

I thought I had that working a year ago, but do not find any documentation on that now.

[alexbarnes]

@marcust - would love to know whether you'd managed to fake the AWSELBAuthSessionCookie? I've been trying but with no success so far.

[marcust]

@alexbarnes Sorry for the false hope, it is actually part of my question, because I don't know what is in there.

[alexbarnes]

Thanks for the reply @marcust. I've been hacking at this for hours but not found a way to make it work. You can actually work around the AWS validation between the ALB and Cognito to associate an App Client using the client credentials flow for Authorization. But I can't find a way to make the ALB process a token provided in the Authorization header!

I've contacted our AWS account manager to see if he can bring this up with the ALB team. At the very least I'd like to know whether this is on their roadmap.

[marcust]

@alexbarnes Good to know, please keep us posted about what you find out.

[binarymist]

Any progress on this?

[k8s-ci-robot]

@binarymist: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[alexbarnes]

@marcust - Just been reminded of this thread. I was told by AWS that the ALB team have no plans to support this feature and that I should use API Gateway instead. I'm now deploying mod_oauth2 on EC2.

[mightymarty]

I was really looking forward to using ALB with cognito in a project to support a user already authenticated using cognito on a mobile app. It would seem natural that a mobile app already authenticated with cognito could hit an api endpoint and pass a token to allow access. Is it true this is not possible with ALB?