Let's create a secret and see how it can be consumed. On the secrets page, click the generate/import button. Here we can manually create a secret or upload a certificate and store it as a secret, that is, store a certificate without any of the certificate-specific functionality available under certificates. I'm going to create a database connection string secret manually. The secret value is your basic SQL Server connection string. The content type field is a description field where you can give more details about the secret. The set activation and set expiration fields let you configure dates and times when the secret will be available. You can also make the secret available or not with the enabled switch. Clicking the create button will create and store the secret in the key vault. Ok, we've got our connection string secret which is enabled and ready to use. 

Let's head over to a Winform application where I'm using Azure.Identity and Azure.Security.KeyVault.Secrets to retrieve the connection string secret I've just created. It looks pretty simple, with only two lines of code doing the heavy lifting of actually getting the secret. The main problem with the code is that I need to be authenticated with Azure for it to work. I'm authenticating with DefaultAzureCredential, so I need to run apps under my identity. It works, but far from ideal. We can give apps their own identity through app registrations in Azure active directory. Click on new registration and give your application a name. This name doesn't have to be the same as the app, but it should bear some relationship, so you know at a glance which app the registration refers to. After giving it a name, I'll hit the register button. 

Once the app is registered, I'll grab the application client id. Back in the key vault, we need to create an access policy for the app. Click the Create button under access policies. First, I need to specify my app's permissions, which will be get and list. Just a point of semantics regarding creating and updating secrets. Both of these functions fall under the set permission. Next, we select the principal, which is the app registration. The easiest way is to use the application client id and paste it into the search box. Select the app principal, click next and then create. There we go; the WinFormsGetSecret access policy with get and list permissions on secrets. Back in the app code, I've got a static credentials class with my tenant id, to which I'll add the application client id. In a stroke of irony, we need one more piece of data to authenticate the app – an app secret. 

The tenant and client ids are hardly top secret, so we need an additional value to validate the app. Back in the Azure portal's app registration, select certificates, and secrets. Under client secrets, click New Client Secret. I'll give the client secret a description of ASecretToGetASecret, go with the default expiry period, and click Add. We need the secret value, which I'll copy, not the secret id. I'll paste the secret into the AppSecret member and go back to the get secret code. Next, I'll replace DefaultAzureCredentials with ClientSecretCredential, using Tenantid, Clientid, and AppSecret as parameters. We can now retrieve the ConnenctionString secret using the app's identity, which has been registered with the key vault in an access policy.

Let's now set a secret from PowerShell. We first need to encode the secret's value with ConvertTo-SecureString and put it in a variable. Then we set the secret value with Set-AzKeyVaultSecret. As you'd expect, it takes the vault name, secret name, and secret value as parameters. This scenario illustrates why set is the same as create and update. If the secret name did not exist, a new secret would be created; otherwise, the specified secret is updated. With the command executed, let's go and look at the updated secret in the portal. Clicking on the ConnectioString secret reveals we now have two copies; the current or updated value and the previous value. 

Before leaving secrets, let's look at retrieving a secret from a logic app using a system managed identity. This is probably the most basic logic app you can build; an app with a single HTTP request action. The method will be GET, and I'll grab the URI from the secret's connection string. I'll remove the secret version identifier from the URI, but I'll need to add the API version number as a query parameter. It's 7.3, and you can find the current version in the key vault API reference documentation. Next, we need to configure authentication, which will be managed identity. As the warning message says, I'll need to set that up, but first, I'll enter the audience, which is https://vault.azure.net. 

Ok, we're all done here for the moment, so I'll save the logic app. The next stop is the app's identity, where I'll turn on system assigned managed identity and save it. We copy the object principal Id and head back to the key vault to create an access policy, as we did before with the Winforms app. First, we check the secret permissions, then use the copied object Id to locate the logic app. Select the app, click next and then create the policy. Back in the logic app designer window, I'll run the trigger. Once it's run, we can inspect the HTTP output and see a status of 200 OK, and in the JSON body, we've got the secret value and its attributes. We can retrieve previous iterations of the secret by using its version Id. I'll copy the secret's original URI and paste it into the GET method URI, retaining the api-version parameter. It's a bit quicker and easy to do this through the code view, and click save. When I run LogicalGetASecret now, we get the initial secret value.