Thousands of results appear when you type “AWS and Azure” in Google. They talk about the difference, pros and cons, and more. Though these cloud giants have individuals features that clearly make them superior to the other, it is often difficult to select one of them. Today, the pay-as-you-go option is a boon in such scenarios. Thus, allowing users to pick the best from both the cloud service providers.
However, there still is a problem or rather area of concern i.e. Compliance. The one word that stops creative people in their tracks. You see, AWS services are designed to work best with each other, and it’s the same with Azure. You can write policies and have trust relationships on AWS so that the services communicate securely with each other without exchanging any sensitive keys that you don’t want to be exposed, while on Azure you have managed identities and key vaults to store and retrieve any secrets.
I came across the same dilemma when a requirement of communicating with azure resources like storage blobs, virtual machines, and cosmos DB uses AWS lambda. Here, I would like to share my approach that met all the compliance needs, and also there was no significant lag while using these two powerful clouds.
I had a couple of secrets that I needed to safely store and retrieve in Azure like the storage connection string, the cosmos DB URI and connection string, etc. The best place to store them was using the Azure Key Vault. This is fairly straightforward, by just creating a JSON string of all the keys and saving them as a single secret. Post Storing, retrieval was a question? For access Key Vault secrets you need to add access policies and grant users or applications/services access to the secrets. For granting access to an external application, we need to register one in the Active Directory first. So this is how I was able doing it
Head over to Azure Active Directory and register an App. Note down the tenant id, client id, and client secret somewhere, you will need it later. After the App is created, click on it, and then select API permissions. Add permission and select Azure Key Vault. Then click on user impersonation and click on Add permission.
Now that your App is ready, head on back to the key vault. Select Access policies and add access policy. Now give all the permissions you need on this page and then click on select principal. Search for the App you just registered for and grant access to it.
And that’s it! Your Azure application is now ready.
Now head on over to IAM and add a policy that grants access to this secret.
You can now attach this policy to a role that you can assign to any AWS resource you want (typically EC2 or Lambda).
In my case, I attached this role to a group incognito so that only specific users are able to retrieve secrets from Azure and use them to make API calls.
While starting, this project, it was a huge challenge figuring out how to securely share secrets across AWS and Azure. I am familiar with AWS, but Azure was brand new for me. I had to learn the best practices for secrets management and identity access on Azure, then figure out how to combine this with AWS. I feel this is a pretty secure method of sharing secrets as we are using best practices from both platforms. There are plenty of additional options to further strengthen security like key rotation and encryption.
I would like to reiterate the point that using AWS and Azure services together like this is great! You can now once again Google AWS and Azure and see the pros and cons of each individual service that they offer and mix and match according to your needs.