Support resource outputs as managed Bitwarden secret values

[sliekens]

Related to an existing integration?

Yes: CommunityToolkit.Aspire.Hosting.Bitwarden.SecretManager.

Overview

Let an Aspire resource output supply a managed Bitwarden secret. For example, a provisioned service can produce a connection string during deployment.

Keep AddSecret(name) for user-provided values, including existing parameter configuration, defaults, prompts, and missing-input prefill from Bitwarden. Keep GetSecret(name/id) read-only.

Add an expression overload for managed reference secrets. Aspire owns the destination key, while another resource supplies its value. An explicit Parameters:{parent}-{secret} value overrides the expression. Otherwise, each reconciliation evaluates the expression again. Failed or missing output must not fall back to a stored destination value. Generated output must not become a saved input override.

Usage example

var apiKey = bitwarden.AddSecret("api-key");
var databaseConnection = bitwarden.AddSecret(
    "database-connection", database.Resource.ConnectionStringExpression);

The existing Bitwarden resource supplies bitwarden. The producing database resource supplies database. Deployment steps must order the producer before Bitwarden reconciliation.

Breaking change?

The proposal preserves BitwardenSecretResource : ParameterResource and existing convenience calls. Input precedence and repeated parameter-processing behavior need review.

Alternatives

• Require callers to resolve outputs and run the Bitwarden CLI themselves.
• Replace parameter inheritance with separate input and destination resources. This changes the existing resource model and parameter APIs.
• Add source-specific paths to the writer. This duplicates behavior that belongs in value preparation.

Additional context

Providers prepare the inherited parameter state. Base getters, interface getters, and the common Bitwarden writer read that same state.

microsoft/aspire#18108 is a prerequisite for a clean implementation. Its proposed optional parameters and public value/error setters replace the private-state access needed on Aspire 13.5. Lifecycle ordering and fresh-value tests remain necessary after those APIs become available.

A draft implementation uses Aspire internals to exercise the contract now. It is for design review, with prerequisite work pending.

Help us help you

Yes, I would like to contribute the implementation.