Introducing ZTB - Zero Defining Zero Trust for Bring Your Own Cloud

[ankit01-oss]

What makes a BYOC model zero trust?

Over the past few weeks, we have been rigorously researching and discussing how to build a secure BYOC model. That led us to define what a Zero Trust BYOC model should look like. We've come up with the following five principles that must be present for a BYOC deployment to qualify as “Zero Trust”:

1. Data plane isolation: The customer’s data and compute MUST stay entirely within their cloud account.
2. Pull-based control plane communication: The customer environment MUST initiate any communication with the vendor — never the other way around. Vendor control plane SHOULD NEVER initiate inbound connections to the customer’s environment.
3. Component level zero trust: No component within the BYOC deployment implicitly trusts another just because it’s on the same network or cluster. All internal services MUST authenticate and authorise each other, using signed identities (e.g. JWTs, IAM roles).
4. Least privilege access: Every system, user, and automation MUST have only the minimal access required, for only as long as needed. IAM roles MUST be scoped, the token SHOULD BE time-limited, and RBAC policies MUST be enforced in Kubernetes
5. Encryption everywhere: All communication (inbound, outbound) MUST be encrypted using strong standards. We MUST use TLS 1.2 or higher for all communication paths. Best practice is to enforce this over internal communication also.

What do you think? Are these principles enough?

What would you add to it?

[matt-allan]

Hi,

I'm building a Zero Trust BYOC developer platform. I'm glad to see someone formalizing the model! The way my product approaches this is a bit different, but I can offer my perspective on the principles:

How is trust established?

It's not clear how components determine which identities they should trust. For example, in this section:

All internal services MUST authenticate and authorise each other, using signed identities (e.g. JWTs, IAM roles).

Where do they get the list of identities they trust? In a lot of Zero Trust networking products, the control plane distributes the public keys. Some products don't trust the control plane at all, or make it optional, like Tailscale lock.

It's fine if this isn't a requirement for Zero Trust BYOC, but if it's not then claims like "blocks lateral movement in case of compromise" need to be qualified, e.g. "blocks lateral movement in case of component compromise".

Is it Zero trust or zero knowledge?

The data plane isolation section requires that all of a customer's data MUST stay entirely within their cloud account, with an exception for metadata and telemetry. I think this is too strong.

A lot of the value of a Zero Trust BYOC SaaS is having easy access to data. It doesn't always map cleanly to "metadata". In my own product, developers can view build and release logs through the web console. But there is no way I could ever see their customer's data. The important distinction in my mind is between your direct customer's data and their customer's data, not between data and metadata.

Pull vs Push doesn't matter

Using pull instead of push doesn't meaningfully improve security. It seems like it does, but that's because of the other principles it enables.

As a thought experiment, imagine the customer runs a custom web server you connect to instead. Is it any less secure? The only practical difference is they need to use inbound firewall rules instead of outbound.

What really matters is that the agent (or web server) gives the vendor a narrow, domain specific API for access, which the customer can audit and control. There is a good example of this principle in Building Secure and reliable systems.

Ideally the customer can audit the source code, and the vendor cannot auto-update the agent.

Least Privilege examples

IAM roles MUST be scoped, the token SHOULD BE time-limited, and RBAC policies MUST be enforced in Kubernetes.

In a zero trust design, why is the vendor defining IAM roles and enforcing RBAC policies? I think I get what you mean but the examples sound like traditional BYOC, not zero trust.

My own product doesn't need IAM access, unlike my competitors, because I use a zero trust design. I do enforce least privilege by sandboxing the agent so it doesn't accidentally inherit the host's IAM permissions.

Encrypting local communication

Just a small nit:

Best practice is to enforce this over internal communication also.

I'm using unix domain sockets to connect to the agent from the CLI. If you have access to the socket, you almost certainly have access to any TLS cert on the same filesystem. Am I not following best practices to use plain text?

I think this should say "over internal networks" instead.

Appreciate you putting the work into this. Happy to talk more if you have any questions.