Introduction:

Azure KeyVault stores secrets consumed by users, applications, services, and devices without the need for clients 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 otherwise:

Whitelisting

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. 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.

Role Based Access Control

An Azure login context can be set to a given subscription which can then be used to find the service principal and the role that needs to be allowed access to the resource. With the help of this principal, an application can be added to its operation service role. The addition of principal to role is done with internal security context and not that of the logged-in principal. This security context or the privilege to add members to roles can be facilitated by a secret in the key-vault. Similarly, other security group-based role assignments which can empower different workflows in different contexts, can also be created. This completes the access control for the resources by leveraging the least-privilege policy.

Proxy services:

KeyVault can be integrated with existing applications as an HTTP pipeline. An HttpPipelinePolicy is one that can mutate the request and the received response enabling it to work just like an Nginx handler. It is called pipelining because multiple HTTP requests can be sent in the same TCP connection. In a pipeline, there is no limitation of a response right after a request in a sequence. The resources that KeyVault supports, are part of "/secrets/", "/keys/", or "/certificates/" path qualifiers which allows policies specific to those.