Add support for Keycloak deployment to ACA

[anderly]

Description

Per #6004, deploying a container provisioned via the Keycloak integration won't start in Azure Container Apps (ACA).

ACA will try to activate it, but it continuously fails.

The container reports this in the logs:

Key material not provided to setup HTTPS. Please configure your keys/certificates or start the server in development mode.

This PR includes a basic starting point for changes required to get Keycloak working in Azure Container Apps.

See my comment on #6004 showing what is necessary to get Keycloak working on ACA.

Currently, this only outputs the additional env vars if the passed port is 8443. Otherwise, it behaves as before for local dev scenarios. Open to making additional changes based on review and suggestions, but wanted to show bare minimum to get it working and be able to support ACA and SSL.

To opt-in to this configuration for deployment to ACA, users would simply specify port 8443 in the call to AddKeycloak like so:

var keycloak = builder.AddKeycloak("keycloak", 8443);

OR

var port = builder.Environment.IsDevelopment() ? 8080 : 8443;
var keycloak = builder.AddKeycloak("keycloak", port);

Another option would be an explicit Publish extension method similar to PublishAsAzurePostgresFlexibleServer on IResourceBuilder<KeycloakResource> builder for more fine-grained control over these settings.

The changes in this PR output 3 additional env vars:

    KC_HTTP_ENABLED=true
    KC_PROXY-HEADERS=xforwarded
    KC_HOSTNAME-STRICT=false

Since ACA includes TLS termination at the Envoy proxy, we're setting KC_HTTP_ENABLED=true per https://www.keycloak.org/server/hostname#_using_edge_tls_termination and KC_PROXY-HEADERS=xforwarded per https://www.keycloak.org/server/reverseproxy#_configure_the_reverse_proxy_headers.

Technically, KC_HOSTNAME-STRICT doesn't have to be false and shouldn't be for prod configurations, but if it's not, KC_HOSTNAME env var also has to be provided (see here) and needs to match the ACA container url or a configured custom domain. We could make the inclusion of KC_HOSTNAME conditional with an additional param on the AddKeycloak extension method to, optionally, provide a custom domain which would be used to set the KC_HOSTNAME variable. Or, we'd need to always set KC_HOSTNAME to match the generated container url (https://container-app-name.randomwords-digits.centralus.azurecontainerapps.io) or use a custom domain as KC_HOSTNAME if specified.

Fixes #6004

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • [] Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

[anderly]

@dotnet-policy-service agree

[DamianEdwards]

I'm not following why this is the predicate for setting all the config to setup Keycloak for running behind a reverse proxy. My reading of this is that when the user specifies the port to be 8443, we configure the Keycloak container as if it's running behind a reverse proxy, but also enable non-HTTPS? How is it expected this will be used, i.e. what will the app host code look like?

[anderly]

Ok. I've simplified this quite a bit with recent commit for bare minimum for running behind reverse proxy and leveraging existing ACA TLS edge termination.

So, no changes to app host code or usage. This just outputs 3 additional env vars:

    KC_HTTP_ENABLED=true
    KC_PROXY-HEADERS=xforwarded
    KC_HOSTNAME-STRICT=false

Since ACA includes TLS termination at the Envoy proxy, we're setting:

• KC_HTTP_ENABLED=true per https://www.keycloak.org/server/hostname#_using_edge_tls_termination
• KC_PROXY-HEADERS=xforwarded per https://www.keycloak.org/server/reverseproxy#_configure_the_reverse_proxy_headers.
• KC_HOSTNAME-STRICT=false per https://www.keycloak.org/server/hostname#_fully_dynamic_urls

Technically, KC_HOSTNAME-STRICT doesn't have to be false and shouldn't be for prod configurations, but if it's not, KC_HOSTNAME env var also has to be provided (see here) and needs to match the ACA container url or a configured custom domain. We could make the inclusion of KC_HOSTNAME conditional with an additional param on the AddKeycloak extension method to, optionally, provide a custom domain which would be used to set the KC_HOSTNAME variable. Or, we'd need to always set KC_HOSTNAME to match the generated container url (https://container-app-name.randomwords-digits.centralus.azurecontainerapps.io) or use a custom domain as KC_HOSTNAME if specified.

[DamianEdwards]

I think configuring Keycloak for operation behind a reverse proxy needs to be behind a method call, rather than having these items always set. Setting KC_HOSTNAME to the URL associated with the endpoint as part of deployment should be doable via an EndpointReference. Deployment takes care of ensuring the required value is populated.

[anderly]

That makes sense as I did mention in my initial PR description that I thought a dedicated Publish method similar to PublishAsAzurePostgresFlexibleServer might be preferred.

So, maybe we wrap this additional config in PublishAsAzureContainerApp or WithReverseProxy extension method which could set the KC_HTTP_ENABLED and KC_PROXY-HEADERS env vars and the KC_HOSTNAME could be derived from the EndpointReference and or a custom domain, if provided, via param on the new method.

Let me know if that jives with the direction you're thinking.

[DamianEdwards]

Something like WithReverseProxy I think is the basic building block. Folks can then put that behind an if check for publish mode. We can consider introducing something like PublishWithReverseProxy if we want to make that a wider pattern (it isn't today, but I for one think we should consider it).