Security & Trust

Last updated 29 July 2026

For security reviewers, procurement teams, and anyone who has to sign off on bringing KubeManta into a regulated environment.

Summary for the person who has 60 seconds

Question	Answer
Where does our data go?	Nowhere. KubeManta is self-hosted. Cluster data never reaches the vendor.
What does leave the cluster?	A license key and a random cluster UUID, to the licensing provider — plus, unless you switch it off, a node-count report (size counts only, itemised in the Privacy Policy). Optionally, a version check that sends nothing. That is all.
Can the vendor access our cluster?	No. No back-channel, no support tunnel, no vendor credentials.
Does the AI act on its own?	No. Every write requires explicit human approval. Enforced in code, not policy.
Is it secure by default?	Yes — a vanilla install is read-only. Write permissions, secret reading, and privileged operations are all opt-in.
SSO?	SAML 2.0, OIDC, LDAP/AD.
Do you have SOC 2?	No — see §8. We will not imply otherwise.
Third-party penetration test?	Not yet — see §8.

1. Architecture and data residency

KubeManta installs into your cluster with Helm and runs there. There is no vendor control plane, no data pipeline out, and no agent reporting to us.

What runs in your cluster:

Component	Role
Agent pod	API, database, licensing, all business logic. Runs as UID 1000, non-root.
Terminal sidecar	The browser terminal's shell. Runs as UID 1001 — a different user and PID namespace from the agent, holding no secrets.
UI pod	The Next.js dashboard.
expert-exec pod	Optional, off by default. Isolates privileged operations — see §5.

State lives in one SQLite database on a persistent volume in your cluster.

What crosses the boundary — the complete list:

Destination	Payload	Frequency	Disable
Licensing provider	License key + cluster fingerprint (a random UUID). The heartbeat also carries the node-count report — eight numbers and nothing else, itemised in the Privacy Policy §3.3, never used to calculate a charge, and switchable off with `LICENSE_METER_ENABLED=false`.	Validate 12h, heartbeat 6h	Network policy; degrades gracefully (§7)
Our version feed	Nothing — a bare GET for a public file. No body, no query, no key, no identifying headers.	~6h, cached	Admin UI, Helm value, or env var; off automatically in air-gap mode
An AI provider you configure	Prompt content, from your cluster directly to them — never via us	Only when someone uses an AI feature	Not configured by default; local-only mode; egress allowlist

The cluster fingerprint is the metadata.uid of your kube-system namespace — a random UUID Kubernetes generated at cluster creation. The fingerprint itself says "same cluster as last time" and nothing else — no names, no cloud, no contents. The node-count report is separate, itemised, and disableable, as above.

2. Authentication and SSO

SSO: SAML 2.0, OIDC, and LDAP/Active Directory, usable concurrently. JIT user provisioning and group-to-role mapping. (Enterprise tier.)

Implementation specifics a reviewer will want:

SAML: RSA-SHA1-signed responses are rejected (rejectDeprecatedAlgorithm); SP-side signature and digest algorithms pinned to SHA-256. Response signing is mandatory — no configuration accepts a fully unsigned response.
Replay protection: assertion IDs are recorded and single-use.
Request binding: SP-initiated flows bind InResponseTo to the originating request via a signed relay cookie. Unsolicited/IdP-initiated responses are rejected. (v1 is SP-initiated only — a deliberate limitation, stated here so it is not a surprise during integration.)
OIDC: Authorization Code + PKCE, JWKS signature verification, .well-known discovery.
Session revocation: deactivating a user is enforced per-request, not only at next login.

Local authentication: bcrypt password hashing; signed HMAC session cookies; per-IP login lockout with durable auto-ban.

Break-glass: local admin login is never fully disabled, so an IdP outage cannot lock you out of your own cluster. A CLI password reset exists via kubectl exec.

Sessions: sliding idle timeout (default 8h, configurable, 0 disables) with an absolute ceiling. Both apply; the stricter wins.

3. Authorization — RBAC at two layers

3.1 Application RBAC

Per-user accounts with viewer and admin roles. The role is read from a signed session claim — never from client input.

Every privileged endpoint calls a server-side admin check. Viewers get HTTP 403 on writes, on privileged activity feeds, on saved configurations that could contain secrets, and on the terminal.

How it is verified: a behavioral test suite asserts that a viewer session is rejected on a representative endpoint from every category in the blocklist, with an admin session as positive control. A per-endpoint enforcement audit is published in RBAC_ENFORCEMENT.md.

3.2 Kubernetes RBAC — secure by default

A vanilla install is read-only. This is the default, not a hardening guide you have to follow.

Capability	Default	To enable
Read workloads, events, metrics	✅ On	—
Read Secrets	❌ Off	`rbac.readSecrets=true`
Write (restart, scale, delete, exec)	❌ Off	`rbac.allowWrites=true`
Privileged operations (Helm writes, apply)	❌ Off	`expertMode.enabled=true`

Without these opt-ins the corresponding features return 403 — including to the AI. An operator who installs and walks away has installed a read-only tool.

4. Approval-gated remediation — nothing is autonomous

