Brac POC — bank-payment app

End-to-end payment workflow on OpenShift — designed, built and shipped with the bank's existing pipeline. Single sign-on, canary release, browser-trusted TLS at the edge, mTLS in the cluster, live health view, and standard web hardening — all delivered through GitOps.

Demo asset for the BRAC engagement. A working payment workflow with customer and approver roles, single sign-on, a canary release of the customer page, browser-trusted TLS at the edge, mutual TLS between the internal components, a real-time health view of the backend services, and three of the standard web-hardening controls every audit asks for. Built end-to-end on top of the bank’s existing platform — no new vendor, no new toolchain.

At a glance

What got built

Four pieces in one namespace:

Who logs in

All three users share one demo password: Hkj38djf&&&.

Login is single sign-on through WSO2 — the bank doesn’t manage usernames or passwords inside the app itself.

Technology choices

Every layer of the app uses something the bank’s operations team already runs in production. Nothing exotic, nothing that needs a new vendor relationship to support.

How the app was designed

A small set of decisions, made up front, that the rest of the implementation followed:

How the app is built

A single push to GitLab triggers everything else.

The whole sequence is four to six minutes end-to-end. The build fails closed — a single critical CVE blocks the push to Nexus, which blocks the deployment. No image ever lands on the cluster without having been scanned.

GitOps deployment

The cluster’s state is a rendered copy of two Git repositories. No engineer ever runs oc apply against the running environment.

On the cluster, Argo CD watches both repositories and continuously reconciles their contents onto OpenShift. Two important properties fall out of this:

• Self-healing. If anything drifts from what’s in Git — someone patches a Service directly, a resource gets deleted by mistake — Argo reverts it within seconds.
• Auditable. Every change to the running app is a Git commit, with an author, a timestamp, and a diff. Compliance gets the audit trail for free.

The deployment itself uses two-side reconciliation: the cluster declares it wants the image at digest sha256:abc…, the image already exists in Nexus, OpenShift pulls it, and rolls the deployment. The whole sequence after a Jenkins build is typically under a minute.

Traffic flow — browser to pod

A request from zahid’s browser passes through six named layers before it reaches an application pod:

The public TLS terminates at step 4. From step 5 onward, the in-cluster hop between the proxy and the backend service is also encrypted, using mTLS — see Internal mTLS below.

System view — interactive

Hint: drag any box to rearrange. Click a box to flip its colors (useful for highlighting a path you’re walking through). The lines are live — the animation shows the direction traffic flows.

Reading the diagram:

How a payment moves

1. Zahid logs in on the customer page. Browser is redirected to WSO2, signs in, comes back signed in.
2. He picks a recipient from the dropdown — accounts are listed by name and account number; balances are not exposed across customers.
3. He submits a payment for an amount. Funds are reserved against his balance immediately.
4. Admin logs in on the approver page. The pending queue auto-refreshes every five seconds.
5. Admin clicks Approve. Funds move into the recipient’s balance, the transfer is logged with the admin’s name on the audit trail.
6. Decline would refund the sender. Either decision is one-shot — the app won’t let the same transfer be settled twice.

Canary release of the customer page

Two versions of the customer page run side-by-side. Visitors get the stable v1 unless they explicitly ask for v2.

To show v2 in a demo: install the ModHeader browser extension, add a single rule (Name: X-Canary, Value: v2), reload. Disable the rule to flip back to v1.

The routing decision is visible in the x-served-by response header — open Chrome’s dev tools → Network → click the page request → Headers → Response Headers — to see which version served you.

Internal mTLS

Public traffic to the app uses a browser-trusted Let’s Encrypt certificate; that part is unchanged. The hop inside the cluster between the NGINX reverse proxy and the health-view endpoints on the backend services now uses mutual TLS — both sides authenticate with certificates, both sides verify each other’s certificate against the lab certificate authority.

To prove mTLS is doing its job, two commands from a terminal:

# 1. Without the client cert — handshake rejected
oc -n bank-payment exec deploy/client-frontend-canary-proxy -- \
  curl -k --max-time 5 https://payment-client-svc:9445/health/live
# → SSL_ERROR_ZERO_RETURN

