BYOC Security: Zero Trust by Design
How Ververica's Bring Your Own Cloud deployment implements Zero Trust security — control-plane/data-plane separation, a one-way agent, least-privilege access, and per-tenant breach isolation, aligned with NIST 800-207.
On this page
Ververica Cloud: Bring Your Own Cloud (BYOC) is built on Zero Trust, security-first design principles. Your data and processing stay inside your own cloud account, you keep control of security policies and observability, and Ververica is treated as an untrusted third party that is granted only the minimum access its services require.
Where BYOC runs. Ververica operates the BYOC control plane in Microsoft Azure's Germany West Central region. The data plane can run in any Azure region in the world, so you can choose the location that is optimal for your data residency, latency, and compliance requirements.
This page explains what Zero Trust means, how the BYOC architecture embodies it, and the design principles to review before you deploy.
What is Zero Trust?
Zero Trust is a security model that abandons the idea of a trusted internal network behind a perimeter. In modern cloud environments there is no fixed network boundary around your users, applications, or data, so a firewall alone can no longer define what is "inside" and safe. Zero Trust replaces implicit trust with continuous verification.
The model is codified in NIST SP 800-207 and rests on three ideas:
- Never trust, always verify. Every access request is authenticated and authorized on its own merits, regardless of where it originates — including requests from a vendor.
- Assume breach. Operate as though an attacker may already be inside, and design so that a compromise is contained rather than catastrophic.
- Least privilege. Every user, service, and process gets only the minimum access needed to do its job, and only for as long as it needs it.
In a Zero Trust architecture a software vendor is not a trusted insider. BYOC is designed around that assumption: Ververica is a third party, and the architecture limits what that third party can see and do.
How BYOC's architecture enforces Zero Trust
BYOC splits the platform into two planes with a hard boundary between them.
- Control plane — managed by Ververica. Hosted in Ververica’s cloud, it provides the management interface, orchestration, and lifecycle of the platform. Critically, the control plane stores and controls only metadata. Your data never leaves the data plane.
- Data plane — owned by you. Runs inside your own cloud account and Kubernetes cluster. All data processing and all data movement happen locally, inside your cloud — fully decoupled from any third-party control plane. This is what gives you complete data sovereignty.
Because raw data and processing logic never cross into the vendor’s environment, an entire class of risk simply does not exist: there is no copy of your data in Ververica’s cloud to breach, subpoena, or mishandle.
A one-way agent, not vendor push-access
Connectivity between the two planes is handled by a Ververica agent that runs inside your cloud and establishes a one-way (outbound) connection to the control plane. The agent pulls instructions out to your environment; the vendor never opens an inbound connection into your infrastructure and holds no standing inbound access.
This matters for Zero Trust:
- You control connectivity. The connection originates from your side and is governed by your network and security policies. The agent integrates with your existing tooling — for example, AWS VPC Flow Logs — so you keep full observability of what crosses the boundary.
- No permanent cross-account trust. Weaker BYOC models grant the vendor long-lived cross-account roles or have the vendor manage IaaS services (compute, network, storage) directly in your cloud — designs that require broad, persistent privileges and enlarge the attack surface. BYOC avoids that: there is no permanent vendor foothold to compromise.
When evaluating any BYOC vendor, ask the Zero Trust question directly: does the vendor truly need this access to deliver its core function? If the answer is no, granting it only expands the trust surface.
Key security features
The BYOC deployment provides the following Zero Trust capabilities:
- Least-privilege access — Each component or user is granted only the minimum permissions required. For example, a process may be allowed to read or write only specific data locations.
- Identity-based authentication — Access is controlled by verified identity, so only authenticated users or systems can interact with the platform.
- Isolation — Your infrastructure and Ververica’s services are isolated from one another, limiting the blast radius of any issue or breach.
- Fine-grained authorization — You define detailed rules for who or what can access which resources and perform which actions (for example, read a bucket vs. write to it).
- Short-lived credentials — Access tokens are ephemeral and expire quickly, shrinking the window in which a leaked credential is useful.
- User-controlled security policies — You define and enforce your own encryption standards, access controls, and compliance measures.
- Full observability — You retain complete visibility into performance, activity, and security posture so you can monitor and troubleshoot effectively.
Designing for Zero Trust: principles to review before you deploy
Before deploying BYOC, review the following principles. Each maps to a NIST 800-207 concern and includes the questions worth asking of any vendor — including Ververica.
Policy control, observability, and sovereignty
In a Zero Trust architecture you retain full control over policy administration, observability, and security policy enforcement, and the vendor is treated as a third party.
Key questions: Who controls vendor–customer connectivity policies? Who owns and controls data-access policies? How does every party gain full observability at all levels?
With BYOC, the one-way agent keeps connectivity under your control, all data processing and movement stay inside your cloud, and the agent integrates with your existing security and observability tools — so policy enforcement, observability, and data sovereignty remain yours.
Least-privilege access
The principle of least privilege (PoLP) holds that any user, application, system, or process should have only the minimum access needed for its task, reducing the damage from error, breach, or misuse.
Key questions: How much control does the vendor actually need in your stack? How does the vendor guarantee a least-privilege design? Who owns observability and auxiliary systems?
Grant external vendors the bare minimum required to deliver core services. In particular, avoid handing a vendor control over networking, compute, or storage unless it is strictly necessary — each grant expands the attack surface. For storage, define scoped policies that name exactly which resources (for example, a specific S3 bucket) and which actions (for example, GetObject, PutObject) are permitted.
Kubernetes workloads
Ververica’s data-plane software runs on your existing Kubernetes infrastructure without elevated privileges — it does not require access to the host operating system or the Kubernetes control plane. Ververica creates non-privileged Kubernetes namespaces dedicated to each tenant (workspace), and each tenant communicates with the control plane through its own agent.
You collect logs and metrics from the containers in these clusters — for example by scraping standard output for logs and Prometheus metrics — while preserving tenant-specific isolation. Because the software is packaged as standard microservice containers on certified Kubernetes distributions (compatible with any CNI or CSI / storage class), there is no proprietary lock-in: you can audit, replace, or relocate components.
Breach isolation
Zero Trust assumes a breach will happen and contains it. BYOC maintains complete separation of service chains between tenants — each tenant (workspace) gets its own dedicated agent, its own set of services, and its own exclusive data storage, governed by Role-Based Access Control (RBAC). A single service chain serves exactly one tenant, so a breach in one tenant cannot affect another.
Key questions: How do you ensure breach isolation, identity-based authentication, and dynamic authorization? Who owns authentication and authorization services? How is granular access control enforced?
Key measures:
- You own authentication and authorization — these services are managed by you, not Ververica, keeping security control on your side.
- Dynamic authorization with ephemeral or rotating tokens mitigates the risk of a compromised credential.
- Granular, customer-controlled access policies let you specify exactly which third-party URLs and API calls may reach tenant storage.
- Cloud-native integration — Ververica integrates with providers such as OpenID Connect (OIDC) and security token services, so you keep control of identity rather than handing it to the vendor.
Your cloud, your rules
Because data stays in your account and you keep control of policy, BYOC fits organizations with strict security, governance, and compliance needs — particularly regulated industries such as financial services. You get data residency (data never leaves your chosen region or provider), freedom from vendor lock-in, and the ability to apply your existing cloud pricing agreements — while still getting Ververica’s fully-managed Flink experience.
For where these responsibilities fall between you and Ververica, see BYOC and its shared-responsibility matrix. To deploy, see Getting Started: BYOC.