Encryption in Transit and at Rest

Encryption is easy to claim broadly and hard to state precisely. This page does the precise version. It names which connections carry TLS, which stored data is encrypted and by what mechanism, and where the at-rest story ends. The section on what it does not cover is the one a reviewer should read closely, because the honest scope is narrower than a blanket claim would suggest.

In transit

Public traffic. Connections from your browser or an API client to {slug}.parascope.io terminate at Cloudflare over TLS. A current browser or client negotiates TLS 1.3. The edge also accepts TLS 1.2, so older clients can still reach the product, which means "TLS 1.3 only" is not a claim this page makes. The onward connection from Cloudflare to the platform's own gateway runs over TLS using a Let's Encrypt wildcard certificate that cert-manager issues and renews inside the cluster.

PostgreSQL. Database traffic inside the cluster carries TLS on three segments:

• Application pods to the connection pooler.
• The connection pooler to the database.
• The database primary to its replicas, for WAL streaming.

Certificates on those segments are issued by an internal certificate authority that cert-manager operates in the platform namespace and renews without operator action. It is separate from the public certificate authority used for *.parascope.io, because internal services have no reason to hold publicly trusted certificates. Clients connect with sslmode=verify-ca, so each verifies the server certificate against that internal CA, and both the database and the pooler are configured to reject plaintext connections.

This is server-side TLS. There is no client certificate requirement, and database authentication remains SCRAM-SHA-256. Calling it mutual TLS would overstate what is deployed.

The on-premises appliance. An appliance opens an outbound TLS connection to ingest.parascope.io:7422 and accepts no inbound connection from Parascope, so no inbound firewall rule is needed for it. Collected data travels out and management requests come back on that same connection. Tenant Isolation Architecture covers its direction and the scope of the credential it uses.

One internal segment is worth naming outright. Messaging between the platform's own pods and the message broker runs on the pod network without TLS on the internal client port; the appliance-facing port is the one that carries TLS. What separates tenants on that path is the cryptographic account boundary the broker enforces and the deny-by-default network policy applied to each tenant namespace, both described in Tenant Isolation Architecture.

What is encrypted at rest

Each row names its own mechanism. They differ because the systems they protect differ.

Key handling sits alongside that. For the backup key and the etcd keys, the documented procedure is annual manual rotation, and an offline copy of each is kept outside the cluster so that losing the cluster does not also lose the ability to read its backups. The appliance escrow copy, which is what lets an appliance boot unattended, is wrapped under a separate key-encryption key before it is stored in the control-plane database.

The day-to-day handling of source credentials, including the reveal grant and the audit entry each read writes, is in Data Handling and Retention.

What at-rest encryption here does not cover

Four limits and one disclosure.

Parascope manages no disk-layer encryption on the database volumes. Protection at the physical-disk layer is the hosting provider's responsibility. Customer-managed LUKS on those volumes was considered during the design and left out, on the grounds that holding our own key at that layer would add operational weight without changing any of the threats the table above addresses. If a customer-held key at the disk layer is a requirement for you, it is a conversation to have at hello@parascope.io before you buy, because it does not exist today.

There is no column-level encryption in the tenant database. Your configuration items and their change history sit in ordinary columns, readable by the application role that serves your API. That is what makes them queryable. Application-level column encryption was weighed in the same design and left out, because it breaks indexing on the fields the product searches.

Two files on an appliance stay outside the credential vault. The vault covers what you configure, and the section above says so precisely: collector credentials and any SSH private key you supply. Two files cannot join it, because something reads them before any key is available. The appliance's message-broker credential, at /etc/parascope/nats/leaf.creds, is bind-mounted into the broker container at boot; the appliance's own configuration file, /etc/parascope/appliance.conf, holds no credential but names your tenant. Both are mode 0600 and owned by the appliance agent's service account, so only that account and root can read them. The broker credential is one Parascope issues and scopes to your tenant; it is not a credential into a system of yours. Separately, if encryption fails to initialize while an appliance pairs, the appliance logs that failure and stores collector credentials unencrypted until encryption is set up. The check in the next section is what shows you whether you are in that state.

Encryption at rest does not defend against live access. Every mechanism above protects data that has left the running system: a stolen disk, or a backup object leaked out of storage. None of it stops someone who already holds live access to the running platform, because the services have to decrypt in order to work. The same applies on an appliance, where an attacker with root on a running VM can read the decrypted copies in tmpfs. Live access is what Access Control and Authentication addresses.

One more disclosure belongs in this section. Parascope holds an escrowed copy of the appliance encryption key, which is what lets an appliance start without someone typing a passphrase at every boot. The consequence is that Parascope is technically able to decrypt appliance-stored credentials given the appliance's disk. That is a deliberate trade for unattended boot, and the passphrase path stays available: an appliance that cannot reach the platform prompts for the passphrase and derives the key from it.

Verify it yourself

• The public edge is externally checkable. Point any SSL scanner (Qualys SSL Labs, testssl.sh) at your tenant URL and read the protocols and ciphers it reports. From a shell, curl -v https://{slug}.parascope.io/ 2>&1 | grep "SSL connection" prints the negotiated version. The scanner will also show that TLS 1.2 is accepted, which matches what this page says.
• The appliance connection is checkable from your side. nc ingest.parascope.io 7422 prints the connection greeting, which carries "tls_required":true and "auth_required":true, before any Parascope credential is involved. That greeting is sent in the clear and TLS is negotiated straight after it, so openssl s_client pointed at the port reads the greeting as a TLS record and errors; the greeting is the thing to read.
• Appliance credential encryption is checkable exhaustively, not by sampling. Reading /etc/parascope/encrypted/ only shows you that the encrypted files are encrypted, which is the wrong question; the question is whether anything sensitive sits outside it. sudo find /etc/parascope -type f ! -path '*/encrypted/*' ! -path '*/public/*' lists every file the appliance keeps outside the vault. That output should contain no collector .env file and no private key. What it does contain is the broker credential and the appliance configuration named in the section above, plus configuration files for the broker and the vault, including the vault's salt, which is not a secret and is useless without your passphrase. Anything else in that list is a finding, and security@parascope.io wants to hear about it. findmnt -T /run/parascope confirms that the decrypted copies live under a tmpfs mount that a power-off discards.
• Your export archive downloads through the product. Trigger an export under Settings → Account → Data Export; the download resolves to an authenticated Parascope route that decrypts and streams it, and no object-storage URL is issued. Data Handling and Retention covers that path.
• Encryption controls with their own verify pointers are listed in the control matrix. Anything this page leaves open goes to security@parascope.io.