How can I use a connection string from Azure Key Vault in App Host for Redis connection

[Pedro Almeida (PedroAlmeida21)]

I created an Aspire application from a template that includes a Redis cache. Now, I am trying to leverage Azure Key Vault to get a connection string and pass it to the resources that will consume the caching (e.g., FE application).

My goal is to avoid exposing the connection string as an environment variable in the application that consumes it.

[David Fowler (davidfowl)]

The apphost can spin up a keyvault resource a pass connection information to the application. You can use the keyvault configuration provider in your application to pull configuration data from keyvault.

[Pedro Almeida (PedroAlmeida21)]

Hello David, thank you for replying. I appreciate your time. I've attempted to do as you instructed; please let me know if this is what you had in mind; plus, I have a few questions.

I spin up an Azure Key Vault resource by:

1. Install Aspire.Hosting.Azure + Aspire.Azure.Security.KeyVault packages in AppHost project.
2. Add the following code to Program.cs in AppHost project:

...
var cache = builder.AddRedis("cache");
var keyVault = builder.AddAzureKeyVault("secrets");

builder.AddProject<Projects.DotNetDemo_Web>("webfrontend")
    .WithReference(keyVault)
    .WithReference(cache)
    .WithReference(apiService);
...

4. Updated appsettings.json in AppHost project:

  "ConnectionStrings": {
    "secrets": "YOUR_VAULT_URI"
  }

By following these steps, I could pass the Azure Key Vault reference to the FE which intends to do output cache with Redis. In the FE project (Blazor app), I added the following in the Program.cs:

builder.Configuration.AddKeyVaultSecrets("secrets");

builder.AddRedisOutputCache("cache", configureSettings: 
    settings => settings.ConnectionString = builder.Configuration.GetSection("redis-connection-string").Value);

Based on the logs, I see the code is fetching the cache from my Azure Redis cache and everything is working, I don't see the secret exposed as an environment variable. However, I noticed 2 things:

• A Redis container is created.
• Connection string of the created Redis container is exposed as an environment variable.

To prevent this extra Redis container from being created during deployment, I could potentially update the AppHost with the following: var cache = builder.AddRedis("cache").ExcludeFromManifest();. However, I am not sure if this is the best practice to do since it feel like a hack.

Let me know what are you thoughts on this.

For context, I am currently using .NET Aspire Preview 2.

[Eric Erhardt (eerhardt)]

I don't understand why you need to call var cache = builder.AddRedis("cache"); in your AppHost\Program.cs if you want to talk to an existing Azure Redis cache instance. You can just remove this line completely.

var keyVault = builder.AddAzureKeyVault("secrets");

builder.AddProject<Projects.DotNetDemo_Web>("webfrontend")
    .WithReference(keyVault)
    .WithReference(apiService);

and then in your FE project (Blazor ap) Program.cs, you keep the same code:

builder.Configuration.AddKeyVaultSecrets("secrets");

builder.AddRedisOutputCache("cache", configureSettings: 
    settings => settings.ConnectionString = builder.Configuration.GetSection("redis-connection-string").Value);

You don't need a "AppHost" resource for every component in your underlying service projects. The AddRedisOutputCache("cache", component will talk to your Azure Redis cache without the AppHost knowing about it.

[Pedro Almeida (PedroAlmeida21)]

That makes sense Eric Erhardt (@eerhardt), I believe I followed this process because in my mind I thought:

• In my local machine I would spin up a redis cache.
• In cloud environments I would point to an already existent redis cache.

I apologize for the inconvenience and thank you a lot for the feedback, it's clear for me now!

[David Fowler (davidfowl)]

If you call your secret "connectionstrings--cache" then builder.AddRedisOutputCache("cache") should just work