Forem: Brian Meinert

From LocalStorage to Zero-Trust: Architecting a Serverless Secret Management Platform

Brian Meinert — Mon, 09 Feb 2026 18:51:31 +0000

Tech Stack: JavaScript, Node.js, Azure Functions, Azure Key Vault, Table Storage, Bicep

The Genesis: Breaking Out of the Browser

This project started the way many portfolio projects do for me: a Frontend Mentor challenge. The prompt was simple, build a password generator using vanilla JavaScript.

I built the core logic quickly: a sliding scale for length, character set toggles (uppercase, symbols, etc.), and a strength meter for user feedback on strength of password. But as I tested it, I hit a wall. I wanted to save the passwords I generated.

I implemented localStorage, which worked fine until I cleared my cache, or opened the site elsewhere. The data was trapped in the browser. I realized that if I wanted this to be a real application, I needed to break out of the browser, giving me the perfect opportunity to scale to the cloud.

This is the story of how a static website evolved into a fully architected, "Zero-Trust" serverless application on Azure.

Phase 1: Designing the "Zero-Trust" Architecture

My goal wasn't just to "add a backend." I wanted to simulate a high-security environment. If I’m storing passwords and other secrets, I need to treat the application like a digital vault.

I established three core constraints for the architecture:

Serverless First: I didn't want to manage VMs or OS updates. I chose Azure Functions (Node.js 18) for the API and Azure Static Web Apps for global hosting.
Hardware-Backed Security: Storing a "Master PIN" in code is a vulnerability. I needed Azure Key Vault to hold the sensitive hash.
Identity-Based Access: The application should authenticate against cloud resources using Managed Identities, not hardcoded connection strings.

The Cloud Infrastructure: A fully serverless topology.

Phase 2: The Identity Challenge

The first major hurdle appeared when I tried to connect my API to the Key Vault.

I initially attempted to use the @azure/identity library to authenticate my function app against the vault. Locally, this worked seamlessly using my developer credentials. However, the moment I deployed to production, the backend crashed.

The Diagnosis:
It was a classic "It works on my machine" environment mismatch. The Node.js runtime environment within Azure Static Web Apps handles identity tokens differently than a standard App Service. The library was failing to retrieve a valid token, causing the handshake to fail.

The Solution: Key Vault References
Instead of fighting the library, I pivoted to a platform-native feature: Key Vault References. By configuring the Application Settings in Azure to point directly to the Vault URI (e.g., @Microsoft.KeyVault(...)), Azure handles the authentication at the platform level. It fetches the secret and injects it into the environment variable before my code even runs.

Phase 3: Persistence & The Build Pipeline Trap

With security solved, I needed a database. A full SQL server felt like overkill for simple key-value pairs, so I chose Azure Table Storage. It is fast, NoSQL, and incredibly cheap for this use case.

The Result: Secure, cloud-persisted storage replacing the temporary localStorage.

I built the CRUD endpoints locally, but when I pushed to GitHub, the build failed silently. The Azure build server was looking at my package-lock.json file to decide what to install. I had installed the database SDK manually, but the lock file hadn't updated correctly.

The Lesson:
I performed a "clean install" locally deleting node_modules and the lock file—generating a fresh, accurate dependency tree. This reinforced a valuable lesson: The build pipeline is the ultimate source of truth, not your local machine.

Phase 4: UX Polish & The Full CRUD Lifecycle

A backend is useless if the user experience feels clunky. I spent the next phase refining the frontend to match the robustness of the backend.

Hybrid Input System:
Originally, the app only generated random passwords. I realized users often want to manage their own passwords. I refactored the display component into a hybrid input/display field, adding real-time strength detection to the strength meter as the user types.

The "Edit" Workflow:
I implemented an "Edit Mode" where clicking a pencil icon loads a saved password back into the generator context. When the user saves changes, the backend uses an update and insert, or upsert, strategy, seamlessly overwriting the old entry.

State Management: Loading existing data back into the generator context.

Native-Feel Modals:
For deletions, I avoided the standard browser alert(). I built a custom modal with a "Don't show this again" preference that persists in the browser via localStorage, giving the app a polished, native feel.

Phase 5: From "Pets" to "Cattle" (Infrastructure as Code)

At this point, I had a fully functional app. But I had built it by clicking around in the Azure Portal. If I accidentally deleted the Resource Group, I would have to remember every setting to rebuild it.

I decided to migrate to Infrastructure as Code (IaC) using Azure Bicep.

The Goal: Define the entire environment, Storage, Vault, Web App, and Permissions, in a single file.

