Inter-service security options in Azure

    When designing cloud solutions, security is a very important quality to consider.

    In practice, from a networking perspective, some cloud services are exposed to the internet, others reside in private virtual networks in the cloud.

    A common challenge is managing the credentials used to authenticate to these cloud services.

    A simple example application

    When developing an application for the cloud, one may select one or more PaaS services for hosting the application components. Let’s for a simple example assume we would like to develop a web-application. In Azure we could deploy the Azure WebApp service (based on an Azure AppService). After deploying the service we would deploy our web-application code to the newly created WebApp.

    Now, let us make a second assumption. Let’s assume we need to store all web-application user interaction. In Azure we could provision a Storage Account and use blob storage.

    To be able access the Storage Account from our web-application code from a security perspective we could:

    1. provide anonymous access to the blob container;

    2. use (one of the) access key(s) at the service level to obtain access to all storage entities of the Storage Account;

    3. generate a SAS-token as an access key at the service level to obtain access to all or a subset of storage entities of the Storage Account.

    The first option, isn’t a viable option. We would expose all information publicly to the internet.

    Both latter options require us to embed the access keys into our web-application code (or related settings files) or make sure the access keys are available through environment variables at the service level (and access the environment variable at runtime). Setting an access key at the service level as environment variables is typically performed via a deployment pipeline.

    We would have to make sure not to include the access keys into source control and make sure to rotate (regenerate/renew) the access keys regularly to make sure any leaked access key is invalidated in time.

    Managed Service Identity

    There is a fourth option available for a selected number of Azure services that was until recently in preview. It is called ‘Managed Service Identity’ (MSI) and provides a mechanism for inter-service security.

    The MSI feature provides Azure services with an automatically managed identity in Azure AD. You can use the identity to authenticate to any service that supports Azure AD authentication, including Storage Accounts, without storing any credential in your code.

    The managed identities for Azure resources feature is free with Azure AD for Azure subscriptions. There’s no additional cost.

    To be able to use an MSI for authentication between our WebApp and Storage Account we first need to enable it in the WebApp.

    Enable MSI at WebApp

    As a result of enabling the MSI, its identity is registered in the Azure AD.

    Tying it all together

    For the WebApp to be able to access the Storage Account, we need to add the identity of the MSI with the correct permissions to the access policy of the Storage Account.

    Add permissions to Storage Account

    In the IAM section of the Storage Account, create a role assignment using the MSI of the WebApp with the desired permissions to access the Storage Account.

    In the code of the web-application, to be able to access the Storage Account, because we ‘linked’ the two services together via Azure AD we do not need to provide access keys anymore.

    Because of using a MSI we eliminate the burden of managing access keys by making sure that;

    1. credentials (keys) are not stored in source control;

    2. the application does not need to obtain credentials from settings or environment (it uses an implicit flow for authentication);

    3. no keys are used, security can’t be compromised by leaked keys.

    René Vermijs

    Rene Vermijs is sinds begin 2018 Azure Cloud Solution Architect bij Profit4Cloud. Met ruim 20 jaar ervaring aan bagage adviseert hij opdrachtgevers bij Azure Cloud-oplossingen.