AI is everywhere at the minute, and everyone is trying to develop a way to implement AI in their products or workflows. Azure’s open AI services are a great way to do this, but because they’re so easy to deploy and use, you can end up with a proliferation of AI services. The default security settings for these resources are often set up for convenience and ease of use, rather than locking down your precious data and IP.
Generate SAS Tokens in ARM Templates Without much fanfare, MS recently updated the ARM template spec to allow the creation of SAS tokens inside a template. This is excellent news for anyone who is deploying resources with ARM templates that rely on storage accounts and need a SAS token to access them.
For those not familiar with SAS tokens, you can read more on them here but essentially Shared Access Signatures (SAS) provide a way to generate a key to undertake operations on a storage account, without needing the actual storage account key.
If your application is running on a Kubernetes cluster in Azure (AKS, ACS or ACS Engine), then it is likely that you will need to access other Azure resources from your pods that are secured with Azure AD. These operations could include retrieving secrets from Key Vault, files from Blob storage or just interacting with other applications or API’s that use Azure AD as their identity provider. To be able to do this your application needs to be able to provide an identity to access these resources securely.
Managed Identity (MI) service has been around for a little while now and is becoming a standard for providing applications running in Azure access to other Azure resources. We’re going to be taking a look at using MI in a few areas in the future, such as Kubernetes pods, so before we do, I thought it was worth a primer on MI.
Managed Service Identity has recently been renamed to Managed Identity.
