Skip to content

Security posture

This page is the answer to "what does BCDock do for security?" - designed for partner-questionnaire and enterprise-procurement audiences. It describes what's shipped today, not what's planned. Honest scope: BCDock is a sandbox platform; the controls described here are the ones we've built into the architecture, not certified by an external auditor.

For the formal compliance scope (what BC SaaS gives you that we don't), see reference/limitations § Compliance scope.

Shipped controls

Tenant isolation

Every database query in the Platform API carries a company-scoped filter set from the authenticated company context. The filter applies automatically at the data-access layer to every query - there is no per-query opt-out path within normal API code paths. Cross-company data access from a customer-scoped credential is therefore not possible.

Staff-level cross-tenant operations exist for support purposes but are not reachable from customer-facing API keys or the public CLI.

Per-region Key Vaults

Secrets live in Azure Key Vault, partitioned by what scope they have:

  • Core KV (australiaeast - Sydney, per ADR-018) - secrets that are the same everywhere (the wildcard TLS certificate covering *.bcdock.io subdomains). All pools fetch from here.
  • Regional KV (one per region BCDock provisions in) - region-scoped secrets: per-environment BC admin passwords, pool SSH keys, etc.

Soft-delete is enabled on all KVs (90-day recovery window). RBAC is auto-assigned at provisioning time - each pool has just enough access to fetch the secrets it needs.

Container-side admin passwords

Each BC environment has a unique Administrator account password, generated at provisioning time, stored in the regional Key Vault. The password is never logged, never written to file, and is fetched on demand by the pool agent when starting the container.

The admin password (and the separate Web Service Access Key for OData/SOAP) is surfaced to the customer through the portal env get view and through bcdock env get -o json. The customer can rotate the password through the BC interface; the platform doesn't auto-rotate.

Authentication

Portal (browser sessions) - httpOnly cookies. Two cookies per signed-in user:

  • bcdock_token - 15-minute access token
  • bcdock_refresh_token - 7-day refresh token

Both are httpOnly + SameSite=Lax; the Secure flag is set when the portal runs in production (NODE_ENV=production) so cookies only travel over HTTPS, and is omitted on the local dev stack which runs on plain HTTP. JavaScript on the page cannot read them. Server actions running in the Next.js layer attach the cookies to API calls; client components hit server actions, never the API directly. This is documented in the project's authentication pattern guide.

CLI / API / agents - long-lived API keys (bdk_…) with explicit scopes. See API keys.

OTP exchange (the email-based login flow) is rate-limited at the API layer. Codes are short-lived single-use; the code itself is hashed in storage.

Network surface

Every BCDock environment is reached via HTTPS at https://<env-name>-<shortId>.bcdock.io/BC/, with TLS terminated at Traefik on the pool VM. The wildcard TLS certificate (*.bcdock.io) is issued via the DNS-01 challenge using Azure DNS as the provider - covers all environment subdomains in a single cert.

The pool's API surface (used by the Platform API to talk to the pool agent) sits at https://<pool-host>/pool-agent, fronted by Traefik with the wildcard TLS cert, and authenticated by a per-pool shared-secret token. The token is generated at pool-deploy time, persisted in the regional Key Vault for the agent and on the platform side for the caller, and never logged. Customers don't talk to the pool agent directly.

Immutable provisioning logs

Every stage of every provision / hibernate / resume / delete operation writes a structured log line into the platform-managed audit trail. Append-only - there is no API surface to edit or delete log lines. Used for support investigations and post-mortems.

Critically, the provisioning telemetry is excluded from the customer data export - it's operational telemetry tied to environment IDs, not personal data. This is a deliberate scope decision documented in ADR-015 and data-handling.

Storage soft-delete

Hibernation backup blobs (the snapshot of an environment's state when hibernated) live in per-region Azure Storage with soft-delete enabled (7-day recovery window). After deletion, the blob enters the soft-delete state and can be recovered for 7 days; after that it's hard-purged.

This protects against accidental deletion of a customer environment - operator can restore within the 7-day window. Beyond that, the data is not recoverable by anyone.

What's not claimed

We are deliberate about the boundary between "in the architecture" (what this page describes) and "audited by a third party" (what enterprise procurement teams want). We don't claim:

  • SOC 2 / ISO 27001 for the BCDock platform. Azure (the underlying cloud) carries these certifications; BCDock at the platform level is best-effort. Pursuing certification is a Phase D milestone tied to ≥1 enterprise contract that justifies the audit cost.
  • HIPAA / PCI scope for sandbox containers. They're not in scope for regulated-data regimes. Use synthetic or anonymised data.
  • Penetration testing reports. No formal pen-test on BCDock itself yet. Internal review and standard hardening (Key Vault, RBAC, company-scoped query isolation, parameterised queries) is what's shipped.

If you need any of these, talk to us - we can timeline them against your engagement.

How to report a security issue

See security/disclosure for the coordinated disclosure policy, contact email, and scope.