What your architecture and security review will ask, answered on one page

Your identity provider decides who administers it

Console sign-in through OIDC

Authorization code flow with PKCE, as a confidential client: the browser never holds a token. People are bound by the provider's sub, and their role comes from their groups at every sign-in. QUERYAPIGATE_SSO_ONLY removes personal tokens so nobody routes around your MFA.

A way in when the provider is down

The shared admin key stays an owner for emergencies. Once a named owner exists, every use of it is logged, audited as break_glass_used and alerted. The last active owner can't be locked out by accident.

Off in your IdP, off here

Someone removed from your groups loses their role at the next sign-in; a session already open lasts until it expires (8 hours by default). Deactivating them in QueryAPIGate ends it at once.

Four fixed administrator roles

Every management operation needs one capability, checked before the route runs; a test fails if an operation has no entry, so a new route can't ship unguarded. Roles bound what an administrator can change. For data, the database account behind each connection is still the backstop.

Scoped keys, least privilege by default

Grants per saved query, collection or connection; read-only unless writes are granted; table allow-lists; IP allow-lists; expiry; rotation without downtime; rate limits, quotas and concurrency caps per key.

Tokens from your identity provider

Signed-in users call with a JWT checked against your JWKS. A parameter can be bound from a claim, so a user's tenant_id or email comes from the token, not the request.

Governed like any other caller

MCP clients sign in through OAuth 2.1 or use a scoped key, and see only the saved queries they are granted. A write proposed by an agent waits for a person to approve it, and both are audited.

Who changed what, in a record your SIEM already holds

$ queryapigate audit verify
# checks the chain in the store, naming the first broken entry

$ queryapigate audit verify --file siem-export.log
# checks the copy your SIEM received, on its own:
# exact repeats from at-least-once delivery dropped,
# a repeat that differs reported as conflicting_copies

What the chain can't show on its own: the newest entries deleted, or a rewrite by someone holding both the store and the key. That is why the copy in your SIEM matters. The audit trail in the threat model →

Every change through review, if that's your rule

Locked

QUERYAPIGATE_CONFIG_LOCKED refuses changes made in the Console or the API to anything the file manages.

Drift

Without the lock, a change by hand shows in the next diff, and the next apply undoes it.

No secret in git

A password is a reference (an environment variable, a file, Vault or AWS), never a value, and a file with one in it is refused. Keys are SHA-256 hashes of random secrets, rotated by pull request.

Grow from one container to several without a migration

Three real servers on every CI run

A multi-instance test runs three servers on one store on every change. The reference deployment was run end to end: a key's 4-per-minute limit allowed exactly four calls across all three instances, and with one instance stopped, twelve calls in a row still succeeded.

A signed Helm chart

Stable since 0.30. Non-root, read-only root filesystem, every capability dropped, no service account token, an optional NetworkPolicy and autoscaling. It refuses, before changing anything, a setup that can't work, such as several pods on SQLite.

Every store upgrades itself

Each release upgrades the store on its first start. Several instances on one store are replaced one at a time with no downtime, checked in CI against the previous release. Patch releases never break a covered surface; minor releases say so under Breaking.

Backup and restore

Everything QueryAPIGate owns, from connections and saved queries to keys, roles, history and the audit log, lives in its store. Back it up while it serves; restore one now and then, because a backup nobody has restored is not a backup.

Kept out of a backup on purpose: QUERYAPIGATE_SECRET_KEY, which encrypts connection passwords, the admin key, and any environment variable a connection refers to. Keep them in your secrets manager. Scoped keys are in the store as hashes, so they keep working after a restore.

# SQLite: a consistent copy while the server keeps running
$ queryapigate backup /data/backup.db --force

# PostgreSQL: one snapshot, safe while serving
$ pg_dump --format=custom --schema=public --no-owner --no-privileges \
    --file="queryapigate-$(date +%F).dump" "$QUERYAPIGATE_DATABASE_URL"

Approved algorithms, and releases you can verify before they run

FIPS 140-3

Validation is a property of the cryptographic module, not of the application. QueryAPIGate uses only FIPS-approved algorithms (FIPS 140-3, SP 800-131A); run it on a validated OpenSSL in FIPS mode, such as Red Hat Enterprise Linux 9 with fips=1 or Ubuntu Pro FIPS, with Python's cryptography from the distribution, and the cryptography it uses is validated.

Signed releases, SBOM and provenance

The image and the Helm chart are signed keyless with cosign by the release workflow, by digest. Each platform carries an SPDX 2.3 SBOM and SLSA provenance naming the repository, workflow, commit and run. Every GitHub Action is pinned by commit and the base images by digest.

$ cosign verify ghcr.io/anantharajuc/queryapigate:{{ entVer }} \
    --certificate-identity https://github.com/AnanthaRajuC/QueryAPIGate/.github/workflows/docker.yml@refs/tags/v{{ entVer }} \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com

$ docker buildx imagetools inspect ghcr.io/anantharajuc/queryapigate:{{ entVer }} --format '{{json .SBOM}}'

Admit only signed releases to a cluster with Sigstore's policy-controller or Kyverno; both policies are in the guide, tested against signed, unsigned and wrongly signed images.

The project's own security practices are scored by OpenSSF Scorecard, an independent automated check from the Open Source Security Foundation. It runs on every change to the main branch and once a week, and the badge below always shows the latest score.

Everything a vendor-risk review asks for, in one download

Where data goes

Every table QueryAPIGate keeps, what personal data it holds, for how long and who reads it, on one page. A test fails if a table is missing from it.

Erasure

queryapigate history forget erases a person's runs, events and usage counts, recorded in the audit log by a hash of who, not their name.

What it does, what stays yours, and what we don't claim

No SOC 2 or ISO 27001 report

Those certify an organisation running a service. QueryAPIGate runs inside yours, under your controls; what it provides is the evidence your own assessment needs.

Experimental features are labelled

Today: H2, generic JDBC and MongoDB connections, OpenTelemetry tracing, and secrets and credentials from AWS. They sit outside the compatibility promise until they graduate.

Reporting a vulnerability

Please don't open a public issue. Use GitHub's private advisory form or email arcswdev@gmail.com. Fixes are published as Security entries in the changelog, with how to check whether you were affected.