Simply put: Ververica’s new Bring Your Own Cloud architecture follows Zero Trust design principles, providing a deployment method that blends security and accessibility for businesses.
This blog is the next installment of the BYOC series. The first blog introduced Ververica’s Bring Your Own Cloud Deployment option, offering a high-level overview of why BYOC was created and the benefits users can expect when utilizing this deployment option. The second blog, digs more deeply into “The Dilemma” businesses encounter when trying to find an ideal balance to ensure that a chosen deployment provides the appropriate level of flexibility, efficiency and security required.
The third blog focuses on security, and is divided into two parts. Part One shares the evolution of the connectivity landscape, and the pressures businesses face in a world that is interconnected via the internet with no clear physical boundaries. It also introduces the variations of BYOC in the market and how well they support security measures, including Zero Trust strategies.
Part Two explores exactly how Ververica’s BYOC deployment option helps businesses to address ever-growing issues of connectivity, solution complexity, and the capability to adhere to strict security measures when utilizing Ververica’s Unified Streaming Data Platform. In addition, Part Two dives into how Ververica ultimately allows data streaming and processing projects as a cloud deployment that aligns and supports Zero Trust strategies. Let’s get started!
Simply put: Ververica’s new BYOC architecture follows Zero Trust design principles, providing a deployment method that blends security and accessibility for businesses.
When beginning to build a Zero Trust architecture, there are several essential questions that help guide how to best comply with Zero Trust design, including:
In Ververica’s BYOC option, the control plane is centralized and fully managed by the vendor, while the distributed data plane resides within the customer cloud.
The next two questions are related to data governance. With Ververica, vendors in the control plane store and control only metadata, so data never leaves the data plane and is 100% owned by the customer, ensuring security.
All data processing and data movement also happens within the customer cloud, inside the customer cloud account, thus keeping processing and data movement local and entirely under customer control. (As depicted in Figure 8.)
Figure 8: Ververica's BYOC control and data plane architecture
With Ververica’s BYOC, this same pattern repeats: the user has all control and the vendor has no implicit trust. Let's dive a bit deeper.
The next set of questions to ask when creating a BYOC offering includes:
With Ververica, in order to maintain Zero Trust, policy administration, observability, and all security policies remain under full control of the business. The vendor is then treated as a 3rd party, maintaining compliance with NIST 800-207. Figure 9 illustrates the implementation approach for managing policy control, observability, and sovereignty.
Figure 9: Policy and observability points control
To achieve this, it starts with interface decoupling. In Ververica’s BYOC model, we provide an agent that operates within the customer's cloud. This agent functions as a client, establishing a one-way connection from the customer's cloud to the control plane (server-side). This ensures that customers retain full control over connectivity with the vendor's (Vererica’s) control plane. (Figure 10.)
The agent is designed and packaged to allow seamless integration with the customer’s existing security and observability policies and tools, such as AWS VPC Flow Logs. Additionally, all data processing and movement occurs locally within the customer’s cloud, fully decoupled from third-party control planes. As a result, customers maintain complete control over data storage and access policies, ensuring sovereignty over their data at all times.
Figure 10: Implementation considerations for connectivity, observability and access policies
Next, let’s drill down even further in the implementation of the tenant local processing following Zero Trust strategy.
One of the most important Zero Trust principles is the principle of least privilege (PoLP), a security concept that dictates that users, applications, systems, or processes should have the minimum access permissions necessary to perform their specific tasks or functions. This minimizes the potential damage that can occur from accidental errors, security breaches, or malicious activities due to restrictive access rights.
Questions to consider here include:
Getting the implementation right at this stage introduces significant design trade-offs. Figure 11 highlights the seriousness of these challenges. Access privileges often start with broad permissions over infrastructure services, resulting in a larger trust surface. For example, if a vendor has control over your networking, compute, or storage services, the attack surface expands substantially. On shared IaaS (Infrastructure-as-a-Service) networking or storage resources, achieving granular service access, such as microsegmented access, is typically not feasible.
Similarly, in CaaS (Container-as-a-Service) environments, granting elevated privileges across entire clusters inherently requires a trust surface encompassing the full scope of those clusters. Since the cloud emphasizes co-location and density optimization, implementing a true Zero Trust model in scenarios requiring elevated IaaS or CaaS privileges is challenging.
Even if access is limited to the service level, a critical question arises: Which services should vendors have access to? The answer should always be the bare minimum required for the vendor’s services to function. Vendor designs must be closely scrutinized by repeatedly asking: "Does the vendor truly need this access to deliver its core business function?"
Figure 11: Least privileges principle
With Kubernetes now the de facto industry standard for orchestrating containerized workloads and enabling cloud portability, businesses must make several key implementation decisions early in the implementation process. Here are recommendations:
By adhering to these principles, businesses can build highly portable, secure, and customer-friendly solutions that align with modern cloud-native practices. Figure 12 shows how Ververica’s data plane software is made of containerized cloud native services that fit existing K8S/IaaS infrastructure, requiring no elevated privileges.
Ververica creates non-privileged Kubernetes namespaces dedicated to each tenant (workspace). Integration to existing customer monitoring solutions is portable and easily achievable, using collecting or scraping of containers standard output (for logs) and prometheus metrics within the Kubernetes cluster. The control plane then communicates only over agents for each tenant.
Figure 12: Least privileges with lightweight cloud-native services
Things get more sophisticated as we look at the next series of Zero Trust design questions (Figure 13). This part is critical, because it brings in the toughest choices and it really shows the difference between before and after zero trust architecture.
The last set of questions to consider when building a Zero Trust BYOC offering are :
Ververica ensures breach isolation by maintaining complete separation of service chains between tenants. This design guarantees that a breach in one tenant does not impact others. Authentication and authorization services are fully owned and managed by the business or customer, not the vendor, ensuring greater control and security.
Dynamic authorization further enhances security by using ephemeral or rotating access tokens for critical tenant data. This approach significantly mitigates risks, even in the event of a credentials breach.
Granular access control empowers customers with explicit policies, defining precise third-party access URLs and listing allowable API calls for tenant storage. Importantly, these access policies remain under the customer's full control.
Figure 13: Isolated, dynamic and granular principles
Implementation begins with isolating service chains to ensure breach isolation (Figure 14). Each Ververica tenant (workspace) is assigned its own dedicated access, managed through Role-Based Access Control (RBAC). This includes a dedicated agent, a specific set of services, and exclusive data storage. A single service chain is designed to serve only one tenant, ensuring complete isolation.
A critical aspect of this implementation is leveraging existing cloud-native customer services for authentication and authorization when accessing customer data. While portability is often prioritized, as discussed in previous chapters, it is not always the best choice for Zero Trust implementations. In this case, data plane software must follow best practices by integrating with specific cloud-native solutions, such as OpenID Connect (OIDC) providers and security token services. This approach allows Ververica’s BYOC deployment to avoid managing these services, their artifacts, or service policies, leaving full control to the customer.
Finally, accessing customer data storage is equally critical. Storage remains entirely under the customer's control and is isolated for each tenant. Customers should define and manage access policies, specifying exactly which resources (e.g., a specific S3 bucket) and which actions (e.g., GetObject, PutObject) are permitted. This approach enforces granular access control and upholds the principle of least privilege.
Figure 14: Implementing isolated, dynamic and granular principles
The Zero Trust paradigm is changing how organizations are building and thinking about security. The importance of assuming a breach has already happened, never providing implicit trust and always requiring verification are key steps to meeting Zero Trust strategies. Gartner revealed that Zero Trust architecture and solution trends are on the rise, with 63% of organizations already implementing Zero Trust strategies. Ververica takes security seriously and acknowledges this trend, which is why our BYOC deployment option is built specifically to meet Zero Trust specifications.
In conclusion, let’s summarize how the BYOC deployment of Ververica’s Unified Streaming Data Platform meets Zero Trust principles (Figure 15):
By following these principles, Ververica is able to provide a secure, high-performance streaming data platform solution that aligns with Zero Trust architecture in a flexible BYOC deployment method, meeting and exceeding the security requirements of a deployment option.
Figure 15: Ververica's Unified Streaming Data Platform
Stay tuned! In the next blog of this series, dive into how Ververica’s BYOC offering increases efficiency, another part of “The Dilemma” business face when choosing a solution and implementation.
Catch up on the entire BYOC Blog Series: