Data Residency & Key Custody
How Cybros keeps regulated data in-region and under customer key custody. Two independent controls: where the data sits (residency) and who holds the key (CMEK). On-prem combines both and closes the boundary entirely.
DATA_RESIDENCY
-
Config:
data_residency(envDATA_RESIDENCY), values like"us","eu","in". -
Advertised (secret-free) at
GET /api/v1/system/deployment:{ "mode": "private", "data_residency": "eu", "features": { "cmek": true } } -
It is a region tag, not a mover. Residency is achieved by deploying the stack (pods + Postgres + Redis) into that region; the tag records and advertises the promise so the UI can badge it and audits can assert it. Pin your managed RDS/ElastiCache and cluster to the region, then set
DATA_RESIDENCYto match.
Where state lives (all region-pinned):
| Data | Store | In-region? |
|---|---|---|
| Findings, projects, orgs, audit hash-chain, credit ledger | Postgres | Yes — RDS/PG in-region |
| Encrypted integration secrets | Postgres (envelope-encrypted) | Yes |
| Queues / rate-limit / cache | Redis | Yes — in-region |
| Object/report blobs (if any) | Postgres / in-region bucket | Yes |
CMEK (Customer-Managed Encryption Keys)
Cybros uses envelope encryption: stored secrets are sealed with
SECRET_ENCRYPTION_KEY (AES-256-GCM, 32 bytes). CMEK means that key is owned by
you, held in your KMS, and never persisted by Cybros in plaintext.
- Enable via
cmek.enabled=true,cmek.provider(aws-kms/gcp-kms/azure-kv/vault),cmek.keyId(KMS ARN/URI). Theprovider/keyIdare surfaced in the ConfigMap for audit; the key material itself is delivered via an ExternalSecret unwrapped from your KMS — it is never rendered into the chart. - Advertised as
features.cmek: trueon/system/deployment. - Revocation = kill switch. Disable/rotate the KMS key in your account and Cybros can no longer decrypt stored secrets. You hold the off switch.
- Region-pin the KMS key to the same region as the data for residency alignment.
What crosses the boundary
| Topology | Leaves the region/boundary |
|---|---|
| On-Prem | Nothing by default. AI + payments are offline stubs, no telemetry. Only opt-in GitHub/IdP/KMS egress if you enable them. |
| VPC / Private | Nothing except the integrations you explicitly enable (GitHub, IdP, KMS, payments), each pinned in-region where possible. |
| SaaS | Data resides in the SaaS region; residency is HackTiger-operated. |
There is no phone-home / telemetry in the codebase. Egress is opt-in per
integration and enforced at the network layer (see docs/vpc-deployment.md).
Compliance summary
- Deploy the full stack (pods + managed DB/cache + KMS key) into the target region.
- Set
DATA_RESIDENCYto that region so it is advertised and auditable. - Enable CMEK so encryption keys stay in your custody and revocation is yours.
- For strict sovereignty, choose On-Prem — the boundary is your network and nothing leaves it unless you open a specific egress path.