Add Authentication to BCG (Broadcast Gateway Service)
Version Control
| Version | Date | Who | What |
|---|---|---|---|
| 0.1 | 5 Nov 2025 | Saji Varghese | Draft |
Document Overview
| Decision required | How to secure BCG /send operation |
|---|---|
| Decision Outcome | |
| Owner | Saji Varghese |
| Current Status | Draft |
| Decider(s) |
Context
-
BCG dispatches customer messages on-site. There is no authentication/authorisation, so any caller can invoke
POST /send. -
Clients are internal services running in heterogeneous environments (inside/outside Kubernetes).
-
The organisation already uses App Key for service-to-service auth.
Decision Driver
-
Security posture: Remove critical vulnerability; prevent spoofing/abuse.
-
Org standards: Reuse existing App Key issuance and governance.
-
Heterogeneous clients: Must work across clusters and private cloud (i2).
-
Low integration cost: Minimal client change; fast rollout.
-
Auditability & ops: Attribute every request; clear deny logs/metrics.
Considered Options
-
Option 1 - Per-service App Key at BCG (header-based, scoped).
-
Option 2 - Network/IP allow-listing only.
Decision
We will use Option 1
Consequences
Positive
-
Closes unauthenticated entry point; strong caller attribution.
-
Works across environments; minimal client changes.
-
Simple incident response via key revocation; good audit trails
-
In future, could extend to use App Key for authorisation
Negative / Risks
-
Secret distribution and rotation overhead for clients.
-
New dependency on key-verification path (requires cache/fallback).
-
Scope taxonomy and governance needed.