The Challenge: RBAC Orchestration
Being brand new to IaC, there were many challenges that came with this phase, however, the hardest part of automation was permissions. My Static Web App needed permission to read the Key Vault. In code, this requires orchestrating a sequence:

Create the Static Web App (to generate a Managed Identity).
Dynamically retrieve that Identity's Principal ID.
Inject that ID into a roleAssignment resource targeted at the Key Vault.

The Result:
I wrote a main.bicep file that defined the entire stack. I successfully deployed a "Test Environment" parallel to my live app, verified it worked, and then destroyed it with a single CLI command.

Conclusion: What I Learned

This project started as a JavaScript exercise, but it became a much needed crash course in Cloud Engineering.

Key Takeaways:

Security is an Architecture: Storing secrets requires thinking about Identity, not just hashing passwords.
The Cloud is Asynchronous: You have to wait for resources to exist before you can grant permissions to them—Bicep handles this dependency graph beautifully.
Serverless is powerful: I built a scalable, global, secure application for pennies a month.

I now have a Serverless Secret Management Platform that is secure, scalable, and fully reproducible to show off in my portfolio, and for my own personal use.

Link to GitHub Repository

Solving the "MFA Wall" and Other Roadblocks: Setting Up a Cloud-Ready Linux Environment

Brian Meinert — Fri, 19 Dec 2025 15:18:35 +0000

Spending the last few years diving into the multifaceted world of IT, from physical hardware and networking to frontend development and Infrastructure as Code (IaC), I realized they all share a common heartbeat. As someone striving to become a world-class Solutions and Security Architect in the future, I knew it was crucial to become proficient in the engine that powers the modern cloud: Linux.

Provisioning the Environment: Why WSL2?

For a lifelong Windows user (with a little Apple ecosystem sprinkled in), the first hurdle was deciding how to run my Linux distribution. I weighed the options of dual-booting, dedicated Virtual Machines, and the Windows Subsystem for Linux (WSL2).

I ultimately chose WSL2. It offers a seamless bridge, allowing me to run a high-performance Linux environment directly alongside my Windows productivity applications without the overhead of a full VM or the hassle's of rebooting for a dual-boot setup.

However, the installation presented a firmware-level roadblock. My initial attempts to install WSL were blocked because virtualization was disabled in the system firmware. This required a quick trip into the UEFI/BIOS to enable Intel Virtualization Technology (VT-x).

Mastering Navigation and Shell Customization

Once I had my Ubuntu environment live, I spent time leveling up my command-line proficiency. I used the Boot.Dev Linux course to accelerate my learning, which I highly recommend for anyone looking to move past the basics of Bash quickly.

After gaining confidence in navigation, I wanted to customize my environment for better workflow persistence and a touch of personality. I modified my .bashrc file using the nano text editor to achieve two things:

Automated Directory Mapping: I added an auto-CD command so my terminal launches directly into my active project folder on the Windows filesystem (/mnt/c/).

Dynamic Scripting: I wrote a custom Bash script using conditional logic (if/elif). Now, every time I open the terminal, it executes a check against the system date and greets me with a personalized message or a holiday-specific greeting (Christmas, New Year’s, etc.) based on the date command output.

# ==========================================================
# Holiday Greeting Variables
# Format MM-DD for fixed-date holidays
DATE_MONTH=$(date +"%m-%d")

# Calculates the Nth Day of the Week holidays
# Thanksgiving: 4th Thursday in November
THANKSGIVING_DATE=$(date -d "$(date +%Y)-11-01 +3 weeks Thursday" +%m-%d)
# Labor Day: 1st Monday in September
LABOR_DAY_DATE=$(date -d "$(date +%Y)-09-01 +$(($(date -d "$(date +%Y)-09-01" +%w) != 1 ? 8-$(date -d "$(date +%Y)-09-01" +%w) : 0)) days" +%m-%d)

# ==========================================================

# 1. New Year's Day
if [ "$DATE_MONTH" == "01-01" ]; then
    echo "🎉 Happy New Year, Brian!"

# 2. Birthday
elif [ "$DATE_MONTH" == "02-21" ]; then
    echo "🎂 Happy Birthday, Brian!"

# 3. Halloween
elif [ "$DATE_MONTH" == "10-31" ]; then
    echo "🎃 Happy Halloween!"

# 4. Christmas
elif [ "$DATE_MONTH" == "12-25" ]; then
    echo "🎄 Merry Christmas, Brian!"

# 5. 4th of July
elif [ "$DATE_MONTH" == "07-04" ]; then
    echo "🎆 Happy Independence Day, Brian!"

