RunAsExisting is deploying role assignments

[DanielToft]

Hi

I'm not sure I understand the purpose of RunAsExisting.

Why is it deploying role assignments to the resource for the user running the aspire project? If the user running the aspire project does not have access to the resources, the bicep script will also not have access to deploy the role assignments.

Is it possible to override this? I would like to have this feature, but I do not want all employees to have direct access to the resources. This will be impossible to control. We already have a model to give employees access to the right resources.

Today I'm using AddConnectionString, but I think it would be nice to have the resources shown in the dashboard as I would with RunAsExisting.

[captainsafia]

@DanielToft Thanks for starting up this discussion!

Our implementation of the AsExisting feature doesn't currently do anything to evaluate if the user has access to the target resource. The failure mode we currently rely on when they don't is the failure mode at the Bicep provisioning step.

We haven't quite sorted out the best stance on this. Should we avoid assigning role assignments altogether for existing resources? What if the the correct role assignments aren't provisioned? In this case, they would surface even later to the user when they attempted to interact with the resource.

For the moment, assuming you know your users have the correct assignments configured, you'll have to pair the AsExisting APIs with a ConfigureInfrastructure call that removes the role assignments configured by default. Something like:

builder.AddAzureStorage("storage")
  .RunAsExisting("myexistingresourcename")
  .ConfigureInfrastructure(infrastructure => {
    var roleAssignments = infrastructure.GetProvisionableResources().OfType<RoleAssignment>().Where(filter);
    foreach (var roleAssignment in roleAssignments)
    {
      infrastructure.Remove(roleAssignment);
    }
  });

[DanielToft]

Hi @captainsafia

Thanks. This works perfectly!

I think role assignments should be handled differently when you are in run mode versus publish mode.

When publishing, I think it's a good practice to automatically handle permissions in a CI pipeline, but when you're in run mode, it's better to manage permissions manually.

When you run the aspire project and you don't have access to the resources, the bicep script won't work either, as you don't have access to give yourself access.

[davidfowl]

When publishing, I think it's a good practice to automatically handle permissions in a CI pipeline, but when you're in run mode, it's better to manage permissions manually.

Can you explain why? If the user doesn't have access to the resource, the project won't work. If they have permission to create role assignments then it will work. Isn't the right fix to block the user from being able to create the role assignments in the first place?

What would be the point if using RunAsExisting at all? To have the deployment grab the right connection information and then potentially fail to connect?

[DanielToft]

Hi @davidfowl,

Yes, I just want Aspire to automatically grab the connection string without changing anything in the resources. My case is that sometimes we want the development environment to use resources like blob storage and azure sql databases on the staging environment and the resources on the staging environment are deployed by Aspire.

It could be that RunAsExisting is not the right solution for us and I just misunderstood its purpose. Maybe AddConnectionString is better? I just think it would be nice to have the resources visible in the dashboard.

Employees in our organization do not have access to grant themselves access. Access is granted and controlled by IT through groups.

However, it works great with the code snippet captainsafia posted above. It does not seem to work in Aspire 9.2. I believe the role assignment architecture has been refactored. Is there a way to remove role assignments in 9.2 or is it better for me to just use AddConnectionString?

[davidfowl]

I think we should elevate this to an issue. For now revert to AddConnectionString.

As for the resource not being visible in the dashboard, it was an explicit choice but something we can improve

cc @eerhardt