Security self-assessment

This follows the structure of the CNCF TAG Security self-assessment template. It describes only what exists in this repository today; where something is missing it says so and the item is collected in Gaps. It does not repeat the attacker analysis: that is the threat model, which is linked wherever it applies.

Status: draft by the maintainer, not reviewed by anyone outside the project. No external audit, penetration test or TAG Security review has taken place.

Metadata#

Overview#

Querdian is a Kubernetes-native reverse proxy that sits between users (typically Grafana with OAuth pass-through) and Prometheus/Thanos, Loki and Tempo. It authenticates a bearer token with OIDC, resolves the user’s groups to policies expressed as Kubernetes CRDs, rewrites every query so that it can only match data the policies allow, and forwards it. It is default deny and fails closed.

Background#

Prometheus, Loki and Tempo have no per-user authorisation on labels. Multi-tenancy in Loki and Tempo (and Mimir) is by tenant header only, with no finer granularity. Teams that share a backend therefore either run one stack per team or put a filtering layer in front. Querdian is such a layer. Architecture and request lifecycle are in PLAN.md section 3 (the plan is a design document; where code and plan differ, the docs under docs/ describe the code).

Actors#

• Querdian proxy (this project): one Deployment, usually two replicas, a single binary that contains the proxy, a management server and the policy controller.
• Identity provider (OIDC issuer): issues the tokens; trusted absolutely for username and groups claims.
• Kubernetes API server: source of the policies (ClusterAccessPolicy, AccessPolicy) and namespace labels; trusted.
• Backends (Prometheus/Thanos, Loki, Tempo): trusted, but must not be reachable by clients except through Querdian (NetworkPolicy support exists in the chart).
• Users: authenticated, possibly hostile within their authorisation (the main adversary).
• Platform admins / namespace admins: create policies. A namespace admin can write AccessPolicy in their namespace only; the implicit namespace matcher cannot be removed.
• Collection pipeline (Prometheus scrape config, OTel Collector, Alloy/Promtail): must write the namespace label from trusted metadata. This is outside Querdian’s control and the single most important assumption (threat model, section 1).

Diagram and trust boundary: threat model, section 2.

Actions#

1. A user (Grafana) sends GET/POST with Authorization: Bearer <JWT>.
2. Route lookup (default deny), authentication (OIDC), policy resolution (exact union of the policies matched by user or group), request normalisation (parameter allow-list, canonical paths).
3. The enforcer builds a plan: inject matchers (single term), or-lift (PromQL/LogQL metric queries) or fan out and merge (LogQL logs, metadata endpoints, tail).
4. The proxy executes the plan with the tenant header set from the policy only; responses are streamed or merged and, for some endpoints, filtered or redacted.
5. Every response carries X-Trace-Id; decisions are counted in metrics and recorded on the trace.

Goals#

• Isolation: a user can read exactly the union of what their matching policies grant, on PromQL, LogQL and TraceQL read paths, including metadata endpoints.
• Fail closed: errors in authentication, resolution, parsing, rewriting or merging produce a rejection, never an unenforced pass-through. If the exact union cannot be expressed, reject.
• Queries are rewritten with parsers, never with regular expressions or string surgery.
• Clients cannot choose a tenant: tenant and credential headers are stripped and set by Querdian.
• Traceable decisions without logging personal data by default.
• Supply-chain hygiene: license allowlist, DCO, pinned CI actions and base image, signed release artefacts (once released).

Non-goals#

• Write and ingest paths, ruler, alerting and admin APIs: all denied.
• A UI; running outside Kubernetes; gRPC and streaming APIs.
• Protecting data from an authenticated user who is entitled to see it, from a compromised identity provider or Kubernetes API, or from a workload that can forge the namespace label in the telemetry.
• Authentication of backends, TLS termination, rate limiting, token revocation and DDoS protection (these belong to the ingress, mesh, identity provider and the backends).
• Redacting denied labels from query results (labels.deny hides and blocks, see limitations).
• Compatibility with evoila/janus: credited as inspiration only; no code, tests or docs were copied.

Self-assessment use#

This document is a self-assessment by the maintainer to help potential adopters and reviewers (TAG Security, CNCF TOC, OpenSSF) judge the project. It is not a security audit, not a certification and not a guarantee. A reviewer should read it together with the threat model and the limitations; the limitations are the part most likely to matter in practice.

