Azure Secret Management System:

Introduction: Azure KeyVaults store secrets consumed by users, applications, services, and devices without the need to manage it themselves. The documentation on this service offering from the Azure Public cloud helps us review some of the features that can be leveraged for its usage. This article captures one aspect of their usage that is popular with DevOps but does not get much attention. Secrets are used to safeguard access to resources and access to those resources must be whitelisted. Depending on the resources, there can be many whitelists and subscriptions, or domains can be whitelisted for root folders.

Description: We begin with a root folder that can be environment-specific and includes Deployment subscriptions and Storage subscriptions. Adding a subscription to this root folder under one of the categories is equivalent to whitelisting that subscription for access to resources. Similarly, there can be many paths granting access and the subscription may need to be added to all these paths. Even new regions can be part of the path and adding a subscription to the new region grants access based on this whitelist.  A whitelist can be followed up with an approval service to complete the addition.

A whitelist can be used together with role-based access control. For example, setting the Azure login context to the given subscription can then be used to find the service principal and the role to which the principal needs to be added. The service principal of an app can be added to the storage key operation service role. Similarly, security group-based role assignments can be created. This completes the access control for the resources.

At the resource level, we can take the example of a storage account, a commonly-used and critical resource for many services.  The secret management system may have a path for all storage accounts and there would be a path specifier specifically for this storage account by name. 

This specific whitelisting then proceeds with the following steps:

Step 1. Determine the rootPath for the storage account and the subscriptionId that needs to be added.

Step 2. Use the DSMSProxy to check if the rootPath folder exists.

Step 3. If Step 2 succeeds, add the subscriptionId to the rootPath folder.

Internal bool whitelist(string rootPath, Guid subscriptionId) {

        If (DSMSProxy.Folders.Exists(rootPath)) {

             DSMSProxy.Folders.AddToWhitelist(rootPath, subscriptionId);

             return true;

        }

        throw new Exception(string.format(“{0} Not Found”, rootPath));

}

Thus, we see a Zookeeper like a strategy to maintain whitelists based on folder paths for resources that complement the RBAC control.