Add AlwaysUseProxyPublicAddr to app spec protos

[avatus]

This adds a new field to the app, AlwaysUseProxyPublicAddr, that will be used to tell the web api/ui to rebuild the requested app's FQDN based on the proxy public addr that the request came from (upcoming PR to consume this)

Will backport the full feature (this plus next PR) all together

[avatus]

this isn't necessarily required but I decided to do it this way since the public_addr is an optional field. If a customer explicitly sets the public addr, i don't think overriding it with this field makes a bunch of sense. I also wanted this field to be implied based on the non-existence of the public_addr instead of set but, its better to be explicit with both

[github-actions]

Amplify deployment status

Branch	Commit	Job ID	Status	Preview	Updated (UTC)
avatus/use_proxy_addr	d317cc6	6	✅SUCCEED	avatus-use-proxy-addr	2025-03-05 19:23:16

[marcoandredinis]

Should this be done in CheckAndSetDefaults instead?

I don't think this check should only be applied to Apps coming from a configuration file.
We also have:

• terraform resources
• kube operator resources (we don't have an App resource yet, but this check can be overlooked if we keep it as a fileconfig only check)
• Apps created in Kubernetes App discovery https://goteleport.com/docs/enroll-resources/auto-discovery/kubernetes-applications/get-started/
• and with other clients using the API

[avatus]

good point. however, for file config, the public addr is derived before CheckAndSetDefaults
so the publicAddr would already be set implicitly before the check making clusters unable to start.

i would be ok with removing the check all together and just having some really good documentation on this field saying it will overwrite any set public addr (since they are both optional fields). what are your thoughts?

[marcoandredinis]

Can we expand on this? When should this be used vs using a custom public addr?

[avatus]

yeah i can update it for sure.

essentially, the apps public addr, if not set explicitly, is appName.proxyPublicAddr[0]. however, we allow multiple publicAddr for proxies and we would like to be able to access apps from any configured proxy public addr.

for the web UI (which the follow up PR targets), we can use the apps publicAddr/fqdn to authenticate the app. This doesn't work if the user is authenticated to the proxy of a different publicAddr.

so instead, what we want to do is something like make the apps fqdn be "appName.WhateverProxyPublicAddrTheRequestCameFrom". this AlwaysUseProxyPublicAddr field is a way for us to differentiate between using the public addr that was implicitly set (proxyPublicAddr[0]) and one that can be crafted per request (proxyPublicAddr[x])

My original plan was to just not set the proxyPublicAddr implicitly and do someting like "if not set, just use the proxy public addr from request", but that wouldn't work because there are a lot of other places the code base expects this field to exist. so instead, i added AlwaysUseProxyPublicAddr as an optional field to "override" this implicit publicAddr.

Now, I just have to distill all of that into a godoc comment lol

[avatus]

i actually think itd be better to remove this check and just add docs to this field and to publicAddr saying if "if always_use_proxy_public_addr" is set, it will use that to build the apps FQDN for the web UI.

it makes it explicit what is happening in the background, and wont break/change any existing configs unless they want to use this new field (which they would have to read the docs for anyway)

[marcoandredinis]

The name is not very explicit about its implications, but the comment is super clear, and I don't have a better suggestion 😅

Thank you