# 6. Thanksgiving
elif [ "$DATE_MONTH" == "$THANKSGIVING_DATE" ]; then
    echo "🦃 Happy Thanksgiving, Brian!"

# 7. Labor Day
elif [ "$DATE_MONTH" == "$LABOR_DAY_DATE" ]; then
    echo "🛠️ Happy Labor Day, Brian!"

# 8. Default Welcome Message
else
    echo "Welcome back, Brian! Ready to build something great."
fi

# Display the Date/Time
echo "Current Time: $(date)"

Azure Integration & The MFA Challenge

With the environment stabilized, it was time to connect to the cloud. I installed the Azure Command Line Interface, but immediately hit a common security roadblock: Error AADSTS50076.

Because my Azure tenant is secured with Conditional Access Policies, my login was blocked due to a missing Multi-Factor Authentication claim. To resolve this, I performed an az logout and cleared the local profile cache (rm -rf ~/.azure) to ensure no stale tokens were causing a conflict.

I then re-authenticated using the --use-device-code flag combined with my specific Tenant ID. By using an isolated browser session for the device code flow, I successfully triggered the MFA, satisfying the Microsoft Entra ID security requirements.

The Road Ahead

My environment is now "Cloud Ready." My next milestone is architecting a Serverless Password Vault, a cloud-native application leveraging Azure Functions, Cosmos DB, and Azure Static Web Apps, while recycling a password generator and storage vault frontend I had built previously for a frontend mentor challenge.

I’ve always welcomed problems during a build. Whether it’s a login failure or a script not producing the desired output, I see these roadblocks as opportunities to sharpen my troubleshooting skills. In a field that evolves as rapidly as the IT ecosystem, a "not-so-simple" fix is just another notch in the belt of an IT professional.

Updates to the Azure Onboarding App

Brian Meinert — Fri, 22 Dec 2023 15:06:40 +0000

Previously, in my last post, I went about creating an automated onboarding app in Azure using the Logic Apps resource. Looking back at the app, I wanted to figure out how to make it more secure, outside of just having an administrator enable the user, so I turned to key vault.

In my first build, the password was hard coded into the application, which as we all know, is a huge security risk and bad practice in the industry. Enter Azure Key Vault, a cloud service that is used to securely store and access secrets, such as our new user password. Once the key vault is created and our password securely stored, I granted permissions to the logic app to access and use the stored secret, which I will be taking you through the steps to integrate key vault into your own logic apps.

Project Steps

Create key vault.
Create a secret in the key vault.
Activate the system assigned identity of the logic app.
Grant permissions to the logic app.
Add the key vault api connection.
Integrate the secret into the user creation.
Test the new app.

The first thing that needs to be done in this process is to add our key vault resource. There are a few different ways that this can be done, either in the portal, by using the Azure CLI, Azure PowerShell, or by deploying through IaC such as bicep, ARM template, or Terraform. For this step, I created the key vault through PowerShell by running,

New-AzKeyVault -VaultName 'KeyVaultName' -ResourceGroupName 'ResourceGroupName' -Location 'Location' -EnabledForDeployment

Once that key vault was created, the next step is to add the secret to the key vault, which is our password, that will be used for our new users. To create the secret, this can also be done in the portal, or over the Azure CLI, or Azure PowerShell. To accomplish this task, I once again used PowerShell by running the command to create a new key vault secret.

$Secret = ConvertTo-SecureString -String 'Password' -AsPlainText -Force Set-AzKeyVaultSecret -VaultName 'KeyVaultName' -Name 'SecretName' -SecretValue $Secret

With the key vault created and secret added to the vault, we now need to grant permissions to the app to use our secret using least privilege access. The first step in doing this was to enable the system managed identity of the logic app. To do this step I hopped into the portal and went into the logic app. Once inside of the logic app, on the left hand side under the settings menu, open the identity option, and change the status from off to on.

Now that the logic app has an identity, we can grant it access to the key vault using RBAC with least privileges. To use least privilege, we need to first understand what we need the logic app to do, which in our case, is to be able to read secrets in the key vault and use the secrets. With that noted, I went ahead and assigned the key vault secrets user role to the onboarding app.

With the key vault set up and permissions to the logic app granted, the next step is to connect the key vault api connection to the logic app workflow. Since we need the password secret from the key vault before we create the user, we'll insert the get secret connection between the HTTP request trigger and create user connection. With that in place, we'll go ahead and select our secret that we created for the new user password.

Since our logic app has now grabbed the secret in the previous step, in the create user connection, password creation, we can input the value from the secret without exposing or hard coding our password.