KubeManta never changes your cluster on its own. There is no autonomous remediation loop in the product.

This is enforced structurally, not by prompt instruction:

AI write tools are never executed inline. The reasoning loop can only emit an approval request and stop.
Execution happens only through a separate endpoint that requires an admin role.
That endpoint requires a single-use, content-bound approval token — the token authorizes exactly the reviewed action. It cannot be replayed or substituted.
Two further durable limits apply on top: a blast-radius cap (writes per actor per time window) and a circuit breaker that trips after repeated write failures. Both are stored in the database and survive a pod restart.
Every write is audited with actor, action and scrubbed detail.

A viewer's approval attempt is rejected before any of this is reached.

5. Privilege isolation

The cluster-admin credential is not in the main application pod.

When Expert Mode is enabled, privileged operations are delegated to a separate expert-exec pod:

The cluster-admin token exists only in that pod.
The agent calls it over HTTP with a bearer secret; a NetworkPolicy restricts its ingress to the agent pod alone.
It builds an ephemeral kubeconfig on tmpfs and deletes it after each operation — never on persistent storage.
It is off by default.

Terminal isolation: the browser terminal's shell runs in a separate sidecar as UID 1001, with a different PID namespace from the agent, no encryption key, no expert credential, and a mount of only its own home directory — it cannot reach the application database. The agent authenticates the WebSocket before accepting the connection, and applies IP access control to it explicitly (because HTTP middleware does not run in WebSocket scope).

Terminal sessions are additionally bounded by per-session memory, process, file-size and file-descriptor limits, a concurrent-session cap, and an idle reaper.

6. Audit trail

Every privileged and destructive action is recorded with who (attributed actor), what (action), and detail (scrubbed of credential-shaped content): pod deletion, deployment restart/scale/delete, Helm install/upgrade/rollback, manifest apply, AI-initiated writes, configuration changes, terminal session open/close, SSO logins and configuration changes, and blocked egress attempts.

Actor attribution is trustworthy: X-Forwarded-For is honoured only when the socket peer is in a configured trusted-proxy CIDR, and then the rightmost untrusted address is taken — so a caller cannot spoof its identity.
Retention defaults to 365 days for the audit log and is configurable per table. An operator-visible view shows size and retention per table.
Tamper-evidence: the audit surface includes a chain-verification endpoint.
Export is available for your own compliance pipeline.
The audit log is admin-only to read.

The audit log lives in your cluster. We never see it.

7. Encryption and secrets

In transit: TLS to the cluster, terminated by your ingress or load balancer.
At rest: credential-bearing settings — cloud credentials, alert integrations, saved Helm configurations, saved bundles, SSO configuration, access-control policy — are encrypted with AES-256-GCM before storage.
Key management: from an environment variable or a mounted Secret. The Helm chart generates a persisted random key by default, marked to survive upgrades. Bring your own key if you prefer.
Secret reading is opt-in (§3.2). Without it, the AI, MCP surface and terminal cannot read Kubernetes Secrets at all.
Redaction: credential-shaped content is scrubbed from logs before they reach any AI prompt or audit detail. Its precise scope and limits — including that it is pattern-based and administrator-disableable — are stated honestly in Privacy Policy §5.4.

8. Compliance posture — what we have and what we do not

We would rather lose a deal than win one on a false compliance claim.

What we do NOT have

	Status
SOC 2 Type I or Type II	❌ Not held. Not in progress. On the roadmap, funded by early enterprise revenue.
ISO 27001	❌ Not held.
Third-party penetration test	❌ Not yet commissioned. Budgeted; planned after initial enterprise deals.
HIPAA / PCI-DSS / FedRAMP	❌ No attestation.
Accessibility audit (WCAG)	❌ Not performed.

If a checklist asks "SOC 2?", the answer is no. We will not answer "in progress" unless an audit has actually begun.

What we do have

A self-hosted architecture that removes the vendor from your data path entirely — which is what most of a SOC 2 review of a SaaS vendor is trying to establish in the first place.
Secure-by-default Kubernetes permissions (§3.2).
Defense-in-depth privilege isolation (§5).
A complete audit trail you hold (§6).
Encryption at rest for credential material (§7).
Admission-policy hardening verified by automated tests (§10).
Documented, disclosed limitations — including in this document.

Why this may matter less than the checklist implies

A SOC 2 report on a SaaS vendor exists to give you assurance about a vendor holding your data. We do not hold your data. The controls a SOC 2 auditor would test on our side govern account and billing records — email addresses, subscription status, license keys — and not your cluster.

We think that is a stronger answer than a certificate. We also recognize it may not satisfy a mandatory procurement gate, and we would rather you knew that at the start of an evaluation than at the end. If a certification is a hard requirement, tell us — it helps us prioritize.

9. Vulnerability disclosure

[email protected]

Please report privately first; do not open a public issue.
We aim to acknowledge within 1 business day, for all tiers including Free.
We will confirm or dispute, agree a disclosure timeline, keep you updated, and credit you if you would like.
Safe harbour: we will not pursue legal action for good-faith research that respects user privacy, avoids service degradation and data destruction, and gives us reasonable time to fix before disclosure.
Test against your own installation, not our infrastructure. Testing our hosted endpoints needs prior written consent — see Terms of Service §7.

