Clariti Docs

Security Model

The Clariti Connector is designed to run on customer infrastructure with minimal attack surface. This page explains the security controls in detail.

Network Security

Outbound-Only Communication

The connector initiates all connections to Clariti Cloud. No inbound ports are required on your firewall. The only exception is port 8443 during initial registration, which binds to 127.0.0.1 by default (localhost only).

Certificate Pinning

When CLARITI_CA_CERT_PATH is configured, the connector validates the Clariti cloud certificate against a pinned CA. This prevents man-in-the-middle attacks even if an attacker controls your DNS or proxy infrastructure.

No Redirect Following

The connector does not follow HTTP redirects. This prevents redirect-based attacks where an attacker could redirect the connector to a malicious server.

HTTPS Enforcement

The cloud API URL must use HTTPS. Plaintext HTTP connections are rejected at startup.

Credential Security

Encryption at Rest

On-premises tool credentials (passwords, API keys, certificates) are encrypted using Fernet symmetric encryption. The encryption key is established during registration and never stored in plaintext.

Secure Memory Handling

When credentials are cleared (e.g., during decommission or credential rotation), the connector overwrites the memory locations with random data before releasing them. This prevents credentials from lingering in freed memory.

Disk Persistence

During graceful shutdown (SIGTERM), encrypted credentials are written to disk at /data/credentials.enc with file permissions 0600 (owner read/write only). On the next startup, they are decrypted into memory and the disk copy is deleted.

Log Redaction

All log output passes through a structlog processor that redacts fields containing password, secret, key, token, or credential. Credentials never appear in connector logs.

Container Hardening

The connector Docker image is designed to run with maximum restrictions:

Security ControlSetting
Root filesystemRead-only (--read-only)
UserNon-root
CapabilitiesAll dropped (--cap-drop=ALL)
Privilege escalationDisabled (--security-opt=no-new-privileges)
Memory limit512 MB (--memory=512m)
CPU limit1 core (--cpus=1)
Temporary filestmpfs only (--tmpfs /tmp)

Authentication

Registration

  1. The Clariti dashboard generates a one-time registration token (64 hex characters)
  2. The token is hashed with SHA-256 before storage — only the hash exists in the database
  3. The connector presents the token via the bootstrap UI
  4. The cloud validates using constant-time comparison (preventing timing attacks)
  5. On success, the cloud issues the connector a 32-byte signing secret (stored on the data volume as a 0600 file; stored in the cloud encrypted and bound to that connector)
  6. The token is invalidated (single use)
  7. Registration tokens expire after 24 hours

Poll Authentication

After registration, every poll request is signed. The connector sends three headers:

HeaderValue
X-Connector-TimestampUnix time (seconds) when the request was signed
X-Connector-NonceRandom value, unique per request
X-Connector-SignatureHMAC-SHA256(secret, method + path + connector_id + timestamp + nonce + sha256(body)), hex

The cloud rejects requests whose timestamp is more than 5 minutes from its own clock, compares the signature in constant time, and remembers each nonce for 10 minutes so a captured request cannot be replayed. The secret never leaves the connector after enrollment; the cloud keeps only an encrypted copy.

Kill Switch

Clariti administrators can instantly disable any connector via the admin console. When disabled, the connector receives a 403 CONNECTOR_DISABLED response on its next poll and stops operating until re-enabled.

Data in Transit

All data between the connector and Clariti Cloud is encrypted with TLS 1.2+. The poll payload includes:

  • Health metrics — CPU, memory, disk usage, uptime (not sensitive)
  • Adapter results — asset data from on-premises tools (may contain hostnames, IPs, usernames)
  • Logs — structured connector logs (redacted of credentials)

Decommissioning

When a connector is decommissioned:

  1. Its status is set to DECOMMISSIONED in the database
  2. Its signing secret is deleted — it can never authenticate again
  3. Its registration token hash is cleared
  4. The kill switch is activated as a defense-in-depth measure
  5. Locally, credentials should be wiped by stopping the container and removing the data volume

Rate Limiting

  • Registration: Maximum 5 attempts per 15 minutes per connector
  • Poll: Maximum 1 poll per 10 seconds per connector (enforced cloud-side)
  • Login brute force: After 5 failed registration attempts, exponential backoff kicks in

Offline Resilience

When the connector cannot reach Clariti:

  • Adapter results are buffered in a local SQLite database (WAL mode, up to 500 MB)
  • Exponential backoff with jitter: 30s base, 2x multiplier, 300s max
  • After 10 consecutive failures, the connector enters degraded mode (5-minute poll interval)
  • When connectivity is restored, all buffered data is uploaded in order