Public static async Task GetToken(string authority, string resource, string scope) Return req.CreateResponse(HttpStatusCode.OK, "SQL credentials collected ok") Var sqlpasswordSecret = await kv.GetSecretAsync(secretUri + "sqlpassword") Var sqlusernameSecret = await kv.GetSecretAsync(secretUri + "sqluser") String secretUri = $" var kv = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(GetToken)) Log.Info("C# HTTP trigger function processed a request.") Public static async Task Run(HttpRequestMessage req, TraceWriter log) Private static string keyvaultname = Environment.GetEnvironmentVariable("keyvaultname", EnvironmentVariableTarget.Process) Private static string clientSecret = Environment.GetEnvironmentVariable("clientSecret", EnvironmentVariableTarget.Process) Private static string clientID = Environment.GetEnvironmentVariable("clientId", EnvironmentVariableTarget.Process) *Īnd a bit of code, sample bellow, for more indept about how to use in Functions read more at Jeff Holan’s blog post: Now to start coding we need some nuget packages: Press the “Add new”, select the principal (AAD Application) in my case the KeyVaultApp, in the Secret Permissions we only want and need Get and no more privileges should be given to the Policy. Now that we have collected the information needed we also need to make sure that our AAD Application has access to the secrets, that is something we are adding to the Key Vault under the “Access Policies”: When it’s created we need to get the Application ID (clientId) and one Key (clientSecret). Accessing Secrets from Functions/Web Apps or other c# applicationsĪny c# application can easily use the KeyVault SDK to retrieve secrets from Key Vault during runtime, but we do need some things in order to make this possible, from code we need an AAD Application in order to grant access to the secrets, I will not go through how to create one here but read more here IMPORTANT if the value in Key Vault is changed a new deployment is required to update the API Connection. The deployment flow looks as follows below where during deployment the secrets is collected from KeyVault (1) and used when creating/updating the API Connection (2) ) this also means that no secrets are stored in the ARM template parameters file and that is great! Now secrets are stored in Key Vault and the developer setting this up don’t know the actual values in test/prod just what the secret’s name is. (Remember deployment time means that if the value is changed a new deployment is needed to reflect the change to the API Connection) When doing a Resource Group Deployment the value is collected from Key Vault during deployment time and then stored in the API Connection. "id": "/subscriptions/fake-a4af-4bc9-a733-f88f0eaa4296/resourceGroups/testenvironment/providers/Microsoft.KeyVault/vaults/ibizmalotest" ![]() Using KeyVault with ARM deployment requires that the KeyVault has enabled access for Azure Resource Manager for template demployment and that the principal (AAD Application) that is used when deploying has permissions to access the secrets.Īfter this secrets are accessible via the ARM Template Parameter file, (only from the parameter file or from a Wrapping ARM Template) here is a sample how it would look like in a parameter file: ![]() So let’s have this sample in our KeyVault where sqluser and sqlpassword should be used in both a Function and when creating a Logic App Connector. It also adds reusability so if the value is needed in a Function and in a Logic App we can make sure it’s the same value that is used and we can manage it in one place. ![]() So with this we can make sure that passwords/usernames and other secrets are not spread via email’s, stored in dropbox or other “safe” places when distributed to the developers to add them to the App Settings or store them in parameter files for our ARM templates. The first step is to centralize the Values and there I find that Azure Key Vault Vault is a superb place for storage, we got RBAC support for granular security, making it possible for a developer to access the values via code or when deploying via ARM template but not to see or edit the value. Usually I find that these are added to Application Settings and manually handled in several places, this is not a desirable way of working and may look something like this, secrets spread out in all areas with red circle: When working with usernames, passwords or api keys these need to be stored in a secure and manageble way.
0 Comments
Leave a Reply. |