We do not currently run a paid bug-bounty programme.

10. Deployment hardening

The Helm chart is hardened by default — there is no "hardened profile" flag to remember.

Every pod the chart renders clears the common Gatekeeper/Kyverno constraint library and Pod Security Admission "restricted" out of the box: CPU and memory requests and limits on every container, runAsNonRoot, allowPrivilegeEscalation: false, capabilities.drop: [ALL], seccompProfile: RuntimeDefault at pod and container level, an AppArmor annotation, readOnlyRootFilesystem, automountServiceAccountToken: false on the API-talking pods (with explicit projected tokens), and no privileged / hostNetwork / hostPID / hostIPC / hostPath. Image tags are pinned, never :latest.

All of this is pinned by an automated render test, so it cannot silently regress.

Two documented exceptions, both optional, runtime-only, and requiring Pro + admin + Expert Mode:

The Trivy self-scan Job has no readOnlyRootFilesystem — Trivy needs a writable CVE-database cache.
The network-analyzer node probe uses hostNetwork. The pod-source probe and all static analysis do not.

Both degrade gracefully if your policy forbids them. A policy denial of any KubeManta write is caught and reshaped into a message naming the blocking policy and the required fix — never a raw webhook dump. Full detail: GATEKEEPER.md.

Additional controls: in-product IP allow/deny lists with durable auto-ban (fail- safe, with loopback and private ranges always exempt so kubectl port-forward cannot lock you out); network policies including blocking cloud instance-metadata endpoints; and flexible exposure modes (service-only, BYO ingress class, BYO load balancer, Gateway API) so you can put your own WAF in front.

Honest caveat: the in-product IP filtering is defense in depth, not a WAF. No L7 pattern detection, no DDoS absorption, no geo-fencing. For internet-facing production, put a real edge in front — the service-only exposure mode exists to make that straightforward.

11. Air-gapped and restricted-egress deployments

KubeManta supports fully air-gapped operation. Enabling air-gap mode renders a default-deny egress NetworkPolicy, forces AI to local-only with an outbound allowlist, disables the update check, and switches vulnerability scanning to offline mode. Corporate forward proxies are supported.

You may mirror our images into your own registry — expressly permitted by EULA §2.

Honest disclosure — please read before purchasing for an air-gapped environment. Some of our documentation has described air-gapped license verification as fully offline against a baked-in public key. That is not accurate for the current code. The Software still attempts the license validation call in every mode; in an air-gapped install that call is blocked at the network layer, and the install then runs on its cached entitlement for the 7-day offline grace period before degrading to Free tier.

In practice a long-running air-gapped install currently needs either an outbound allowance for the licensing endpoint or a forward proxy. We are correcting the affected documentation, and genuinely offline verification is on the roadmap. If this matters to you, talk to us at [email protected] before purchasing — do not discover it after deployment.

12. Source protection

The agent's Python sources are Cython-compiled to native modules during the image build; the readable source is removed. Two build-time gates fail the build if violated: a check that no protected source leaked into the shipped image, and an import smoke test confirming the compiled module still works.

We mention this in a security document because reviewers notice it and sometimes mistake it for obfuscated malware. It is intellectual-property protection, it is disclosed, and it is contractually reflected in EULA §4.1 — including the statutory interoperability exception.

Third-party open-source components are inventoried in THIRD_PARTY_LICENSES.md.

13. AI safety controls

For reviewers evaluating the AI features specifically:

Control	Effect
Master kill switch	One setting disables every AI entry point. Everything else keeps working.
Data residency	Restrict AI to an allowlist of providers; local-only mode keeps prompts inside your network.
Egress allowlist	Deny-by-default outbound domains for AI traffic; blocks are audited.
Namespace scoping	Restrict which namespaces AI may read.
Redaction	Credential-shaped content scrubbed before prompts are built (limits in §7).
Prompt audit	Optionally log every prompt and response, in your cluster.
Cost caps	Per-provider daily token and request budgets with hard stop.
Write safety	Approval gate, blast radius, circuit breaker (§4).

AI output is advisory and can be wrong. Security scanning is assistive and is not a guarantee that your images or configuration are secure. See Terms of Service §10.

14. Business continuity

Our own systems — the website, billing bridge and lead database — are backed up nightly, GPG-encrypted before upload to off-site object storage, with the decryption key held offline. A compromise of our hosting cannot decrypt the backups. Restores are tested periodically.

Your cluster's backups are yours to run. We do not hold your data, so we cannot restore it. The Software supports optional streaming replication of its own database to object storage you control.

15. Contact

Purpose	Contact
Security vulnerabilities	[email protected]
Security questionnaires, procurement, architecture review	[email protected]
Privacy and data-protection	[email protected]

We are a small team and answer security questionnaires directly. If something here is unclear or looks wrong, ask — we would rather have the conversation.

Related: Privacy Policy · DPA · Subprocessors · EULA