Security functions and features#

Critical#

These are the components whose failure breaks isolation. Each is covered by unit tests, most by fuzzing and by differential tests against real backends.

Evidence of end-to-end behaviour: test/e2e/{prometheus,loki,tempo} run real Prometheus, Loki and Tempo containers (make e2e): isolation across namespaces and tenants, semantic equivalence of the rewritten query with the union of per-term queries, and differential tests (a query the backend accepts is either enforced or rejected, and every rewrite is accepted by the backend). These suites found and led to fixes for real defects before release, listed under Known issues over time. They are not part of the CI workflows (see gaps).

Security relevant#

Not security relevant#

Policy status conditions (informational; enforcement uses the snapshot), dashboard JSON, the quickstart (demo-only credentials), documentation tooling, Grafana panels.

Project compliance#

• No compliance certification (SOC 2, ISO 27001, FIPS, PCI) or regulatory assessment is claimed. Querdian implements no cryptography of its own: JWT verification uses go-oidc, TLS to the issuer uses Go’s crypto/tls with a TLS 1.2 minimum. It does not terminate TLS.
• Licensing: Apache-2.0; every dependency must be Apache-2.0 or on the CNCF allowlist, enforced in CI (licenses job). Source files carry no per-file license header (only generated code uses the boilerplate in hack/boilerplate.go.txt); the root LICENSE applies.
• Provenance: DCO sign-off is required and checked on pull requests. Clean-room rules for the LogQL and TraceQL parsers are in CONTRIBUTING.md; the documentation used is recorded in pkg/logql/doc.go, pkg/traceql/doc.go and docs/research/. The rules are self-enforced; nothing but the maintainer’s care verifies them.
• OpenSSF Best Practices: not registered; see the checklist.

Secure development practices#

Development pipeline#

• Contributions: pull requests from branches (t<id>-<slug>), conventional commits, git commit -s. GOVERNANCE.md requires approval by a maintainer other than the author; with one maintainer this is not enforceable (gap). Branch protection / rulesets are a HUMAN task and are not verifiable from the repository.
• CI (.github/workflows): lint (golangci-lint with gosec, errorlint, revive, misspell, unconvert), test-race, envtest (controller tests against a real API server), fuzz (30 s per target), govulncheck, licenses, generate (drift check), dco, codeql (go), Scorecard. Workflows run with minimal permissions: and all actions are pinned by SHA.
• Not in CI: make e2e (differential and equivalence suites), make chart-lint, make release-check, coverage measurement, long-running or nightly fuzzing. They are run by hand.
• Dependencies: Renovate configuration (Go modules, actions, test images, GoReleaser); unverified until the Renovate app is installed.
• Build and release: reproducible-leaning flags (-trimpath, CGO_ENABLED=0); the image is built from the same binaries as the archives; distroless base pinned by digest; release workflow with cosign keyless, SBOM and attestations (releasing.md). Never run.
• Design practice: a written plan with ground rules (fail closed, no silent over-grant, clean room) preceded the code; the threat model describes the implementation and lists residual risks; security-relevant findings from the E2E suites were fixed and recorded in the limitations.
• Review: a single maintainer wrote and reviewed the code. There was no independent security review (gap).

Communication channels#

• Internal / project: GitHub issues and pull requests are the only channel. There is no chat, mailing list or forum, no community meeting, no public roadmap other than ROADMAP.md.
• Inbound: issues for bugs; GitHub private vulnerability reporting for security problems (SECURITY.md), once enabled by the maintainer (HUMAN item H2).
• Outbound: GitHub releases and the changelog. No security mailing list or announcement channel exists. Code of Conduct reports go to the (single) maintainer.

Ecosystem#

• Runs in Kubernetes in front of Prometheus and Thanos (CNCF projects), Loki, Tempo and Mimir (Grafana Labs projects). Integrates with any OIDC provider (tested with Keycloak in the quickstart), Grafana’s OAuth pass-through, OpenTelemetry for tracing, Prometheus for metrics, Helm for packaging.
• Depends on prometheus/prometheus (PromQL parser), coreos/go-oidc, controller-runtime and OpenTelemetry. pkg/tempopb is the only Tempo import and Loki’s code is not used (clean room).
• No known adopters (ADOPTERS.md is empty). Not on the CNCF landscape.

