Request Access
FeaturesSecurityInstallHow it worksIntegrationsFAQReleasesSign In

security

Security at Cilera

You trust us with a map of your network. Here is how we keep it safe: the short version first, then the detail. Everything here is true of the service today.

  • EncryptedTLS 1.2+ to and from Cilera, AES-256 at rest.
  • Nothing connects inThe operator only calls out, over HTTPS.
  • Least privilegeOne non-root pod that never changes your workloads or policies.
  • IsolatedEvery workspace walled off in the database; credentials kept only as hashes.
  • AuditedEvery settings and security change logged, tamper-evident, for 12 months.
  • Independently checkedTop grades from Mozilla Observatory and SSL Labs. Re-run them yourself.

Encrypted in transit

  • HTTPS only. Every Cilera address redirects plain HTTP to HTTPS and sends HSTS for two years, including subdomains.
  • Modern TLS. TLS 1.2 and 1.3 only. Older versions are refused.
  • From your cluster. The operator only makes outbound HTTPS connections. Nothing connects into your cluster.
  • Inside your cluster. The operator reads flows from Hubble Relay over TLS or mutual TLS when Relay serves it, as on GKE and AKS, with certificate verification always on. Otherwise it uses Relay's plaintext in-cluster port, the open-source Cilium default.
  • Between our services. Connections from our services to the database are encrypted.
  • To your SIEM. Syslog forwarding uses TCP with TLS and certificate verification by default. Plain UDP or TCP is only used when an owner or admin explicitly chooses it, and the destination is marked unencrypted.
  • Alerts. Slack and webhook alerts go to HTTPS addresses on public hosts only. Webhooks are signed (HMAC-SHA256 with a timestamp), so your endpoint can reject forged or replayed requests.

Encrypted at rest

  • Your data. The database and its backups are encrypted at rest with AES-256.
  • Integration secrets. Slack webhook URLs and webhook signing secrets are encrypted again in a separate secrets vault. Only our server can read them; they never reach the console.
  • Credentials. API tokens and cluster credentials are stored only as hashes. A copy of the database would not contain a working credential.
  • Shown once. API tokens and webhook signing secrets are shown once, when they are created, and never again.

Who can do what

  • Workspace isolation. Every table is isolated by workspace in the database itself, not only in application code.
  • Owners and admins for changes that matter. Changing alert channels and creating API tokens needs an owner or admin who confirms their password. Alert channels can also be changed with a read-and-write API token. Containment needs an owner or admin, who confirms what will be cut; it can never be started with a token.
  • Audit log. Every change to settings and security, by a person, an API token, the operator or Cilera support, with what changed. Entries are append-only and chained by hash, so a removed or altered entry shows. Kept 12 months, readable by owners and admins, and forwarded to your SIEM if you choose.
  • API tokens. Read-only or read-and-write, always expiring (30 days to a year), revocable at once. A token can never create tokens or contain a workload.
  • AI explanations. When someone asks for one, that incident's evidence (counts, workloads, ports and drop reasons) is sent to a third-party AI model to write the explanation. No notes and no other incidents.
  • Deleting your data. The owner can delete the workspace with their password. Clusters and API tokens are refused at once, and everything is deleted after 7 days unless the owner cancels.

What runs in your cluster

  • One pod, read-only except its own Secret. Distroless, non-root, read-only filesystem, all capabilities dropped. No access to pods, nodes or your other Secrets.
  • What it can write. Its own state Secret, which holds the cluster credential. When containment is on, a deny-only Cilium policy named cilera-containment-*, when an owner or admin contains a workload. An admission policy in your cluster rejects any other policy write. Containment can be left off at install.
  • What leaves the cluster. Aggregated flow counts by workload, port and verdict, drop reasons, latency, allowlisted Cilium settings, network policy specs, and namespaces and workloads with their labels (each can be turned off or filtered). HTTP and DNS detail only when you turn them on. No packet payloads and no pod IPs of your workloads.

Check it yourself

Independent tests of our public addresses. Our grades on 10 October 2026 are shown; each link runs the test again in a new tab, so you see today's result, not ours.

Security questions and vulnerability reports

Email [email protected]. Security questionnaires are welcome. Vulnerability reports with steps to reproduce go straight to our engineers, and we follow coordinated disclosure through to a fix.

×

console

The Cilera console is in early access

The console is not yet publicly available. Request access at [email protected].

Request AccessKeep Exploring