Security
Easier operations. Explicit boundaries.
Understand Ankra’s architecture, the controls available today and how to secure the applications and infrastructure you run.
Architecture
Where Ankra sits in your trust boundary.
A SaaS control plane, an outbound-only agent inside your cluster, and Git as the source of truth between them.
Yours
Your Git repositories
Desired state for clusters, stacks and applications.
Ankra
Control plane
UI, API and orchestration at platform.ankra.app. Holds metadata, not your workloads.
Your infrastructure
Kubernetes cluster
- Node
- Node
- Node
Ankra agent, one per cluster
Git
Git is the source of truth
Desired state lives in your Git repositories. The platform reconciles clusters to Git, so turning Ankra off leaves your clusters running from history you own.
SaaS control plane
The control plane runs with us
The UI, API, and orchestration run at platform.ankra.app by default. It holds metadata, encrypted credentials in Vault, and the audit log, not your workloads. Enterprise customers can run the control plane self-hosted instead.
In-cluster agent
The agent runs with you, and only dials out
One agent per cluster connects outbound over NATS with per-agent JWT credentials and rotating session tokens. Nothing connects inbound. Your API server is never exposed to us.
The honest part: the agent runs with cluster-admin
The agent has cluster-admin inside your cluster. It has to, because it manages anything you ask it to, from namespaces to CRDs. We would rather tell you that plainly than bury it. What constrains that power is the operating model around it:
- Scoped roles and configurable agent autonomy. Gated proposals wait for approval.
- Drift guards. Sync windows and prune protection constrain out-of-band change.
- Lease serialisation. One operation at a time per cluster, no racing changes.
- Execution records and agent transcripts for the work performed.
Controls
The controls matrix, as it stands today.
Everything below is shipped, opt-in, or actively in progress. There is no aspirational tier. If it is not listed, we have not built it.
Identity & access
4 controls- SSO login with MFAShipped
TOTP, WebAuthn passkeys, and recovery codes on every account.
- Organisation-level MFA requirementShipped
Require MFA for every member of your organisation, enforced at login.
- Role-based access controlShipped
Built-in and custom roles, with assignments scoped to cluster groups.
- Short-lived kubeconfig cluster accessShipped
SSO-backed cluster credentials that expire on their own, with instant revoke-all.
API & AI surface
5 controls- API tokens hashed at restShipped
SHA-256 hashes only. Secret material lives in Vault, with a 90-day default expiry.
- MCP scope isolationShipped
mcp:read and mcp:write are separate scopes; MCP tokens are rejected on the REST API and vice versa.
- MCP OAuth 2.1 with PKCE onlyShipped
Standards-based authorisation per RFC 9728, RFC 8414, and RFC 7591.
- Always-on AI secret redactionShipped
Pattern and entropy detection runs before anything is persisted.
- Secret values never exposed to AI toolsShipped
AI tools see key names and counts only, never the values.
Secrets & data
3 controls- Vault-backed secret storageShipped
Platform secrets are stored in HashiCorp Vault or OpenBao.
- End-to-end secret encryptionOpt-in
SOPS with AGE, using per-organisation keys.
- In-cluster SOPS decryptionShipped
Encrypted secrets are decrypted inside your cluster. Plaintext never transits the platform.
Audit & governance
6 controls- Append-only audit logShipped
Every administrative change is recorded in a log that can only grow.
- Organisation audit viewerShipped
Search and filter the full audit history from the platform.
- Audit log exportIn progress
CSV and JSON export of audit events.
- 12-month standard audit retentionIn progress
Audit events retained for twelve months as standard.
- Draft, approve, commitShipped
Every AI-proposed change is human-approved and lands as an attributed Git commit.
- Drift detectionShipped
Sync windows and prune guards catch and constrain out-of-band change.
Cluster & infrastructure
4 controls- Hardened in-cluster agentShipped
Non-root, read-only filesystem, all capabilities dropped, seccomp enabled.
- Outbound-only connectivityShipped
Per-agent credentials and no inbound access to your cluster.
- Always-on log redactionShipped
Logs are redacted at the source, before they leave your cluster.
- Hardened provisioningShipped
Scoped cloud firewalls, private networking, bastion hosts, Vault-managed SSH keys, and 15-minute join tokens.
Vulnerability management
8 controls- Security CenterOpt-in
Fleet-wide findings, per-cluster posture, and remediation priorities, powered by Trivy Operator.
- NetworkPolicy over-privilege scoringOpt-in
Ingress and egress scored per cluster: unprotected workloads, over-broad rules, and what to tighten.
- Pod-security policy violationsOpt-in
Kyverno baseline results per cluster, installed in audit mode with an explicit switch to enforce.
- One-click security baseline installShipped
Installs pinned Trivy Operator and Kyverno on a cluster from a single action.
- Security baseline on new clustersIn progress
A security baseline installed by default on newly created clusters.
- Accepted-risk dispositionsShipped
Accept a finding with an expiry date, and revoke the acceptance at any time.
- Daily posture snapshots and trendsShipped
Posture captured daily, so you see direction rather than a point in time.
- Scheduled security reportsShipped
Recurring reports by email, with CSV export.
Compliance
3 controls- Benchmark compliance postureOpt-in
CIS and NSA/CISA pass rates per cluster, plus Trivy configuration audit as a second axis.
- SOC 2 programmeIn progress
An ISMS is being built against the Trust Services Criteria. Audit in progress.
- Compliance evidence exportShipped
CSV or JSON over a date window: posture history, dispositions with reasons, audit summary, and attestations.
Your clusters
The other half: securing what you run.
Everything above is how we secure the platform. The Security Center is the product side of that, covering the clusters you run on it.
Image vulnerabilities, benchmark compliance, pod-security policy violations, and NetworkPolicy over-privilege across every cluster in the organisation. Findings become decisions you record once, with a reason and a review date, rather than a list that returns unchanged on the next scan.
Disclosure
Found something? Tell us.
We take reports from security researchers seriously and we answer them ourselves.
Report a vulnerability
Email security@ankra.ai with what you found and how to reproduce it. We acknowledge reports within three business days, and good-faith research will not be met with legal action.
Buying Ankra?
Procurement and compliance material lives on our trust page: our SOC 2 posture, what data the control plane holds, and the sub-processors behind the platform. Product detail on every control lives in the documentation.
Security review
Reviewing Ankra for your organisation? Talk to security.
Send your questionnaire or ask how a control works. The trust centre holds the rest.
What the trust centre covers.
- Compliance status
- Data handling and sub-processors
- Platform security controls