As the title says I'm currently having an issue where the following piece of code take 20+ seconds to execute.
var azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(
new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
var secret = await keyVaultClient.GetSecretAsync(vaultBaseUrl, secretName).ConfigureAwait(false);
The Secret is read eventually but I feel this is an excessive amount of time to wait. I have yet to find anyone with a similar issue.
First time using Key Vault, am I possibly not accessing it correctly?
I had the same issue (on my development machine) and the reason was, that AzureServiceTokenProvider seems first to try a local url's that time out which is probably the better setting when running on Azure but not for local development.
The solution for me was to set the environment variable AzureServicesAuthConnectionString to the value RunAs=Developer; DeveloperTool=VisualStudio on my dev machine.
See also this github issue https://github.com/Azure/azure-sdk-for-net/issues/4645
Try starting the stopwatch after you retrieve your access token from AAD and ending it once you retrieve the secret. I suspect the delay is during the retrieval of the token.
Personally I found it was quicker to just get the token yourself when I created an app that used Azure APIs.
The SLA for Azure Key Vault Service is supposed to be much better
than what you're observing here. I mention it here because if all
else fails, you could take this up with Microsoft Support and they
should be able to help.
SLA for Key Vault
We guarantee that we will process Key Vault transactions within 5
seconds at least 99.9% of the time.
Check which region did you create your Key Vault in? Is your application (where you're accessing it from) in a completely different region by any chance?
Related
guys!
I've just started to use Vault for our applications, and I've noticed few areas for improvement.
So I want to gather more information how it could be done.
I used kv secret engine and have created next path structure:
/{env}/services/{service}
env could be sand/stage/prod1/prod2...
services could be app1/app2/app3...
The first problem is - secrets duplications.
For example:
app1 and app2 need to communicate between each other and they have keys/secrets to do that. So I need to go and add keys/secrets in two places at least: /{env}/services/app1 and /{env}/services/app2
I came up with solution as master-slave secrets. For example:
Create /{env}/common secret and gather all duplications in this place.
Create /{env}/nested secret and set there secrets as common secret key and paths to services: APP1_USERNAME=/{env}/services/app1,/{env}/services/app2
Create l-function to fetch /{env}/common secrets by keys from /{env}/nested and write them to paths defined in /{env}/nested secret values
Trigger function once an hour/two/three...
The second problem is - how to automate secrets adding, or how to notify developers at least.
For example: Developer finished to develop new feature that should use new configuration parameter, and forgot to push it into vault.
Pull request was successfully reviewed and merged, new code deployed and doesn't started due to lack of parameters.
I have some thoughts to use gitHub actions for code scanning and checking secrets in vault.
Is there any practices to handle such situations?
Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?
I just ran into this myself. You can set add a credential using Powershell which is more than 2 years. So I'm guessing it's a UI limitation.
$startDate = Get-Date
$endDate = $startDate.AddYears(98)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId b09d3e1b-417d-425c-be05-9e46943d7207 -StartDate $startDate -EndDate $endDate
Has Microsoft changed the expiration date for Client secrets to be max
2 years? It is not possible to select "Never" anymore?
That's correct. The new expiration age for the client secret can be 2 years maximum.
As of February 2022 it isn't possible anymore:
https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/
Looks like we got an official answer from Microsoft's team at Jun 08, 2021, according to this discussion: https://learn.microsoft.com/en-us/answers/questions/422538/future-plans-of-microsoft-with-the-maximum-expirat.html
This was the final answer from their engineering team:
There are plans to limit lifetimes of the secret administratively. However, there are no current timelines or ETAs of when this will happen. Removing the UX option to have never expiring secrets is a first step of that process (you can still create secrets that never expire with PowerShell, AZ CLI and Graph API).
So, I understood that, for a while, I can use PowerShell's method suggested by Daniel in the accepted answer above.
However, we cannot rely on this forever because sooner or later the 'never' option may disappear completely if Microsoft's plans materialize. I hope it doesn't in this case. As some have said, I also foresee expiration problems in the coming years because of this limitation.
You can set the date through Azure Built in CLI.
Open the Azure CLI in the browser. Then this command below. Note: If you don't pass a password, this will reset your existing password! The end-date is whatever you want it to be:
az ad sp credential reset --name {name of your AD app} --end-date 2035-03-04 --credential-description DescriptionHere
If you want to preserve the App Secret, which is what I needed, I already had created the secret and started using it, make sure to pass the existing password.
az ad sp credential reset --name {name of your AD app} --password {whatever password you want to keep} --end-date 2035-03-04 --credential-description AppAccess
--credential-description is optional but if you don't pass one it will be blank on the UI which is not nice.
Further info:
https://learn.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest
There is an Azure Active Directory feedback request to allow for extension of expirations without having to reset the passwords. Please upvote it as it would be a nice way to solve the issue of having to go through all apps using a Client Secret every few years.
Azure DevOps allows for this on your Personal Access Tokens (PAT). Would love for this to work the same way and allow for extensions in both the CLI as well as the portal:
https://feedback.azure.com/d365community/idea/c9d2da85-8be2-ec11-a81b-6045bd7ac9f9
It can't be changed unfortunately, not even by manipulating your App registration manifest directly (that's how you change most things that are not supported with their UI).
Great, now you have to set a reminder for yourself to update that application in time. If you leave the company there is a good chance the people after you will forget it and break your application from one day to the next..
Very unusual, that client secret supposedly is only known to your server - how exactly does forcing you to change it after 2 years (in which is was evidently unbroken) ANY safer? Now your Azure-operators have to tell your devs/devops the NEW client-secret.. that is a high-senitive information that has to be transferred SOMEHOW - completely unnecessary risk!
That reminds me a bit of companies where you need to change your PW every month. I think at this point in time it is well understood that this actually lowers your security, because people are lazy and find all kinds of workarounds, like appending numbers (worst case: the current month) to the password, greatly weakening the password strength overall.
Same if you have to send a new client-secret for one of your clients every year. Sure everyone KNOWs that you are supposed to use a safe channel (as far as that even exists), but this just invites security issues born out of lazyness, stress or simply human error
Well done Microsoft, i feel safer already..
Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.
Microsoft recommends that you set an expiration value of less than 12 months
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret
I want to use Cosmos db with c# code. A really important point is that data should stay encrypted at any point. So, as I understood, once the data on the server, it's automaticaly encrypted by azure by the encryption-at-rest. But during the transportation, do I have to use certificate or it's automatically encrypted. I used this link to manage the database https://learn.microsoft.com/fr-fr/azure/cosmos-db/create-sql-api-dotnet. My question is finally : Is there any risk of safety if I just follow this tutorial?
Thanks.
I think that's a great starting point.
Just one note, your data is only as secure as the access keys to the account so, on top encryption at rest and in transit, the Access Key is probably the most sensitive piece of information you need to protect.
My advice is to use a KeyVault to store the database access key rather than define them as environment variables. Combined with Managed Identity, your key will never leave the confines of the azure portal which makes it the most secure option. I'm not sure how you plan on deploying your code but more times than not I've seen those keys encoded in source code or in some configuration file that ends up exposed.
A while ago I wrote a step-by-step tutorial describing how to implement this. You can find my article here
I would suggest you to follow the instructions mentioned in here, and not even using access keys, because if they are accidentally exposed, no matter that you have stored them in a Key Vault or not, your database is out there. Besides, if you want to use access keys, it is recommended to change the access keys periodically, which then you need to make this automatic and known to your key vault, here it is described how you could automate that.
Im currently implementing a solution where we are going to store secrets once an hour. It will be the same secret that is updated, or rather we will call SetSecret, since UpdateSecret wont allow us to update the value of the secret. Since Seting a secret with an existing name creates a new version of the same, they will all have an expiry date.
The questions i got is as follows:
Are there any native retention logic for versions. Ex, removed after a certain time if expired/Removed when there is x amount of versions?
If not, is there any max count for versions?
Does it count towards some storage limit?
Manually deleting versions is not possible, so a possible solution will ofcource be to sometimes remove the secret. But this is a step i would like to skip since it will add more complexity if native retention of secrets is supported.
Cheers!
There is no native retention logic within key vault and all the versions will remain in key vault.
There is no limit on the maximum number of versions of a particular secret.
No, it will not be counted towards any storage limit as well.
I'm looking to get at an Azure function app's list of operational endpoints for each function, in particular the secret code that needs to be passed in to invoke the function.
I've tried lots of current answers in SO but all only seem to work with Function App's which use Files as the secret storage type.
We have a requirement to use Blob storage which is also the default in V2 function apps.
What I'm really after is the code piece that comes after the function name when it's retrieved from the Azure portal, I can manufacture all the other pieces before that myself.
For example https://mytestfunapp-onazure-apidev03.azurewebsites.net/api/AcceptQuote?code=XYZABCYkVeEj8zkabgSUTRsCm7za4jj2OLIQWnbvFRZ6ZIiiB3RNFg==
I can see where the secrets are stored in Azure Blob Storage as we need to configure that anyway when we create all the resources in our scripts.
What I'm really look for is how to decrypt the secret stored in the file. I don't care what programming language or script the solution may be written in, I'll work with it, or convert it to another language that we can use.
Here's a snippet of what the stored secret looks like in Blob storage, it's just a JSON file.
I'm wondering if anyone out there has some experience with this issue and may be able to help me out.
For now it's not supported to get the true key value programmatically. you could just view your key or create new key in the portal. You could find the description here: Obtaining keys.
If your function is a WebHook, when using a key other than the default you must also specify the clientId as a query param (the client ID is the name of your new key):
https://<yourapp>.azurewebsites.net/api/<funcname>?clientid=<your key name>
More information refer to this wiki doc: WebHooks.