Skip to content

Unclear how to add and manage secrets #8824

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
dluc opened this issue Apr 16, 2025 · 8 comments
Open
1 task done

Unclear how to add and manage secrets #8824

dluc opened this issue Apr 16, 2025 · 8 comments

Comments

@dluc
Copy link

dluc commented Apr 16, 2025

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

After an initial deployment I added a couple of secrets to a project, following this doc https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/external-parameters

  • added accesskey1 and accesskey2 Parameters in AppHost's appsettings.json
  • set values using dotnet user-secrets set "Parameters:accesskey1" "..." and dotnet user-secrets set "Parameters:accesskey2" "..."
  • run azd deploy

The deployment kept failing with:

ERROR: failed deploying service 'myResource': failed executing template file: template: manifest template:25:19: executing "manifest template" at <securedParameter "accesskey1">: error calling securedParameter: parameter accesskey1 not found

After trying different approaches, I ran azd provision and it prompted for the two secrets, updating .azure/{envname}/config.json, adding the two new entries:

{
  "infra": {
    "parameters": {
      "accesskey1": "vault://11073122-0831-4cba-9ed8-17ec4360fde8/aaa665e4-ac99-46c7-acd8-a36d44e7bc32",
      "accesskey2": "vault://11073122-0831-4cba-9ed8-17ec4360fde8/26b3d840-c3ff-491a-bf38-cf893bcc6714",
      "qdrantstorage_Key": "vault://11073122-0831-4cba-9ed8-17ec4360fde8/cd946f29-c6b9-4003-9701-f164de0926eb"
    }
  },
  "vault": "11073122-0831-4cba-9ed8-17ec4360fde8"
}

My deployment doesn't include any AKV. The vault is stored locally on my workstation, under ~/.azd/vaults/11073122-0831-4cba-9ed8-17ec4360fde8.json, where the secrets are saved in base64 format:

{
  "26b3d840-c3ff-491a-bf38-cf893bcc6714": "cGFzc3dvcmQ=",
  "aaa665e4-ac99-46c7-acd8-a36d44e7bc32": "cGFzc3dvcmQ=",
  "cd946f29-c6b9-4003-9701-f164de0926eb": "Zm9vYmFy"
}

azd deploy is reading secrets from this file and ignoring those set with dotnet user-secrets, which seems to deviate from the documentation.

Additionally, azd env set-secret "accesskey1" prompts for a KeyVault from Azure, rather than updating this local file.
I haven't found how to update these secrets with azd so I'm editing the vault file manually encoding/decoding these base64 values.

Forcing values

FYI, I tried this but the values are ignored. The secrets in Azure portal are the values coming from AZD vault:

var key1 = builder.AddParameter("accesskey1", secret: true, value: "accesskey 1");
var key2 = builder.AddParameter("accesskey2", secret: true, value: "accesskey 2");

myResource
    .WithEnvironment("App__Authorization__AccessKey1", key1)
    .WithEnvironment("App__Authorization__AccessKey2", key2)

.NET Version info

azd version 1.14.0 (commit c928795c47f27d1e997c217147dc649054ac05c8)
dotnet 9.0.202
Aspire.AppHost.Sdk 9.1.0

@davidfowl
Copy link
Member

davidfowl commented Apr 16, 2025

Yea this part of aspire + azd is really messy. Anything defined in the app host's configuration is used for development not deployment.

@davidfowl
Copy link
Member

cc @vhvb1989 This is something we should spend some time on.

@davidfowl
Copy link
Member

I'm not really sure that secrets should ever be pushed from your local environment to the deployed environment by default. That should be an explicit operation with potentially different values from whatever was in user secrets. I can see the argument being that maybe azd provision/deploy is about moving from local dev to remote dev so it can use the same values.

@ekomsctr
Copy link

Yea this part of aspire + azd is really messy. Anything defined in the app host's configuration is used for development not deployment.

This. I'm using the Publish feature from Visual Studio, and when i create a new Environment, the IDE prompt me for the Parameters value, which are stored then in the config.json file in the .azure/ folder.

After that, when i deploy the aspire solution to ACA (both from right click > Publish and running azd up), the only Parameters used are the ones from the AppHost appsettings.Development.json, not even the appsettings.json are being considered.

Can we shed some light on this? It gets tiring replacing manually some configured secrets every time.

@davidfowl
Copy link
Member

After that, when i deploy the aspire solution to ACA (both from right click > Publish and running azd up), the only Parameters used are the ones from the AppHost appsettings.Development.json, not even the appsettings.json are being considered.

Can you clarify what you mean by this? azd should be using config.json for parameter values, are you seeing something different?

@ekomsctr
Copy link

I made some test, here's what i found:

  • Launch profile (as to be expected) define the DOTNET_ENVIRONMENT, which determines the appsettings.json the Parameters will be fetched from during deployment (or aspire-manifest generation)
  • The "Right Click > Publish..." deployment seems to be using only the Parameters supplied in the corresponding appsettings..json
  • The parameters supplied in the config.json values are not taken in consideration

Let me know how i can supply you better insights to understand the issue!

@davidfowl
Copy link
Member

@bradygaster @vhvb1989 do the parameters in visual studio come from appsettings.json somehow? I don't see how that can happen unless VS is explicitly reading them from there and giving those values to azd.

@vhvb1989
Copy link

cc @vhvb1989 This is something we should spend some time on.

@davidfowl if you can express this in the manifest, AZD can take the user-secrets from dotnet during deployment. For example:

"param-to-user-secret": {
      "type": "parameter.v0",
      "value": "{param-to-user-secret.inputs.value}",
      "inputs": {
        "value": {
          "type": "string",
          "secret": true,
          "default":{
            "value": "{dotnet.user-secrets.secret-name}"
          }
        }
      }
    }

This would be telling anyone deploying that the value for the param-to-user-secret can be defined/overridden BUT, by default, it is mapped to dotnet user secret: secret-name.
AZD would respect any override for the parameter or, when not explicitly set, it would run dotnet user-secrets list to fetch the value for the parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants