Aspire apps and HTTPS

[DamianEdwards]

Today, new Aspire projects are configured to run locally with HTTP communication only (i.e. there is no HTTPS configuration or launch profiles). This was done back in preview.1 as we identified some experience issues with HTTPS that we need to revisit and address before GA:

• The default launch profile used is different when launching via dotnet run vs. Visual Studio. In VS, if a profile named "https" is defined, it will be selected by default. In dotnet run, the first launch profile defined is used by default. ASP.NET Core templates define two launch profiles by default: "http" and "https", in that order, so VS users get HTTPS by default but CLI users get HTTP by default as the experience for setting up and trusting the dev certificate is more complicated for CLI users.
• Projects that depend on other projects via HTTP traffic (e.g. frontend Blazor project calling backend API project like the Aspire starter template) have the scheme hard-coded in the URI. Service Discovery: allow configuration to replace URI scheme for HTTP calls #381 is currently tracking updating Service Discovery to support dynamic schemes (e.g. auto://localhost) so that the code doesn't have to hard-code the scheme name, allowing the project to run successfully whether it was launched with configuration for HTTP or HTTPS. Of course the code can be changed by the user to hard-code HTTPS as the scheme (which would likely be a documented recommendation). This will enable the template to work in all scenarios.
• The AppHost project takes into consideration the name of the launch profile used to launch it in that it attempts to use the launch profile with the same name in any projects configured as resources when launching them.
• The AppHost and dashboard both host endpoints that should work with HTTPS. The AppHost hosts a gRPC resource server endpoint during the inner-loop, and the dashboard hosts a gRPC OTLP endpoint and the actual dashboard UI endpoint. All of these endpoints should work with HTTPS in the default case. There is already some logic for handling this in places so that if the AppHost project is launched with a launch profile named "https" that contains an "applicationUrls" property setup with an HTTPS address, it will end up being flowed to the dashboard for the UI endpoint. The gRPC resource server endpoint however currently doesn't consider HTTP vs. HTTPS in its default which will likely have to be changed, e.g. to set the scheme to HTTPS if the URL supplied for the dashboard UI (via ASPNETCORE_URLS) is HTTPS.
• Assuming the above points are addressed, the AppHost project templates could be updated to include an "https" launch profile by default with an option to opt-out of HTTPS (similar to ASP.NET Core project templates) and the end-to-end experience should be similar to that of ASP.NET Core projects today. We should consider whether to add the HTTPS redirection middleware to the app projects in the template too ([WebToolsE2E][Aspire] Create an Aspire Starter project, the Program.cs of the xxx.Web project is missing the line 'app.UseHttpsRedirection()'. #526)
• Aspire.Hosting should configure ASP.NET Core resources when published to enable forwarded headers by default (Enable forwarded headers when publishing projects by default #290). This is required to ensure the incoming URL scheme and host name are preserved through the ingress proxy.
• Regarding our default deployment target of ACA via AZD, we want the apps to be configured to use HTTPS when communicating between each other (i.e. service discovery configuration uses the HTTPS addresses if present), exposing HTTPS externally for apps marked as external, and we need to revisit what happens for gRPC apps which today are set to use HTTP/2 and allow insecure in the ACA ingress settings as TLPN negotiation doesn't work. Perhaps a question of whether HTTPS addresses should be used if the app itself wasn't configured for HTTPS in the manifest.

[kvenkatrajan]

@DamianEdwards, just to confirm

The AppHost hosts a gRPC resource server endpoint during the inner-loop, and the dashboard hosts a gRPC OTLP endpoint and the actual dashboard UI endpoint. All of these endpoints should work with HTTPS in the default case.

This is referring to the localhost/dev inner loop correct? Currently if configured with an https endpoint to a remote resource server this works as expected.

[davidfowl]

I think this got put into dashboard by the bot, it's templates, and service discovery and app model.

[kvenkatrajan]

Ah thanks :) . I think there were refrerences to DashboardServiceHost code in the request. So confirming. Adding the other areas as well in the path.

[davidfowl]

@kvenkatrajan you're right, there's dashboard work in here as well.

[davidfowl]

@DamianEdwards there's nothing in here about deployment.

[DamianEdwards]

@davidfowl what kind of things are you expecting to see about deployment here? The only thing I can think of is ensuring that service discovery configuration between projects/services is properly configured with https addresses if the manifest contained https. And of course ensuring gRPC works.

[davidfowl]

That ACA works with https and gRPC and the implications with allow insecure (we turn that on today by default)

[DamianEdwards]

OK added a bullet for it, thanks.

[joperezr]

I'm assuming we want this done for P5. Do we have tracking issues for the work that needs to happen in each of the areas? (templates, app model, dashboard, SD) If so we can also update the top post to also include a list with all of these to be able to track the progress.

[DamianEdwards]

Not yet, other than those already linked to (like the SD work). This issue is about figuring out what other work is needed and then tracking it.

[DamianEdwards]

Regarding deployment to ACA, I verified that AspireShop updated for HTTPS fully works when deployed to ACA by AZD after the following adjustments:

• All ASP.NET Core project launchSettings.json files are updated to include an appropriately configured https launch profile
• The base address of all services' HttpClient instances in the frontend Program.cs are updated to use the https:// scheme
• The gRPC service app is toggled back to not allow insecure clients (i.e. perform HTTP->HTTPS redirection) in ACA ingress
• All ASP.NET Core apps are configured to enable the forwarded headers middleware via the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable on publish using a lifecycle hook

Code is at: https://github.com/dotnet/aspire-samples/tree/damianedwards/healthchecksui/samples/AspireShop
Deployed at: https://frontend.delightfulsea-671ce956.westus.azurecontainerapps.io/

[iphdav]

@DamianEdwards and @davidfowl I just wanted to link this issue to a separate issue I just created documenting how we can use a single port (with HTTPS) for both the OTLP receiver and Dashboard app UI. Yes we should always use HTTPS for both OTLP and the dashboard UI. When deploying to a service such as the Azure App Service, it is so much easier to have that single port (configured by default to use HTTPS). Here is the issue describing how to set this up:
#2756

I am successfully using the Aspire Dashboard as a nice OTLP receiver/viewer in one of our cloud dev environments. Note that I also added Entra ID login plus added verification of a HTTP Header key for the inbound telemetry.

[DamianEdwards]

Closing this as the major change to enable the HTTPS experience are complete now. We can log individual issues for any follow up items.