If you only take one thing away from this blog post, let it be this:
Hopefully this can inspire you into looking at solutions for automatically configuring secrets and connection strings. Since the developers are logged in with az they can only fetch secrets and configuration values they have access to.Īnother interesting fact is that by using this secrets.sh pattern you can change where the values are read from and how without having to do anything else than ensure that the developers have the correct CLI installed on their machine. You also get the ability to control who can access the secrets. One of the strengths of using az to read values from resources in Azure like this is that the only thing a developer needs to do if one of the Keyvault values changes is to run secrets.sh for a quick refresh. secrets.sh dev your application now has access to mysecret and can use it as needed.
MYSECRET=$($azCmd keyvault secret show -vault-name mykeyvault-$ENVNAME -name mysecret -query value | sed -e 's/^"//' -e 's/"$//')ĭotnet user-secrets set mysecret "Hardcoded example is $MYSECRET"Īfter executing. Now we'll combine this with the secrets.sh: # secrets.sh modified $ MYSECRET=$($azCmd keyvault secret show -vault-name mykeyvault-$ENVNAME -name mysecret -query value | sed -e 's/^"//' -e 's/"$//') $ MYSECRET=$($azCmd keyvault secret show -vault-name mykeyvault-$ENVNAME -name mysecret -query value) # This will have " as part of the variable value Let's first fetch the secret value from my dev keyvault, strip away " and prepare the secret value for usage in the secrets.sh script. To remove the start and end quotes you can use sed like this: sed -e 's/^"//' -e 's/"$//' A secret containing a connection string with a hidden " or two inside of it can be very frustrating to debug. For some reason bash and az will helpfully add a starting and stopping " if you don't remove them. Now we'll add a secret based on a value saved in my private keyvault, but first, a gotcha when reading strings from Azure Keyvault using az, you'll end up with a "quoted" string. Let us start with a very simple az "whoami" equivalent: # secrets.sh modifiedĮcho "Logged into: $($azCmd account show -query name)"Įcho "Logged in as: $($azCmd account show -query user.name)" You probably noticed az not being used in the example. Successfully saved mysecret = Hardcoded example to the secret store.
Regardless of how many secrets a project contains, all you need to get up and running are three simple steps: $ git clone In this example there is a lot of work for only setting one secret, but as the number of configurations required for an application to run increases, the cognitive load stays about the same for the developers cloning and running it. If || ĭotnet user-secrets set mysecret "Hardcoded example" # The Git-bash path to Azure CLI is 'az.cmd'. This script creates dotnet user-secrets for the project in typically two environments (dev and test). At a customer project at Thon Hotels I worked on, all new dotnet core microservice projects that needed some kind of connection string or other secrets included a bash script secrets.sh compatible with Git bash, Linux and macOS. Having a standardized way of handling this also reduces the cognitive load on developers moving between different applications.Ĭredentials, secrets and deployment, in general, are hard. Simplifying the process from cloning a repo to being able to run and debug the app locally with access to external resources located in the cloud can be a huge timesaver.
#Visual studio for mac user secrets series
This is the first part of a series about Azure CLI and dotnet user-secrets. The initial time to a functioning working local dev environment can be a big hurdle, especially if the organization you are working for is running any significant amount of microservices.
0 kommentar(er)
