Building a zero-trust PaaS

When you click “Delete service” on a platform, how does it delete the Deployment in Kubernetes for you?

Why does a platform breach affect its customers?

Several developer platforms were breached in October 2026 alone. According to Wiz, at least nine AI developer platforms disclosed security incidents that month. Attackers were after much the same thing: environment variables stored by the platforms, especially API keys for AI services².

Zeabur was one of them. An attacker obtained a cluster admin token with no expiration, reached the platform database, and exfiltrated data for 321,810 accounts and 3,218,965 environment variable records³. A week later, an attacker at Railway escalated privileges from the build infrastructure, obtained CI credentials, and decrypted some of the environment variables stored in encrypted form. Up to about 100,000 workspaces were affected⁴. By the end of the month, secrets stored in Northflank's control plane had also been decrypted. Customers reported unauthorized use of their AI API keys, and Northflank had to ask all customers to assume every environment variable was compromised and rotate them all⁵.

This had happened before. In Zeabur's August incident, the attacker entered through a vulnerability in a user container and eventually reached the production database, obtaining the names and values of project environment variables⁶. Vercel's entry point was a third-party AI tool used by an employee⁷. CircleCI's was malware on an engineer's laptop⁸. GitHub integrations were compromised through stolen OAuth tokens held by Heroku and Travis CI⁹. After Codecov's uploader was tampered with, it sent environment variables straight out of customers' CI environments¹⁰.

The entry points differed, but the attackers wanted the same things. Platforms store customer data and hold the credentials needed to access customer resources. Often, another key inside the platform is all that protects that data: Zeabur's cluster admin token, for example, or Railway's CI credentials. Encryption doesn't stop the attacker when the platform also holds the decryption keys. Railway's and Northflank's environment variables were decrypted; CircleCI's encryption keys were extracted directly from a running process.

Once attackers breach the platform, they can use its identity to read every customer's data. A compromised platform means compromised customers.

Users shouldn't have to trust the platform

NIST SP 800-207 describes Zero Trust as refusing to grant implicit trust just because a request comes from an internal network or a company-owned device. Access still requires authentication and authorization, with only the permissions needed for the operation¹¹.

Apply that principle to the platform itself: users shouldn't have to trust the platform. Instead of holding a credential that can act on every customer's resources, the platform acts on each user's behalf with that user's permissions. The system hosting the resource decides whether to allow each request based on the user's identity.

Back to deleting a Deployment: Zeabur Open Source uses the user's token directly, so it doesn't need to keep a shared credential with access to every Namespace. The same RBAC rules apply whether you use Zeabur Open Source or run kubectl yourself.

That's the theory. How does it work in Kubernetes?

How does Kubernetes know whose token it is?

Kubernetes already supports OIDC authentication¹². A cluster administrator configures a trusted issuer: the authentication server that issues tokens. kube-apiserver verifies signatures with that issuer's public key, then maps the token's claims to Kubernetes users and groups. An expired token, or one that wasn't signed by a trusted issuer, fails authentication.

RBAC comes next. If Alice belongs to the dev group and an administrator grants that group access to the dev Namespace, Alice can work with resources there. RBAC permissions are additive, with no deny rules. If another binding grants Alice broader permissions, she gets those too¹³.

Zeabur Open Source only needs to include Alice's token in the request. It doesn't need its own list of the Namespaces she can access.

The right side of the diagram shows this flow. Zeabur Identity handles sign-in and issues tokens. Zeabur Open Source forwards the token, and kube-apiserver verifies the signature and checks RBAC. On the left, the platform holds shared, highly privileged credentials and checks users' permissions itself.

Connecting Zeabur Identity users to RBAC

zeabur-identityctl kube-config generates an AuthenticationConfiguration for kube-apiserver. For example, alice in Zeabur Identity maps to zeabur:alice in Kubernetes, and the dev group becomes zeabur:dev. The zeabur: prefix keeps these mapped identities separate from built-in identities that start with system:¹⁵.

To let the dev group edit resources in the dev Namespace, create this RoleBinding. Zeabur Identity's documentation also recommends binding roles to groups rather than individual users¹⁴:

kubectl create rolebinding dev-edit --clusterrole=edit --group=zeabur:dev -n dev

When Alice signs in with dev in her token's groups, kube-apiserver grants her the permissions from this binding. Zeabur Identity's own ServiceAccount can't create RBAC objects and has no impersonate permission. It can read only a few Secrets of its own, and each must be requested by name. The default admin binding is applied by the cluster administrator, using their own permissions, during installation¹⁶.