# 2. With the client cert — accepted, returns 200 + JSON
oc -n bank-payment exec deploy/client-frontend-canary-proxy -- \
  curl --cert /etc/nginx-mtls/tls.crt --key /etc/nginx-mtls/tls.key \
       --cacert /etc/nginx-mtls/ca.crt \
       https://payment-client-svc.bank-payment.svc.cluster.local:9445/health/live
# → {"status":"UP",...}

The plain-HTTP port on the backend (9080) stays open for the OpenShift platform’s own probes and for the public-facing API Routes, which are already protected by the bearer token from WSO2.

Egress controls — what the pods can talk to

By default the pods in the bank-payment namespace cannot reach anything outside their own namespace, not even the wider cluster. Every outbound destination is opened by an explicit allow-rule. This limits the blast radius of a compromised pod — a leaked credential can’t be exfiltrated to a public server, the pod can’t pivot into other tenant namespaces, and the only external destination it can reach is the bank’s own identity service.

The full set of NetworkPolicies for this tenant lives in the platform GitOps repository — adding a new outbound destination is a small Git commit, reviewed and audited like everything else.

Observability — two parallel surfaces

Every signal the app emits (traces, metrics, logs) is shipped to two independent observability backends in parallel — the OpenShift-native stack (in the cluster console, owned by the platform team) and SigNoz running on a lab VM (a full observability platform with APM, alerts, SLO tracking).

The split is intentional. The platform team uses OpenShift’s native view because it lives in the same console they already operate the cluster from. App developers and the on-call rotation use SigNoz because it has richer per-endpoint analytics and a side-by-side trace / log / metric view. Both surfaces show the same data — the app pushes once, an in-cluster collector fans out.

Where each signal lands

Tail sampling — kept the interesting traces, dropped the noise

The in-cluster fan-out collector applies tail-based sampling to traces before forwarding to SigNoz. Sampling decisions are made on the complete trace:

Net effect: anomalies survive at full fidelity, normal traffic is ten-times-cheaper to store, and the trace storage bill scales with meaningful traffic instead of raw volume.

Business-aware traces

Spans on the transfer and approve / decline endpoints carry the business context as searchable attributes — not just generic HTTP metadata:

In SigNoz, you can paste a transfer ID into the trace search and find that exact customer payment — including the cross-service hop to the approver, the ledger write, every Liberty handler — in one waterfall.

What SigNoz gives you on top of the data

The OTLP plumbing is the same as for Tempo, but SigNoz adds an APM layer that needs no extra wiring:

Curated dashboard (Perses, in the OpenShift console)

A pre-built Perses dashboard ships alongside the app and renders under Observe → Dashboards → Bank Payment Overview in the console. Three collapsible grids:

The dashboard YAML lives in the same repo as the app; the Cluster Observability Operator’s Perses operator reconciles it into the console.

Quick-glance in-app status page

Independent of the platform tooling and SigNoz, the app also serves a tiny status page at /obs/ directly on the customer hostname. Two cards, one per backend, refreshed every five seconds. Convenient when you want a one-click health check without leaving the app.

This in-app page goes through the mTLS hop described above; the console-side observability and SigNoz go through their own collectors which run in their own namespaces / on the lab VM.

Web hardening at the edge

Three controls applied in front of every request, configured in one NGINX file:

Two additional headers travel alongside HSTS: X-Content-Type-Options: nosniff (browsers can’t misinterpret file types) and Referrer-Policy: strict-origin-when-cross-origin (other sites don’t see internal paths in their referrer logs).

Where everything lives

Roadmap (intentionally not yet built)

• Persistent storage for accounts + transfer history. The demo uses in-memory state; a service restart wipes the ledger. JDBC + PostgreSQL or a PVC-backed JSON snapshot is the obvious next step.
• API Gateway in front of the two services — the gateway definitions are already in the repo, waiting on WSO2 APIM.
• Service mesh for fleet-wide mTLS and a richer canary story beyond a single header rule.
• Audit event stream — every approver decision emitted to Kafka for downstream reconciliation, plus the same event flowing through the OpenTelemetry pipeline for correlation with the trace data.