Security issue resolution#

Responsible disclosure process#

SECURITY.md: report privately through GitHub security advisories; the maintainers aim to acknowledge within 3 working days and agree a disclosure timeline with the reporter. What exists, honestly: a stated contact route and an acknowledgement target. What does not exist: a defined embargo and coordinated-disclosure policy with durations, severity classification, a security team or backup contact, a PGP key, a list of supported release lines (SECURITY.md says only the latest main is supported; this must be updated at release), and CVE assignment practice (GitHub advisories can request CVEs). Private vulnerability reporting must be switched on in the repository settings for the link to work (H2). No report has ever been received.

Incident response#

There is no written incident response procedure. The intended course, derived from the tooling that exists, is: reproduce in the E2E framework (test/e2e/framework), fix in a private advisory fork, release a patch version via releasing.md, publish a GitHub security advisory and amend the changelog. Because Querdian fails closed and has no persistent state, mitigation for operators is usually to delete the affected policies or to scale the proxy down. This is a description of intent, untested.

Appendix#

Known issues over time#

No vulnerability has been reported against a release (there is no release). The defects below were found by the project’s own differential and end-to-end testing during development, before the first release; they are listed because they show the class of risk the proxy carries. Commit hashes refer to this repository.

Residual and known risks that remain are enumerated in threat model, section 12 and the Loki findings in limitations (“Findings from the end-to-end suite”).

OpenSSF Best Practices#

Not registered yet. The criterion-by-criterion state and the exact HUMAN steps are in openssf-best-practices.md: 41 of 67 criteria Met on the repository evidence, 15 Unmet (most depend on making the repository public, enabling private vulnerability reporting and cutting a release), 11 N/A. Scorecard runs weekly once the repository is public; no score is claimed.

Case studies#

None. There are no adopters. The only deployment evidence is the kind quickstart (quickstart.md): a demo with two teams and verify.sh (71 assertions), and the chart verification script hack/kind/verify-chart.sh. Placeholder: add adopter case studies here when they exist, with their permission.

Related projects#

An honest comparison. Descriptions of other projects are from public documentation as the maintainer understands it and should be re-checked; they change.

Gaps collected#

Everything this document found missing, so a reviewer does not have to hunt for it.

Project and governance

• One maintainer. GOVERNANCE.md’s “approved by a maintainer other than the author” cannot be met or technically enforced; a majority vote of one is not governance. Code of Conduct and security reports go to the same person.
• No adopters, no case studies, no contributors from other organizations, no public community channel or meeting.
• No issue or pull request templates, no CODEOWNERS; CONTRIBUTING.md has no bug-reporting guidance and does not state the test requirement (it lives in TASKS.md).
• Name and domain check (T0.0) is a HUMAN task and unticked: trademark search, querdian.dev registration. The GitHub org and repository settings (2FA, ruleset, Actions policy) cannot be verified from the repository.
• No per-file license headers in the source (Apache-2.0 does not require them).
• No project website; docs live in the repository.

Security process

• SECURITY.md: no embargo/disclosure durations, no supported-versions policy beyond main, no PGP key.
• No written incident response plan; no external audit, penetration test or threat-model review.
• No VEX or security advisories yet (none needed so far).

Engineering

• make e2e, make chart-lint and make release-check are not part of CI; PLAN section 13’s nightly long fuzz and full E2E do not exist. Fuzz in CI is 30 seconds per target; no OSS-Fuzz; no committed fuzz corpora.
• No coverage measurement.
• The release pipeline (signing, SBOM, attestations, multi-arch image, OCI chart) has never run; T5.2’s acceptance items are unticked. The chart is signed but not attested.
• Product limitations with security relevance: no rate limiting, unauthenticated management port, no TLS termination, tokens valid until expiry, namespace-label integrity is the operator’s responsibility, clean-room parsers may diverge from the backends in unexplored corners, eventually consistent revocation (threat model, section 12).
• Tested only against the backend versions in the E2E suites; Thanos and Mimir federation are not tested end to end.