Use Cases

OpenLBAC enforces label-based access control at the proxy layer — no changes to Prometheus, Loki, or Grafana required. Below are the most common patterns, each with concrete policy configuration, query rewrite examples, and deployment guidance.

Choose your scenario

Multi-Tenant SaaS — Namespace Isolation

Multiple customers or product teams share a single Prometheus and Loki cluster. Each tenant is scoped to their own namespace label. A malicious user who manually injects another namespace into their query gets back no data.

Key labels: namespaceDatasources: Prometheus, Loki

---

Team-Based Service Isolation

Engineering teams (payments, identity, marketing) can only query data tagged with their own team label. SREs have unrestricted access. Contractors get a further env != prod restriction on top.

Key labels: team, envDatasources: Prometheus, Loki

---

Environment Access Tiers

Developers see dev and staging. SREs see all environments. Contractors see staging only. Executives get a prod-only view scoped to aggregate job names. Production business metrics never leak to lower-trust roles.

Key labels: env, jobDatasources: Prometheus, Loki

---

Compliance & Sensitive Log Isolation

Log streams are classified with a sensitivity label at ingest (public, internal, confidential, restricted). General engineers see only non-sensitive logs. Payment and security teams see their own restricted streams. Compliance auditors have full access with a complete audit trail for PCI DSS, HIPAA, and GDPR evidence.

Key labels: sensitivity, teamDatasources: Loki Compliance: PCI DSS req. 7 & 10, GDPR data minimisation, SOC 2 CC6

---

On-Call Blast Radius Scoping

L1 on-call engineers are scoped to their own service. L2 can see all services except sensitive security operations. L3 SREs have full access. A break-glass group allows temporary unrestricted access during P0 incidents, with every query logged and alerted on.

Key labels: teamDatasources: Prometheus, Loki Pattern: tiered access, break-glass, audit trail

Common label conventions

These use cases assume your Prometheus metrics and Loki log streams carry consistent labels. The table below shows the recommended label set:

Label	Example values	Applied to
namespace	tenant-a, payments, platform	Kubernetes namespace or logical tenant
team	payments, identity, sre	Owning team
env	dev, staging, prod	Deployment environment
region	eu-west-1, us-east-1	Cloud region
sensitivity	public, internal, restricted	Data classification tier

All five labels can be combined. A policy like:

{
  "rules": [
    {"label": "team",        "operator": "=",  "values": ["payments"]},
    {"label": "env",         "operator": "!=", "values": ["dev"]},
    {"label": "sensitivity", "operator": "!=", "values": ["restricted"]}
  ]
}

...enforces all three dimensions simultaneously — team=payments AND env!=dev AND sensitivity!=restricted.

Mix and match

These patterns compose. A real organisation typically deploys several simultaneously:

• Namespace isolation for multi-tenancy (customer boundary)
• Team isolation within a tenant (internal boundary)
• Environment tiers for all groups (prod protection)
• Sensitivity classification on top for compliance (regulatory boundary)

OpenLBAC applies all active rules as a single AND'd query injection, regardless of how many dimensions you use.