Who issues the key card? Who opens the door?

If issuers, signature verification, and RBAC still feel abstract, think of a hotel key card.

Zeabur Identity is the front desk. Signing in with a passkey is like showing your ID at check-in. The front desk gives you a key card marked “Alice, dev team.” kube-apiserver is the door lock: it checks that the front desk issued the card, then looks up which rooms the dev team can enter (RBAC). Zeabur Open Source is a runner who carries your card and uses it to open doors for you. The runner has no separate key that opens every room.

How long does that card last? If it never expires, the platform can keep acting on your behalf once it has it. Zeabur Identity's regular access tokens expire after 10 minutes by default; admin tokens expire after 5 minutes. Within a session, a refresh token can get you a new card, so you don't have to use your passkey every 10 minutes. By default, though, a session ends after 1 hour of inactivity. Even with refreshes, it lasts no more than 12 hours from sign-in by default¹⁷.

Access tokens use the JWT format defined in RFC 9068 and must contain a client_id claim¹⁹. The kube-apiserver configuration generated by Zeabur Identity checks this claim to reject ID tokens¹⁵.

If someone steals a token from the platform, they can use it to access resources Alice has permission to use until it expires. A stolen admin token gives them more access. That's why Zeabur Identity admin accounts can sign in only with passkeys. Their tokens carry the zeabur:admins group, which is bound to cluster-admin during installation¹⁶. The recommendation is to use a separate regular account for everyday work and sign in with the admin account only when you need to administer the cluster¹⁷.

The issuer's signing keys also need protection. kube-apiserver grants access based on identities signed by Zeabur Identity. Anyone who can issue a forged “this is Alice” token can obtain Alice's permissions.

Incidentally, Zeabur Identity runs as a small Pod, uses less than 30 MiB of memory after sign-in, and has no database of its own. Users, credentials, and sessions are all stored as Kubernetes custom resources²⁰.

How does the platform become an OAuth client?

zeabur-identityctl client create zeabur \
  --type confidential \
  --audience kubernetes \
  --display-name Zeabur \
  --redirect-uri https://zeabur.example.com/auth/callback \
  --home-url https://zeabur.example.com/ \
  | kubectl apply -f -

The sign-in flow looks roughly like this:

The dashed lines are round trips that happen only during sign-in. After that, only the bottom two solid lines remain: Zeabur Open Source sends your token directly to kube-apiserver with every request.

When Zeabur Open Source needs to know who you are, for example to read account details, it uses SelfSubjectReview to ask kube-apiserver “who does this token belong to?” It doesn't determine the user's identity by interpreting an ID token itself²⁴²⁶.

The zeabur-kube crate makes the Kubernetes API calls. It creates clients with the user's token. The sole exception is the terminal, which uses Zeabur Open Source's own ServiceAccount¹. That ServiceAccount is bound to a single Role that lets it create Pods in a dedicated terminal Namespace and connect to them to run commands²⁷. For example, this command checks whether it has permission to impersonate other users:

kubectl auth can-i impersonate users --as=system:serviceaccount:zeabur:zeabur

This command checks impersonate users. To check permissions on other resources, substitute the corresponding operation. The result also changes if the cluster administrator binds additional roles to this ServiceAccount.

Secrets are read with the user's token too. The list shows only names, types, and key counts; values are fetched from Kubernetes only when you ask to reveal them²⁸. Whether you can see a Secret's contents therefore depends on your permission to read it²⁶²⁹.

What happens when you don't have enough permission? Zeabur Open Source doesn't retry with its own identity. When kube-apiserver rejects a request, the interface lists the missing permissions and the original Kubernetes response, and asks you to contact an administrator³⁰. On the cluster page, you can also copy the required ClusterRole to send to the administrator³¹.

If you need to administer the cluster yourself, sign out and sign back in with your admin account using a passkey. The RBAC permissions associated with that token still determine which operations succeed¹⁷.

Zeabur Open Source keeps no separate copy of project data. A project is a Kubernetes Namespace. If you remove Zeabur Open Source, your workloads stay in place, and you can keep managing them with kubectl, Helm, or your existing GitOps tools³². To revoke a user's access, change the corresponding RBAC bindings.

Zeabur Open Source and Zeabur Identity are both public on GitHub. If you're interested, try installing them on a single server.