Any one who can hack into my code and get the client id, tenant id and cert thumbprint can access the secrets stored in my key vault. So what’s the difference between this and just storing the secret values directly in my code where any one who hacks into my code could read?
Even if someone was able to get that info, your vault will still be secure because in order to access your Key Vault and view the contents inside, a user, app, or identity will need to be added to your Key Vault's management plane (RBAC), and data plane (access policies) to view anything within your vault.
Therefore, if a user has a TenantID they still won't have access to your AKV unless they have the credentials of a user, app, or identity that has the correct RBAC and access policies permissions.
For more info: Management plane and Azure RBAC Data plane and access policies
For applications hosted in Azure, using Managed Identity is preferred. This is a separate principal where a password is never made available to even steal or leak.
If you use the DefualtAzureCredential in the Azure SDKs, you can better configure your vault for development and production environments. You can give limited permissions to AAD users, who can log in via Visual Studio, Azure CLI, Az PowerShell Module, and more. Without modifying the code, your application can rely on Managed Identity with its own set of permissions. For example, maybe you use different vaults for production and development configured by a setting where Managed Identity has read access to secrets/keys, but your devs don't - not in the production vault. Role-based Access Control is also coming to Managed HSM (a more secure hardware-based Key Vault) to have principal granularity even in the same vault.
Service principals using environment variables can be used in lieu of Managed Identity but should be reserved only for your production environment, ideally. Devs could also have one, but that probably means sharing of client IDs and secrets, which provides little to no mitigation if someone leaves or information is leaked - no easy mitigation, anyway.
Related
I have developed an Azure Function using visual Studio 2019. now when i deployed the Azure Function inside Azure >> all the settings (which contain some sensitive info) inside the local.settings.json, will be added inside the ""Azure Configuration" >> "App settings"". And as indicated by the page message that those values are stored encrypted, as follow:-
so does this mean that there is no need to take extra steps to secure the sensitive info inside the App setting by using Azure Key Vault ? as those are already secured?
They are secure, but users with permissions to the recourse can potentially access them with a role such as e.g. Contributor. Using a Key Vault would allow you to define access controls more precisely.
As example; Should somebody whose sole responsibility is to manage the resource have access to the secrets?
Also Key Vault allows for some other scenario's like being able to manage secrets centrally or share them across multiple resources (e.g. App Services across multiple regions). And maybe one that's often overlooked; monitoring. E.g. being able to tell 'who' accessed what key at what time.
Edit: link for adding key vault references to your app settings
It is considered a best practice to store any secrets your application might need in a Key Vault. This way, if someone has access to the application that needs to use these secrets in the Azure portal, they would still not have access to the actual secret.
Centralizing storage of application secrets in Azure Key Vault allows you to control their distribution. Key Vault greatly reduces the chances that secrets may be accidentally leaked. When application developers use Key Vault, they no longer need to store security information in their application. Not having to store security information in applications eliminates the need to make this information part of the code. For example, an application may need to connect to a database. Instead of storing the connection string in the app's code, you can store it securely in Key Vault.
Your applications can securely access the information they need by using URIs. These URIs allow the applications to retrieve specific versions of a secret. There's no need to write custom code to protect any of the secret information stored in Key Vault.
Source: About Azure Key Vault - Why use Azure Key Vault? - Centralize application secrets
TL;DR
Do you need to use Key Vault currently? Maybe not, although still depending on how many other people have access to the Subscription / Resource Group / Function App.
Would I advise you to put your secrets in Key Vault? Yes. Especially by doing so now will get you used to working with Key Vault and get you prepared for the future.
EDIT:
For referencing secrets from Key Vault, have a look at Key Vault references. This enables your application to get the secrets from Key Vault without the need for any code change!
For documentation on how to, please see Use Key Vault references for App Service and Azure Functions.
EDIT 2:
even if we store them inside Azure key vault they can be viewed
Yes, but then only if someone has the correct role assignment. If the secret is in Application Settings, anyone with access to the Function App inside of the Azure portal can also see the secrets.
Is there any point in using Azure Key Vault over App Configuration?
Yes, yes, I know - they are complimentary, key vault for secrets, app config for... well, app config.
But, considering they are both encrypted, basically for someone to see either a secret or a config value they'd have to have access to your azure portal (this is a low-level bad guy scenario).
The ONLY difference I see is that you can control permissions differently between the vault and config but apart from that if someone unauthorized has access to your portal you've got bigger problems.
So - why? and please only good and real arguments no "because you should" or "because person X said so", what benefits would I reap with key vault that I don't have with app config?
I appreciate your question. I'd re-phrase it to this:
Q) How are are Key Vault and App Configuration designed differently supporting different purposes? And where can I find a clear comparison table of features and benefits?
I also appreciate your aside:
please only good and real arguments no "because you should" or
"because person X said so", what benefits would I reap with key vault
that I don't have with app config?
Here is what I found to understand benefits as a contrast:
Article 1: What is Azure App Configuration?
App Configuration complements Azure Key Vault, which is used to store application secrets. App Configuration makes it easier to implement the following scenarios:
Centralize management and distribution of hierarchical configuration data for different environments and geographies
Dynamically change application settings without the need to redeploy or restart an application
Control feature availability in real-time
Article 2 : Key management with Key Vault
Key management with Key Vault
Without proper protection and management of the keys, encryption is rendered useless. Key Vault is the Microsoft-recommended solution for managing and controlling access to encryption keys used by cloud services. Permissions to access keys can be assigned to services or to users through Azure Active Directory accounts.
Key Vault relieves organizations of the need to configure, patch, and maintain hardware security modules (HSMs) and key management software. When you use Key Vault, you maintain control. Microsoft never sees your keys, and applications don’t have direct access to them. You can also import or generate keys in HSMs.
Article 3: Azure Key Vault recovery management with soft delete and purge protection
Soft delete and purge protection are two different key vault recovery features.
I think you should not neglect the fact that someone that have the configuration of your App Service can see the secrets. A developer of your company could have access a production App Service for bug investigation but it should not mean he has access to production secrets. The fact of having a single employee's laptop (with access to Azure Portal) hacked should not necessarily mean "access to every secret of your application".
But appart from (as you already know the above), what differences I see:
Better governance and acess monitoring : you have logs to see who try to access each secret, when and how, something you cannot do in an App Service
Better secret management: all secrets stored in one place, you only modify them in key vault once instead of on each app service configuration when some secrets are shared in (used by) multiple app services
Some advanced mechanism like recovery management and purge protection
Better development experience : when debugging an app, if your user has access to the keyvault he can just run the app that will load secrets from keyvault into configuration instead of manually copying secrets from azure app settings locally
1-Data stored in Azure Key Vault is encrypted (App Configuration is not)
2-If a person is associated with Contributor role, he/she can see the configurations in your App Configuration, on Key Vault, only allowed Principals.
3-You can rotate secrets stored in Azure Key Vault, and there won't be any downtime in your app (unless you're caching it on your App Service and need to restart it, in order to refresh the cache)
4-Azure Key Vault is the Microsoft recommended service to store Secrets, Keys and Certificates
I run a very simple nodejs web app on Azure App Services. I need to pass a secret into the app, for which I use dotenv locally. I can set these environment variables in Azure configuration Application settings. Wonder if the secrets are secure there I found I can also store them in Key Vault referencing to them in the environment variables using #Microsoft.KeyVault({referenceString}). In both places I can "unhide" the secret, so I wonder what the advantage of the one over the other is in my scenario?
In the Application settings, the app setting is not really hidden, as you know, simply click Show values then you can see it. Also, anyone has the read permission at your web app scope, he will always be able to check this value, not only the portal UI, but also
azure powershell, cli, resource explorer, etc.
To store the it as a secret in keyvault is secure, just the one(in your case, the system-assigned identity of the web app) who has the correct permission in the Access policies can access the secret. The other people will not be able to access the secret(they are not the RBAC roles e.g. Owner, Contributor in the subscription/keyvault, otherwise they can add themselves to the Access policies).
For more details, see Secure access to a key vault.
Is it industry best practice to cache your ClientID, SecretId and/or Thumbprint to retrieve KeyVault secrets?
If possible is there a sample code for me to do it in C#?
All you need to secure it the secret and the thumbprint. Essentially anything that can be used to access the resource. If you really want to, you can secure the client ID as well, but I haven't heard of anyone suggesting this or recommending this.
Per the Keyvault Overview:
Azure Key Vault helps solve the following problems:
Secrets Management - Azure Key Vault can be used to Securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets
Key Management - Azure Key Vault can also be used as a Key Management solution. Azure Key Vault makes it easy to create and control the encryption keys used to encrypt your data.
Certificate Management - Azure Key Vault is also a service that lets you easily provision, manage, and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for use with Azure and your internal connected resources.
Store secrets backed by Hardware Security Modules - The secrets and keys can be protected either by software or FIPS 140-2 Level 2 validates HSMs
I suggest reading through the referenced overview for keyvault and looking through the docs as well : https://learn.microsoft.com/en-us/azure/key-vault/key-vault-overview
Does the Key Vault offer any benefit (security or otherwise) now that an app service can use Managed Identity to authenticate with other Azure resources? (E.g. azure storage and sql)
Is there any reason to use Managed Identity to access Key Vault and get a key for Storage, for example, now that an app service can directly use Managed Identity to talk to Storage?
You should always use Managed Service Identity where available, however they are not ubiquitous across all Azure. The list of supported services is maintained here. Keep in mind that the calling service needs to support authenticating with it's Managed Service Identity and the called service needs to be able to authenticate and authorise using Azure Active Directory.
When you have a service that does not directly support AD authentication (e.g. CosmosDB), then you still need to store and manage keys and KeyVault is still the right place to do this. This also applies to some 3rd party services like Salesforce, AWS, GCP, etc where "federation" may not be in place. You may also have additional sensitive config that you do not want to store in plain text.
Keep in mind that function appsettings can now directly reference KeyVault, saving the overhead of writing code and config to manage this yourself. See this link.
I would also say, that usage of managed identity should be preferred whenever possible. The major benefit I see is getting rid of credentials you have to manage. You outsource the authentication challenge to Microsoft here, and I would say it works very well.
One less credentials you need to protect, refresh, revoke etc.
I also believe that this goes well in the spirit of Infrastructure as a code, where you define you concern yourself with authorisation and leave secure authentication on the provider.