If you are working on Azure, as a standard practice for governance and security, your cloud team may require you to create and maintain separate Azure subscriptions for production, development, and test environments. Separate Azure subscriptions provide optimal isolation and control between environments to ensure that administrators or operations team members restrict access to production environments while developers get the freedom to create, delete, and break things at their will in their own contained environment without any risk of impacting production. This strategy works very well and is widely adopted by Azure customers.
A challenge our customers often encounter with this approach is the inability to restore production databases across different Azure subscription. Restoring production databases on developer or testing subscriptions may be required for troubleshooting production issues or simulating a production-like environment in testing. Most Azure data services, including Azure Database for PostgreSQL, don’t allow for restoring database backups across Azure subscriptions. This is an intentional choice made by our engineering team to ensure data security, as subscriptions are strongly honored as tenant boundary. To address this, many of our customers rely on logical backup solutions such as dump and restore to extract data from a production server and restore it in the developer subscription, but the process is time- and resource-intensive, and it cannot scale. The good news is that there is a better way to accomplish this solution that can save you time and additional compute resources as you leverage built-in automatic backups and resource movement across subscriptions.
To achieve this, use the following process.
- Perform a Point-in-time Restore of the server in the same Azure subscription – You can restore from the automatic backups of the production server in the same Azure subscription but in a separate resource group by using the Azure portal or Azure CLI.
- Prepare the restored server for developer access - Your production database may contain sensitive customer information or business data that for security reasons you may not want to expose to developers. In this scenario, you can run your custom data masking script on the restored database to delete, hide, or obfuscate sensitive data. In addition, the production server may not have developer logins, so you may want to create logins to allow developers to connect to the restored server and delete any unwanted logins that may not need access to this server. In summary, in this step, you would prepare the server before moving it to different subscription and opening it for developer access. While this step is recommended it may not be generally required and can be omitted.
- Move the restored Azure Database for PostgreSQL server to developer subscriptions – This is the magic step which does the trick. Azure Resource Manager (ARM) allows you to move resources to a new subscription or resource group. You can leverage this feature to move the restored Azure Database for PostgreSQL server to your intended Azure subscription using the interface shown below:
After you complete the move of restored server, the server will now be ready and available for developers’ use.
While using this approach might require a few additional steps, it helps to provide an additional layer of security and governance than does providing direct production access to your developers. You can also script the additional steps using Azure CLI if this a recurring operation in your environment and you periodically need to restore your production databases in developer environments.
We hope you find this approach useful and efficient should you have to go through this drill!!!
Acknowledgments
Special thanks to Sundeep Kambhampati and Rachel Agyemang for their contributions to this posting.
Parikshit Savjani
Principal Program Manager