The final step with our new logic app integration is to test. Again, I used thunder client in VSCode to send the HTTP request to the app, making 2 different accounts and signing in with those accounts to make the password was the one stored in the secrets. With 2 successful runs, the Key vault integration was working as planned.

Key vault should always be your go to for storing your secrets passwords, certificates and any other sensitive information that you may need to use. Azure makes integration of key vault very easy through RBAC with either user accounts or managed identities. It's a great practice to help secure your sensitive data from falling into the wrong hands, that should always be integrated when possible.

Azure Automated Onboarding Project

Brian Meinert — Tue, 31 Oct 2023 22:36:01 +0000

Project Overview

Another week, another Azure project in the books for my portfolio and cloud engineering journey. I'd first like to start by giving a ton of credit to Gwyneth Peña-Siguenza for all of her incredible videos, project ideas, and educational content she puts out. She has been a ton of help to me on my journey through all of this content, and I recommend anyone who's looking to either get into cloud or advance their cloud careers to check out her channel. Now let's get into this project!

The idea of this project is to create an onboarding process for a new member, from an email that is received, or information comes in from a Microsoft list. That info is then taken in by an Azure logic app, creates a new user account in Entra ID, adds them to the proper group with proper permissions and roles, and finally sending an email to the user administrator to review the account and permissions before enabling the account. I did this project a little differently than it was suggested, as I don't have a work or school account, I did not have the proper permissions to trigger the logic app off an email or Microsoft list. Instead, I used an HTTP request that I generated to the app using the VSCode Thunder Client extension.

Project Steps

To get started with this project, the resources you'll need are:

Azure Account (you can get one for free if you don't have one.)
Azure Tennant
VSCode or any other code editor to write some JSON
VSCode Thunder Client
Entra ID Group
Azure Logic App

The first step of this project, once you have an Azure account and tenant said up, is to go in and create a group in your Microsoft Entra ID. For this project, I just created a basic group to add a new user to. If you have an AD p2 license, you can create a dynamic group where you can have people dynamically added based on something like a job role and have a set of specific roles assigned to that group.

Once we have that group created, its time to get into building the logic app.

In the creation, since this isn't going to be a live running app I selected the consumption-based plan instead so I'm only paying for whenever the workflow runs. As soon as the logic app is created, our next step is to hop into the logic designer pane and begin creating our app.

To kick off the app I selected the "When a HTTP request is recieved" trigger. insdie the trigger, it'll ask for a Request Body JSON Schema.
*Note that when you create the trigger your HTTP POST URL will be blank. Do not worry it'll generate the URL when you save the app.

To create the JSON Schema, there are a couple different ways to go about this task. If you know how to write JSON, you can create the file in VSCode or whatever text editor you use. If not, you can use a site such as this free JSON to JSON Schema Converter. You could also just write it out in the body itself. Since I was creating a repository for this project in GitHub to display, I created my JSON Schema in VScode. Once you have your JSON schema written go ahead and add it to the trigger.

Now that we have our trigger completed, the next step I took was to create the actions. for this logic app, I had three actions that were to take place. The first action was to create a user in our Microsoft Entra ID tenant. To fill in the boxes of the create user action, I used dynamic content and concat functions to pull data from the JSON in the HTTP request. Also, for security purposes, I did not enable the newly created account, in case of a chance of a malicious user. The account must first be approved and then enabled by the admin.

Now with the new user created it, I set up another action to add user to a group which I created in my Micorosft Entra ID earlier. Now remember if you have a P2 liscence and dynamic groups, you may not need to do this step based on what the conditions are for your dynamic group (ex. add everyone with Job title containing network administrator) and you have that condition declared and met in the creation of the user. To add the user to the group, there are 2 things you need, the first is the Group ID which you can grab from your Microsoft Entra ID tenant, and the User Id. The User Id, like previously in the Create User, can be dynamically grabbed from the create user action.

With the new user created and added to our specified group, the final step in building the logic app was to add the final action of sending an email to the admin to review and activate the account.

With the logic app completed and saved, it was time to head over to VSCode, open up the thunder client and see everything go into action. with the Post URL copied from the logic app and placed in the thunder client, I then added the JSON body of the required parameters that the app requested, and sent the request.

with the request sent, in the overview section of the logic app, I verified that the run was successful, checked the Entra ID for the new user and also made sure the user was in the group, followed by checking my email to make sure that I got the email to verify and activate the account.

Closing Statements

This was a great mini project to build, and I had a ton of fun creating and learning about logic apps as well. If you are looking for something fun to create and add to your portfolio I highly recommend giving this one a shot! Best of luck on your journey and creations, and as always, thank you for taking the time to give this a read!