Building a Secure Configuration Update Pipeline with Vault, Lambda, and Kubernetes

Problem

Applications on Harel's insurance processing platform needed a controlled way to update live configuration and settings without a full manual deploy each time. The update path this required crossed several infrastructure boundaries in a single flow: an application UI, secret and configuration data held in HashiCorp Vault, a serverless execution step in AWS Lambda, application configuration stored in a Kubernetes ConfigMap, and a deployment pipeline that had to rerun for the change to actually reach the running application. The challenge wasn't any one of those pieces individually, it was making the full, already-defined flow work correctly end to end.

Context

The flow this dashboard needed to implement, UI-driven update through Vault, Lambda, a ConfigMap, and a pipeline rerun, was the defined requirement handed to me, not an architecture I set out to design from scratch. I built the React + Node.js configuration dashboard and the flow behind it as part of Harel's insurance processing systems work.

Constraints

• The update had to go through Vault for secrets and configuration, Lambda for execution, a Kubernetes ConfigMap for the target configuration state, and a pipeline rerun to reach the running application, in that order.
• The overall shape of the flow was externally defined; the goal was to deliver it correctly, not to redesign it.
• The dashboard had to give non-developers a safe, controlled way to change live settings without a manual deploy.

My Role

I built the React + Node.js configuration dashboard and the flow behind it end to end: from the UI through the Vault secret load, the Lambda step, the ConfigMap update, and the pipeline rerun. The overall shape of the flow was the defined requirement I was building against, not an architecture I chose independently.

Architecture / Approach

1. A user operates the React/Node configuration dashboard to change an application setting.
2. The relevant secret or configuration data is loaded through HashiCorp Vault.
3. An AWS Lambda function performs the required execution step against that data.
4. The target Kubernetes ConfigMap is updated with the new configuration.
5. The pipeline is rerun so the updated configuration reaches the live application environment.

Key Decisions

• Following the required flow order exactly, end to end. The UI-to-Vault-to-Lambda-to-ConfigMap-to-pipeline-rerun sequence was the given requirement, not a choice among alternatives; implementing every stage of it, rather than shortcutting any one boundary, was what made the delivery correct.
• Treating the pipeline rerun as the deployment mechanism, not a live patch. Delivering the change through a rerun of the existing pipeline, as required, meant the update reached the application through the platform's standard deployment path instead of a workaround.
• Keeping the dashboard scoped to triggering the flow, not owning it. The dashboard's job was to trigger the required Vault-to-Lambda-to-ConfigMap sequence reliably, not to take on responsibilities, like secret storage or cluster access, that belonged to Vault, Lambda, and Kubernetes themselves.

Trade-offs

The UI-to-Vault-to-Lambda-to-ConfigMap-to-pipeline-rerun shape of this flow was the defined requirement, not the architecture I would have chosen on a blank slate. The goal was reliable delivery within that constraint, wiring each boundary correctly and making the end-to-end flow work, rather than redesigning the overall approach.

Impact

The dashboard enabled secure, live configuration updates for insurance processing applications running on Kubernetes, delivering the required configuration flow, UI through Vault, Lambda, ConfigMap, and pipeline rerun, reliably.

Lessons

This was an important early step into deeper cloud and DevOps work, beyond application code. It reinforced that application engineers often need to understand the infrastructure path a change travels through end to end, not just the part of it that runs in their own service. Delivering reliably within a defined, multi-boundary flow is a different skill than designing an ideal system from a blank slate, and this project was where I built that skill.