Add Radius recipe parameters and secret management

[nellshamrell]

Description

This adds recipe parameter customization and secret management to the Aspire.Hosting.Radius integration, so an AppHost can tune how Radius recipes provision backing resources and can supply the secrets those resources need — declaratively, in the app model — instead of configuring them out-of-band against the cluster.

What you can now do:

• Pass recipe parameters to Radius recipes, either environment-wide or scoped to a specific Radius resource type, to control how backing resources are provisioned (region, SKU, etc.). Parameter values can be plain literals or late-bound ParameterResource / RadiusProviderReference values, including when nested inside objects/arrays.
• Declare secret stores in the app model — application-scoped via builder.AddRadiusSecretStore(...) or environment-scoped via radius.WithSecretStore(...) — and populate them three ways: inline WithData, a reference to an existing Kubernetes Secret (WithExistingSecret), or an encrypted Bitnami SealedSecret manifest (WithSealedSecret) that is applied and its materialization awaited at deploy time.
• Wire recipe configuration, environment secrets, and registry/Terraform authentication to declared stores.

Validation is fail-fast with a dedicated ASPIRERADIUS0xx diagnostic range covering population, publish, and deploy errors, so misconfiguration surfaces at publish time with an actionable message rather than as an opaque cluster failure.

User-facing usage

