Self-hosted password solution in Azure
In this article, I’m excited to introduce a project I’ve been working on that only uses Microsoft Azure resources to build a robust, secure, and self-hosted solution for managing and sharing secrets.
This solution not only ensures that sensitive data remains encrypted and unreadable to unauthorized users, but also integrates optional passphrase protection and email notifications for enhanced usability and security.
Let’s dive into how the solution works and explore some practical use cases where this setup could be useful.
Architecture Overview
I wanted to create a solution that solely uses Azure PaaS Resources because they are easy to deploy and configure, have great monitoring and logging possibilities, are affordable and easy to integrate with other solutions.
Components Used
- Static Web Apps:
Hosts the front-end interface where users can securely create and retrieve secrets. - Azure Functions (PowerShell):
Acts as the backend, handling encryption, decryption, and communication with Azure Key Vault. - Azure Key Vault:
Safeguards the encrypted secrets. - Managed Identity:
used as a security principal to interact with the Key Vault - Azure Communication Service:
Sends email alerts containing the secret name and optional passphrase
How It Works
Creating a Secret:
A user accesses the Static Web App and submits a secret along with an optional passphrase and recipient email address.
The Azure Function encrypts the secret locally using the provided passphrase and stores the encrypted version with a unique secret name in Azure Key Vault as a base64 encoded value.
So the secret is not just encoded, but first encrypted and salted, and after that encoded before and stored in the Key Vault. This is done to make sure that a Key Vault Secret User or Administrator can see the stored values.
Once stored, an email is sent to the recipient containing the unique secret name and the passphrase (if provided).
Retrieving a Secret:
After the recipient has received the e-mail, he can use the information provided to request the secret value. The email will look something like below, but styling can be fully adjusted to your needs in the Function App
The recipient uses the secret name and (if applicable) the passphrase to retrieve the secret via the Static Web App.
The Azure Function retrieves the base64 value which contains the encrypted secret value. than tries to decrypt the secret and returns the secret value to the user.
Once the secret is retrieved, it is deleted from the Key Vault, ensuring that it cannot be accessed again.
Ensuring Complete Deletion:
By disabling purge protection and soft delete in Azure Key Vault, the secret is permanently deleted after retrieval.
The passphrase and recipient address are optional fields. When not provided, the secret will still be encrypted, salted and encoded before stored in the Azure Key Vault
Make sure to copy the returned secret name that is shown on the page. This secret name is required to retrieve the value, and without you will never be able to retrieve the secret value.
Key Features
Encryption at the Function Level:
Secrets are encrypted before being stored in Azure Key Vault, ensuring that even Key Vault administrators cannot access the plaintext data.
Passphrase Protection:
Users can add an optional passphrase for an additional layer of security.
Email Notifications:
Automatically sends an email with the secret name and passphrase (if provided) to the recipient, streamlining the sharing process.
Complete Secret Lifecycle Management:
Secrets are destroyed after retrieval, preventing unauthorized reuse.
Operational Costs
The costs for running this service depends on the resource SKU’s that are used. In the current setup I have not used any network integration so I could use a cheaper Function App. The estimated costs for the who solution is approx. $5,- per month.
Possible Use Cases
This solution is ideal for organizations and teams looking for a self-hosted, secure way to manage and share secrets. Here are some potential use cases:
1. Internal Password Sharing
Organizations can use this solution as a secure platform for sharing credentials between team members without relying on third-party password managers.
2. Temporary Access Tokens
Distribute time-sensitive or one-time-use access tokens securely and ensure they are destroyed after use.
3. Client Credential Sharing
IT consultants or service providers can share sensitive credentials with their clients securely, with the assurance that the information is only accessible once.
4. Onboarding Processes
Simplify onboarding processes by securely distributing initial passwords or secrets to new employees or contractors.
5. Developer API Keys
Developers can share API keys among team members without risking exposure or unauthorized access.
Resources
Link to the resources will be posted later as I am still busy creating the bicep templates.
Follow me on bsky to stay updated!
Rogier Dijkman | MVP (@rogierdijkman.bsky.social) — Bluesky
