aolmez/aks-postgre-keyrotation

An example of rotating keys for AKS, PostGre SQL using KeyVault

Secret Rotation

Out dated

This repository has been moved under the Microsoft org please check it out there: https://github.com/microsoft/aks-postgre-keyrotation

General

This example project demonstrates how to handle secret rotation from a web application running in Azure Kubernetes Service, stores the secrets into KeyVault and then uses those secrets to access Azure SQL PostGre instance.

This generally requires changes to be done for the source application, the ability to store the secret in a secure vault and updates on the destination application. This is really tricky to do in a way that requires zero down time.

The reason why we are attempting to accomplish this with zero downtime is to remove the friction and high cost of deploying changes to an environment so we can more frequently rotate secrets.

Please see Getting Started for information on how to run the code.

Blue / Green Deployment

One approach to handling the source application updates when using Azure Kubernetes Service is to utilize Azure Application Gateway and handle Blue / Green deployments using helm and the Ingress controller that comes with Azure Application Gateway.

In this diagram we are showing how Azure Pipelines can be used to orchestrate each stage of the overall key rotation process.

Steps and Process

1. Application is Live in Production
2. User will run the KeyRotation pipeline
   1. The pipeline generates a new secret.
   2. The pipeline then updates Azure PostGre SQL by activing the secondary role and changing that role's password.
   3. The pipeline then updates KeyVault's definition of that second password.
   4. The pipeline will then update the source application, in our case it's just rotating one slot with the other slot.
   5. Then integration testing runs to ensure basic end to end functionality.
3. Once everything runs the user deploying the key rotation will manually validate that production is setup properly.
4. Once that validation is done, then the user can run another pipeline to delete the old production pod.