Randomly generated passwords for resources like Redis should be consistent to the resource name and environment

[mip1983]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a few separate visual studio solutions splitting out aspects of my app e.g. front end customer facing, back end management etc. They all target the same resource group and container apps environment, deploying together into the same eco-system sharing resources like databases, cache, service bus etc.

I have been deploying these resources through a 'uber infrastructure solution', that adds the disparate projects in under one AppHost, which is ok, but it's another project and it ends up coupling the projects in such a way that they end up needing to be updated together to matching nuget packages etc.

So looking to get away from the central uber infrastructure solution, deploying them as separate solutions using the AppHost from each solution, still targeting the same resource group and container apps environment.

With Aspire 9.2, I've by and large been able to do this, I can set the name of the container apps environment and Azure resources in my apphost with an 'InfrastructureResolver', so that despite being in separate solutions, the Azure container environment resources resolve to the same resource (there is a core resources library that the different solutions reference so that they are configured consistently).

I have hit a problem with some resource types though, like Redis Cache for example, where it generates a random password for that resource. I can deploy one solution, it works fine, but when I deploy another targeting the same resource, it changes to another random password so the thing I deployed previous can no longer talk to Redis. I suspect I'm going to hit this with other resources as well, I can see 'serviceBus-sql-pwd' being generated and 'OtlpApiKey' for example.

While I've eventually figured out how to work around the problem with Redis by manually specifying a password, I think it would make sense if the behavior whenever Aspire needs to generate a random password for a resource, that it's a deterministic in what it generates, e.g. the password is a function of the resource name, the resource group and subscription id, in order to support different Aspire solutions targeting shared resources.

Expected Behavior

Any passwords generated for resources are consistent to the resource name and environment.

Steps To Reproduce

Create two separate Aspire solutions targeting the same Azure subscription/resource group. Add redis cache to both. Use 'AddAzureContainerAppEnvironment' and 'ConfigureInfrastructure' to ensure both projects are targeting the same container apps environment.

Deploy each in turn and monitor a resources that connects with the cache in the console. After the deployment of the second solution, the first will start complaining about the redis cache connection with a password error.

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

[eerhardt]

if the behavior whenever Aspire needs to generate a random password for a resource, that it's a deterministic in what it generates, e.g. the password is a function of the resource name, the resource group and subscription id, in order to support different Aspire solutions targeting shared resources.

I don't believe this would be secure. If the generated password was deterministic given these inputs, you could determine the password just by knowing the resource name, group, and sub id - none of which are protected as secrets.

Specifying the passwords manually is the best route for this scenario, IMO.

[mip1983]

if the behavior whenever Aspire needs to generate a random password for a resource, that it's a deterministic in what it generates, e.g. the password is a function of the resource name, the resource group and subscription id, in order to support different Aspire solutions targeting shared resources.

I don't believe this would be secure. If the generated password was deterministic given these inputs, you could determine the password just by knowing the resource name, group, and sub id - none of which are protected as secrets.

Specifying the passwords manually is the best route for this scenario, IMO.

Do you know what stops it changing the password to another random one each time the cache container is deployed as it is now (assuming you are deploying the same project, not different one's like I am)? Is it in some way deterministic to the solution being deployed?

[davidfowl]

If you are using azd the password is generated and stored in your user profile I believe @vhvb1989 can correct me here.

The big problem here is that you have multiple sources of truth for parameter values. Once you’re done the initial deployment you want that remote state to be the source of truth. Instead of another repo tries to deploy that redis container (I assume with the same name), fact that the secret parameter (password in this case) is already set is not captured anywhere so azd will regenerate it.

[mip1983]

I'm deploying via Azure DevOps pipelines, which is using azd. I have it configured so when the pipeline is executed you can select which parts you want to deploy, e.g. 'Deploy Cache', 'Deploy API X', 'Deploy Web Portal X' and then conditional tasks in the yaml that will run 'azd deploy [projectHere] --no-prompt'.

With the pipeline, that will be a clean/fresh instance of a virtual machine doing the build/release, so it won't have that password persisted anywhere locally (though maybe it does something clever with a key vault?)