Core Concepts

Octokube is built around four core concepts. Understanding them will make everything else in these docs — from configuring access rules to reading the architecture diagram — much easier to follow.

Agent

The Agent is a lightweight component you deploy once inside your Kubernetes cluster. It is the only piece of Octokube that ever communicates directly with the kube-apiserver.

Once running, the Agent:

• Opens a persistent watch connection to the apiserver for each resource type
• Maintains a live, in-memory representation of your cluster state
• Streams updates to the Octokube backend over a single outbound connection
• Responds to snapshot requests when a client needs a full state sync

No developer ever connects to your cluster directly. Every request is brokered through the Agent. No credentials leave your infrastructure.

Virtual RBAC

Virtual RBAC is a permission layer that sits on top of native Kubernetes RBAC. It lets you define access rules that the cluster itself cannot express — without modifying any cluster-level roles or redeploying anything.

With Virtual RBAC you can:

• Grant access by user, team, namespace, and resource type
• Restrict access to specific resources by name
• Define time-based access windows — for example, read-only access between 09:00 and 18:00
• Apply changes instantly, with no cluster modifications required

Virtual RBAC does not replace native Kubernetes RBAC. It operates as an additional layer above it, enforced by the Octokube backend before any data reaches the client.

Real-Time Multiplexing

When the Agent streams cluster state to the Octokube backend, that stream is multiplexed — delivered simultaneously to every team member connected to that cluster.

This means:

• One persistent Agent connection serves your entire team, regardless of size
• Each team member receives only the data their Virtual RBAC rules allow
• Cluster state changes propagate in sub-second time across all connected clients
• Your kube-apiserver sees no additional load as your team grows

The backend handles versioning and gap detection automatically. If a client misses an update, it requests a full state snapshot and resumes from there.

Web IDE

The Web IDE is the browser-based interface your team uses to interact with Octokube. It connects to the backend over a persistent socket and applies incoming updates incrementally as cluster state changes.

Each engineer sees a fully personalized view — scoped to exactly the resources and actions their Virtual RBAC rules permit. There is no shared screen, no admin proxy, and no risk of one user seeing another's restricted resources.

The Web IDE requires no local setup. No kubectl, no kubeconfig, no VPN. Any engineer with a browser and an Octokube account can be up and running in minutes.

How they fit together

Your Cluster
     │
  [ Agent ]  ←── watches kube-apiserver
     │             maintains in-memory state
     │
  [ Backend ] ←── applies Virtual RBAC per user
     │             multiplexes to all connected clients
     │
  [ Web IDE ] ←── each engineer sees their scoped view
                   updated in real time

The Agent owns the cluster state. The Backend owns access control and distribution. The Web IDE owns what each engineer sees and does. Each layer has a single, well-defined responsibility.

Next steps

• Read the Architecture page for a deeper look at how these pieces communicate
• Go to Quickstart to deploy the Agent and connect your first cluster