Recipe parameters (C# AppHost):

var radius = builder.AddRadiusEnvironment("radius")
    // Environment-wide parameters applied to every recipe.
    .WithRecipeParameters(p => p["region"] = "eastus")
    // Parameters scoped to a specific Radius resource type.
    .WithRecipeParameters("Radius.Data/redisCaches", p => p["sku"] = "Premium");

Secret stores (C# AppHost):

// Application-scoped store, inline data from secret parameters.
var dbUser = builder.AddParameter("db-user", secret: true);
var dbPassword = builder.AddParameter("db-password", secret: true);
builder.AddRadiusSecretStore("db-creds", RadiusSecretStoreType.BasicAuthentication)
    .WithData(d =>
    {
        d.Add("username", dbUser);
        d.Add("password", dbPassword);
    });

// Environment-scoped store backed by an existing Kubernetes Secret.
radius.WithSecretStore("tls-cert", RadiusSecretStoreType.Certificate, s =>
    s.WithExistingSecret("app/tls-cert", "tls.crt", "tls.key"));

// Environment-scoped store from an encrypted SealedSecret manifest,
// applied and awaited at deploy time.
radius.WithSecretStore("db-creds", RadiusSecretStoreType.BasicAuthentication, s =>
    s.WithSealedSecret("./secrets/db-creds.sealed.yaml", "username", "password"));

Security considerations

This change handles secret material and executes external tooling, so it is security-relevant:

• No plaintext secrets in generated artifacts. Inline secret values are emitted into Bicep as references to valueless @secure() parameters, never as literals. SealedSecret manifests are validated to be a single encrypted Bitnami SealedSecret, and the parser fails closed if a manifest embeds a plaintext kind: Secret (including inside a last-applied-configuration annotation), has malformed/ambiguous structure, or uses YAML anchors/aliases/merge keys/duplicate keys (ASPIRERADIUS044, 063).
• kubectl execution is injection-safe. All kubectl invocations use discrete ArgumentList argv entries with UseShellExecute=false; secret-returning calls suppress stdout logging so no secret material reaches logs, temp files, or error messages. The apply/sync/verify sequence is bounded by a materialization-timeout budget (ASPIRERADIUS066) and tolerates transient/NotFound poll failures rather than aborting the deploy.
• Store names are validated against a strict grammar (ASCII letters/digits/hyphens, no .., no leading/trailing ., no Windows reserved device names) before being used as Bicep symbols and filesystem path segments, preventing path traversal.
• Deploy fails closed when the active rad workspace's Kubernetes context cannot be resolved, rather than applying to kubectl's ambient context (ASPIRERADIUS059).

A security review of these changes was performed and found no high-confidence issues.

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

[github-actions]

🚀 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/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18834

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

Adds publish/deploy-only secret-provider and recipe-configuration capabilities to the Radius deployment-target integration.

Changes:

• Adds scoped recipe parameters with late-bound values.
• Adds inline, existing, and sealed secret stores.
• Adds validation, Bicep generation, deployment orchestration, documentation, and tests.

Reviewed changes

Copilot reviewed 40 out of 40 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
tests/.../SecretStoreValidationTests.cs	Tests store validation diagnostics.
tests/.../SecretStoreDefaultPathTests.cs	Tests default and Run-mode behavior.
tests/.../SecretStoreConsumerTests.cs	Tests consumer annotations.
tests/.../SealedSecretManifestTests.cs	Tests manifest security validation.
tests/.../SealedSecretArtifactTests.cs	Tests artifact paths.
tests/.../SealedSecretApplyStepTests.cs	Tests apply and synchronization logic.
tests/.../AddRadiusSecretStoreTests.cs	Tests store APIs.
tests/.../WithRecipeParametersTests.cs	Tests parameter registration.
tests/.../RecipeParameterIsolationAndFidelityTests.cs	Tests environment isolation.
tests/.../RecipeParameterAdvancedTests.cs	Tests nested and late-bound parameters.
tests/.../RecipePackParametersBicepTests.cs	Tests recipe Bicep output.
tests/.../SecretStoreConsumerBicepTests.cs	Tests consumer Bicep output.
tests/.../SealedSecretPublishTests.cs	Tests sealed-secret publishing.
tests/.../RadiusDeployParametersTests.cs	Tests deploy parameter bindings.
tests/.../InlineSecretStoreBicepTests.cs	Tests inline-store output.
tests/.../ExistingSecretStoreBicepTests.cs	Tests existing-secret output.
Secrets/SealedSecretManifest.cs	Validates encrypted manifests.
Secrets/SealedSecretArtifact.cs	Resolves artifact paths.
Secrets/RadiusSecretStoreValidation.cs	Implements fail-fast validation.
Secrets/RadiusSecretStoreType.cs	Defines store types and encodings.
Secrets/RadiusSecretStoreResource.cs	Models secret stores.
Secrets/RadiusSecretStorePopulation.cs	Models population modes.
Secrets/RadiusSecretStoreNaming.cs	Validates store names.
Secrets/RadiusSecretStoreExtensions.cs	Adds store builder APIs.
Secrets/RadiusSecretStoreConsumerExtensions.cs	Adds consumer APIs.
Secrets/RadiusSecretStoreConsumer.cs	Models consumer wiring.
Recipes/RadiusRecipeParameterExtensions.cs	Adds recipe parameter APIs.
Recipes/RadiusProviderReference.cs	Defines provider references.
README.md	Documents new features.
RadiusEnvironmentResource.cs	Adds validation/apply pipeline stages.
Publishing/RadiusInfrastructureOptions.cs	Carries generated secret and parameter state.
Publishing/RadiusBicepPublishingContext.cs	Copies sealed manifests.
Publishing/Constructs/RadiusSecretStoreConstruct.cs	Models secret-store Bicep resources.
Publishing/BicepPostProcessor.cs	Emits and validates new symbols.
CloudProviders/RadiusCloudProviderExtensions.cs	Documents export suppression.
Aspire.Hosting.Radius.csproj	Adds YamlDotNet.
Annotations/RadiusSecretStoresAnnotation.cs	Stores consumer wiring.
Annotations/RadiusRecipeParametersAnnotation.cs	Stores scoped recipe parameters.

[nellshamrell]

Good call on end-to-end coverage. A SealedSecret apply/materialize deployment test requires a live cluster (kind + the Sealed Secrets controller) and belongs in tests/Aspire.Deployment.EndToEnd.Tests rather than the unit suite, so it's out of scope for this PR. The apply/sync/verify logic is unit-tested against an injected kubectl runner (including the new permanent-vs-transient handling). I'll track the live E2E separately. Leaving this thread open as a reminder.

[nellshamrell]

Agreed a deployed recipe-parameter round-trip is valuable, but it needs a live Radius environment and belongs in the deployment E2E suite, so it's out of scope here. Recipe-parameter emission is covered by the publish/bicep unit tests. I'll track the live E2E separately and am leaving this thread open.

[Copilot]

Pull request overview

Copilot reviewed 40 out of 40 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 40 out of 40 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/Aspire.Hosting.Radius/Secrets/RadiusSecretStoreNaming.cs:69

• Uppercase letters pass this check, but an inline store with no resource reference is materialized by Radius as a Kubernetes Secret whose metadata.name is the store name. Kubernetes object names reject uppercase, so names such as DbCreds pass AppHost validation and then fail only during deployment. Enforce the target-compatible lowercase DNS grammar, or separate the Aspire resource name from the physical secret-store/Secret name.

            else if (char.IsAsciiLetterOrDigit(c))

[nellshamrell]

Good catch — this is a real limitation. Today an environment-scoped store uses name as both the Aspire model identity and the physical Radius store name, so two environments cannot each declare e.g. db-creds (the second AddResource is rejected).

I'm leaving this one open as a follow-up rather than fixing it in this PR: the clean fix is additive API surface — an optional physical store name threaded through AddRadiusSecretStore/WithSecretStore, a StoreName on the resource, and all emission sites (bicep name:, the UCP reference, and the sealed Secret name). That's a larger, riskier change than the other re-review fixes, and it only bites when two Radius environments each declare a same-named env-local store. Happy to implement it in a dedicated PR if you'd prefer — let me know.

[Copilot]

Pull request overview

Copilot reviewed 40 out of 40 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 42 out of 42 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (2)

src/Aspire.Hosting.Radius/Secrets/RadiusSecretStoreExtensions.cs:204

• Resolve the manifest path before changing the population mode. Path.GetFullPath can throw for malformed paths; after that exception the resource remains marked as sealed and a corrected retry is rejected by ASPIRERADIUS065.

        population.HasSealedSecret = true;
        // Resolve a relative manifest path against the AppHost directory (not the process working
        // directory), matching other hosting file APIs (e.g. KeycloakResourceBuilderExtensions), so
        // the documented `./secrets/...` usage works regardless of where the AppHost is launched.
        population.SealedManifestPath = Path.GetFullPath(manifestPath, store.ApplicationBuilder.AppHostDirectory);
        population.Keys.AddRange(validatedKeys);

src/Aspire.Hosting.Radius/Secrets/RadiusSecretStoreNaming.cs:57

• These rules allow uppercase letters and a 64-character name, but this value is also used as the name of a Radius-created Kubernetes Secret. Kubernetes object names must be lowercase DNS-1123 names, with each label limited to 63 characters, so accepted inputs such as DB-Creds or 64 as will fail only at deployment. Validate the physical store name against the Kubernetes naming contract (or map it to a separate valid physical name).

        if (!char.IsAsciiLetter(name[0]) || name[^1] == '-')
        {
            return false;
        }

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Pull request overview

Copilot reviewed 42 out of 42 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

src/Aspire.Hosting.Radius/Secrets/RadiusSecretStoreNaming.cs:28

• Radius secret-store resource names are capped at 63 characters upstream, but this validator accepts 64. A 64-character name therefore passes AppHost validation and only fails when Radius processes the generated Applications.Core/secretStores resource, defeating the fail-fast guarantee. Align this limit, its diagnostic text, and the 64-character acceptance test with Radius's 63-character ResourceNameString contract.

    internal const int MaxNameLength = 64;

[Copilot]

Pull request overview

Copilot reviewed 42 out of 42 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

src/Aspire.Hosting.Radius/Secrets/KubernetesName.cs:61

• This accepts . and .., and it has no 253-character limit. Kubernetes rejects those values as Secret data keys, so WithData/WithExistingSecret/WithSealedSecret can pass AppHost validation and then fail at deployment. Enforce the path-segment exclusions and maximum length here, update both error messages, and add boundary tests.

        if (value.Length == 0)
        {
            return false;
        }

[Copilot]

Pull request overview

Copilot reviewed 43 out of 43 changed files in this pull request and generated 1 comment.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Pull request overview

Copilot reviewed 43 out of 43 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 43 out of 43 changed files in this pull request and generated 3 comments.