Add support for configuring TLS termination for supported resources

[danegsta]

Description

Adds new experimental API for configuring HTTPS certificate key pairs for resources. This allows configuring a resource to use a particular certificate/private key pair to terminate TLS/HTTPS connections. This can be used to configure resources that otherwise wouldn't support it to secure traffic with ASP.NET Core developer certificate, such as apps running in containers. Certificate assets are provided in both PEM and PFX format with optional encryption of the certificate key; resources can choose to consume the the specific certificate assets required for their configuration (some resources only support encryption with PFX, for example, while others only support PEM format certificates).

This PR includes implementations for:

• YARP
• Uvicorn
• Keycloak
• Redis Containers

Additionally, the existing AspireWithNode playground project has been updated to use these new APIs.

Add a custom TLS keypair with password protection on the certificate:

var passwordParam = builder.AddParameter("tlscertificate-password", secret: true)

builder.AddYarp("gateway")
    .WithCertificateKeyPair(certificate, password: passwordParam);

Disable TLS for a resource:

builder.AddYarp("gateway")
    .WithoutCertificateKeyPair();

Use the developer certificate with a password:

var passwordParam = builder.AddParameter("tlscertificate-password", secret: true)

builder.AddYarp("gateway")
    .WithDeveloperCertificateKeyPair(password: passwordParam);

Fixes #6890 Fixes #9381

Checklist

• Is this feature complete?
  • [x] 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?
  • [x] Yes
    • If yes, did you have an API Review for it?
      • [ ] Yes
      • [x] No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • [x] 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?
  • [x] Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • [ ] No

[github-actions[bot]]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12506

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12506"

[davidfowl]

Can we expose this too https://github.com/dotnet/aspire/issues/11534

[danegsta]

Can we expose this too #11534

I implemented a YARP config and have it working with the dev cert; for now I've only implemented PEM format certificate export, but it should be extendable to support PFX as well.

[danegsta]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[davidfowl]

@danegsta This can't be just dev mode, what's happens when you publish/deploy?

[danegsta]

@danegsta This can't be just dev mode, what's happens when you publish/deploy?

We'd need to figure out a pattern for injecting certificates at deploy time in specific environments (key vault certs for Azure, for example). We don't want to bake private keys into containers at publish as that's bad from a security standpoint, but if we can make certificates available at deploy time we can use this same config then.

I can remove the run mode checks since the args and environment context only gets applied when we chose to evaluate it (so it can be available at publish time when we're ready to take advantage of it).

[danegsta]

We definitely need to start with run mode only for the initial implementation though; I don't want to leak TLS specific config into deploy/publish until it can be supported there.

[YohanSciubukgian]

It could be great to leverage OpenBao, the open-source alternative to HashiCorp Vault (and alternative to Azure KeyVault). It would be ideal for local, offline, and air-gapped environments, while still maintaining Azure KeyVault support for azure cloud-based deployments.

[danegsta]

@afscrome adding TLS to the API method names to avoid confusion makes sense; I do see this API as being specific to server TLS termination, with the potential for future API to cover additional certificate usage scenarios such as client authentication.

[DamianEdwards]

@afscrome adding TLS to the API method names to avoid confusion makes sense; I do see this API as being specific to server TLS termination, with the potential for future API to cover additional certificate usage scenarios such as client authentication.

@danegsta I feel slightly uneasy about putting "TLS" in the name. While it's arguably clear what it means now, it's technically not what the cert is attached to as the underlying security mechanism can change over time (e.g. SSL -> TLS). A more technically correct name would be something like WithServerAuthenticationCertificateKeyPair, but I acknowledge that name is.... long.

[danegsta]

@afscrome adding TLS to the API method names to avoid confusion makes sense; I do see this API as being specific to server TLS termination, with the potential for future API to cover additional certificate usage scenarios such as client authentication.

@danegsta I feel slightly uneasy about putting "TLS" in the name. While it's arguably clear what it means now, it's technically not what the cert is attached to as the underlying security mechanism can change over time (e.g. SSL -> TLS). A more technically correct name would be something like WithServerAuthenticationCertificateKeyPair, but I acknowledge that name is.... long.

The methods are intentionally marked experimental since we'll likely end up making tweaks before we stabilize them. It's probably reasonable to give ourselves some time to think about the naming and adjust in a subsequent release.

[danegsta]

I'm adding work items for the remaining feedback and will tackle them in follow up PRs.

[danegsta]

Added https://github.com/dotnet/aspire/issues/13037 and https://github.com/dotnet/aspire/issues/13040 to track follow-up work.