Support `Proxy-Authorization` header in `kargo` CLI

[steve-marmalade]

Checklist

• [x] I've searched the issue queue to verify this is not a duplicate feature request.
• [x] I've pasted the output of kargo version, if applicable.
• [x] I've pasted logs, if applicable.

Proposed Feature

Provide a mechanism to supply the kargo CLI with a Proxy-Authorization header.

Motivation

I have deployed the kargo API behind GCP IAP so that it's only accessible to admins. Visiting the web-app is straightforward, since GCP intercepts the request and then forwards me to the UI once I log-in.

I would like to do the same via the CLI, and IAP supports the Proxy-Authorization header so as not to interfere with an application's use of the Authorization header.

Suggested Implementation

Adding a flag to kargo login either allowing arbitrary headers or a --proxy-authorization token would be amazing.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[steve-marmalade]

Maybe not the highest priority issue, but I'd be in favor of keeping this open as I believe it would be valuable

[krancour]

Removing the stale label, but it's true no one's so much as looked at this yet. It's the kind of thing that's more likely going to get done through community effort.

[krancour]

I put all the right labels on it to hopefully attract a volunteer.

And I removed the proposal label because I think this isn't controversial and is something we'd happily accept.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[onasser1]

Hi @krancour can I work on this as a community contribution? I've a quick thought about this and let me know if I'm not on the right track. I will create a new flag for Proxy-Authorization header with a string value, taking this string value to be set to http header in client/auth.go and adding a new field in addition to credentials in authInterceptor to be something: proxyCredentials

Would GCP IAP could be able to get that token? I'm asking because I don't have access to GCP currently so I'd not be able to reproduce and test. What do you think about that? I could go and create a PR and move this discussion there if this suits you

[krancour]

@onasser1 I can't get too bogged down in the details of this issue right now, so here's the limited guidance I can offer right now:

1. The original report in this issue, as tends to be the case, is hyper-fixated on a very specific use case. You can and should just dismiss GCP from the equation entirely. The Proxy-Authorization header is formally defined in rfc7235. Whatever is done just needs to be compliant with the spec. Don't worry about GCP.

2. The new flag should only be for the login command. Whatever value is supplied, you're going to have to remember it in the Kargo CLI's config file along with the regular credentials.

3. Because the value supplied to the new flag is a credential, many users may not wish to directly type these in the command since it will be remembered in their shell's history. This is a common concern for passwords and other credentials. My suggestion is that you make a value for the flag optional. If the flag is used without a value being specified, you can collect the credential interactively using the github.com/AlecAivazis/survey/v2, which is how we currently collect the admin password if one is logging in with the --admin flag, but has not provided the --password flag with it.

[onasser1]

Good @krancour , Thanks! I wonder, How would GCP IAP for example use that proxy-authorization from kargo? If you can take a look here and help me if we should do something else. As I feel we need to do something to let that proxy-authorization usable. (Forgive me if not being clear but still trying to understand)