Using least privilege and applying network constraints is a reasonable way to lock down your Key Vault and reduce your attack surface on the Internet. I hope you found this helpful.
So are you saying once you add the region's outgoing IP address to the vnet's FW rules, anyone who runs a logic app in the same region with a valid access token can access that secret?
Just an hour ago, I set up our first ever key vault and with Terraform. This will help me secure the key vault. You are a life saver Dana. This channel is gold.
Can you explain a situation where keyvault is integrated to virtual network and azure function which is not integrated to any virtual network want to access key vault either using private end points
Nice helpful video! The only problem I have is that you already have a VNET created and don't go into how to create one. I would like to restrict access to key vault to only my ContainerApps environment with VNet, but when I create one it asks for all these settings (like IP ranges) which I don't know. Would you have a video that explains this more in depth?
Great video. one question: Why VNET required for PaaS services? - VNET is from IaaS concept right? do I have to create dummy VNET which will be used just for KeyVaults???
Great video...quick question...if you had a commercial application that relied on 100s of endpoints or even 1000s (which were each located at a different client across the world) how would you recommend securing access to Key Vault and even Logic or Function apps? For example, assume you have an appliance running at a client's datacenter and it has a Python app that needs to speak to KeyVault, Function or Logic App - is there a way to secure that access beyond the basics? If you take the approach above you may have 1000s of IP addresses, which might be a management nightmare. It also might be the only way - but I am very curious to what approaches others would recommend. Restricting IP can also be an issue when you consider remote workers (like engineers) and having to grant each of them access. Sometimes security isn't easy at times - but I am hoping there is a way to balance tight security with practical management.
Hi , Can you pls share some insights that if we want to monitor our Azure Key Vault, how can that be achieved? The problem statement is that there are hundreds of customers with their specific customer ID now whenever they change their password we need to know about that someone has changed it. we have the list of all those customer ID? please share your views on the above because I am not getting any stuff on the Azure key vault documentation so that's why I thought to discuss this issue with you.... Note: Azure Monitor we cannot use because our servers are differently managed so pls share any insights of independent with Azure Monitor....
Great video - this got me started on the right path for sure. I am an azure newb. I have an azure function that gets secrets from my keyvault using its principal object ID registered in AAD. All good so far as this works fine. I then turned on my key vault logging via application insights and see another IP from inside azure with the same identity_claim_appid_g and identity_claim_oid_g as my function app getting all the same secrets as my function app. This is confusing to me. These secrets are not super important so I am not worried but I still want to understand what I am seeing. I feel like this is something azure is doing behind the scenes that I am not understanding. Anyone who can help out I would very grateful. One more thing - I implemented another function app and keyvault and see the exact same thing.
Can you elaborate KeyVault with DevOps via Firewalls network? Azure DevOps is not a trusted service and thus could not fetch key vault secrets without ip whitelisting. Devops have over 2000 ips to white list and thus not a feasible solution.
Using least privilege and applying network constraints is a reasonable way to lock down your Key Vault and reduce your attack surface on the Internet. I hope you found this helpful.
So are you saying once you add the region's outgoing IP address to the vnet's FW rules, anyone who runs a logic app in the same region with a valid access token can access that secret?
Just an hour ago, I set up our first ever key vault and with Terraform. This will help me secure the key vault. You are a life saver Dana. This channel is gold.
Extremely helpful Dana! .Thanks you so much and I am so happy i found your channel . Liked all your videos with a thumbs up! :)
absolutely spot on. Thanks for uploading these informational videos.
Really like the step by step detailed explanation. Thanks a lot :)
Good stuff man. Keep up the good work.
Amazing explanation. Thanks a lot for making this video. 100% going to subscribe your channel
You explained this topic well!
Can you explain a situation where keyvault is integrated to virtual network and azure function which is not integrated to any virtual network want to access key vault either using private end points
Very good session. Wish you have time to resume sessions.
Nice helpful video! The only problem I have is that you already have a VNET created and don't go into how to create one. I would like to restrict access to key vault to only my ContainerApps environment with VNet, but when I create one it asks for all these settings (like IP ranges) which I don't know. Would you have a video that explains this more in depth?
Thanks for sharing!
Your video is awesome!
Great video. one question: Why VNET required for PaaS services? - VNET is from IaaS concept right? do I have to create dummy VNET which will be used just for KeyVaults???
Great video...quick question...if you had a commercial application that relied on 100s of endpoints or even 1000s (which were each located at a different client across the world) how would you recommend securing access to Key Vault and even Logic or Function apps? For example, assume you have an appliance running at a client's datacenter and it has a Python app that needs to speak to KeyVault, Function or Logic App - is there a way to secure that access beyond the basics? If you take the approach above you may have 1000s of IP addresses, which might be a management nightmare. It also might be the only way - but I am very curious to what approaches others would recommend. Restricting IP can also be an issue when you consider remote workers (like engineers) and having to grant each of them access. Sometimes security isn't easy at times - but I am hoping there is a way to balance tight security with practical management.
Hi , Can you pls share some insights that if we want to monitor our Azure Key Vault, how can that be achieved?
The problem statement is that there are hundreds of customers with their specific customer ID now whenever they change their password we need to know about that someone has changed it.
we have the list of all those customer ID?
please share your views on the above because I am not getting any stuff on the Azure key vault documentation so that's why I thought to discuss this issue with you....
Note: Azure Monitor we cannot use because our servers are differently managed so pls share any insights of independent with Azure Monitor....
Great video - this got me started on the right path for sure. I am an azure newb. I have an azure function that gets secrets from my keyvault using its principal object ID registered in AAD. All good so far as this works fine. I then turned on my key vault logging via application insights and see another IP from inside azure with the same identity_claim_appid_g and identity_claim_oid_g as my function app getting all the same secrets as my function app. This is confusing to me. These secrets are not super important so I am not worried but I still want to understand what I am seeing. I feel like this is something azure is doing behind the scenes that I am not understanding. Anyone who can help out I would very grateful. One more thing - I implemented another function app and keyvault and see the exact same thing.
Can you elaborate KeyVault with DevOps via Firewalls network? Azure DevOps is not a trusted service and thus could not fetch key vault secrets without ip whitelisting. Devops have over 2000 ips to white list and thus not a feasible solution.