yeke.io · docs
Connecting a cluster
There are two modes and exactly one difference between them: where the cluster credential lives. Everything else — the screens, the permissions, the operation chain — is identical.
Which mode
This is the only question Add cluster really asks you.
| Agent mode | Direct kubeconfig | |
|---|---|---|
| Where the credential lives | Stays in the cluster. It never reaches the centre. | In core, encrypted with AES-256-GCM. |
| Connection direction | Outbound WebSocket tunnel, cluster → core. | core → apiserver, directly. |
| If core is compromised | This cluster is not compromised. | This cluster counts as compromised too. |
| Setup | One kubectl apply in the cluster. | Uploading one file. |
| Precondition | YEKE_PUBLIC_URL must be correct. | — |
| Role separation | Works: the YEKE role maps to a Kubernetes group. | None — everyone acts as the same kubeconfig identity. |
Agent mode is the recommendation for clusters with a high confidentiality class. Role separation also only works out of the box there; in direct mode, if you want per-person separation, you write a personal binding.
Agent mode
A small agent is installed in the cluster and dials out to core on its own.
- 1 · Name the cluster on screen and choose an access mode (below).
- 2 · Run the given command against the target cluster — the manifest is served
from a URL carrying a single-use ticket:
kubectl apply -f "<the URL shown on screen>"
- 3 · The tunnel establishes itself. The cluster shows up as connected.
Two access modes
| Mode | What it does | When |
|---|---|---|
| Full | The agent may impersonate any username; the two groups matching YEKE's roles and their bindings are installed as well. | When you intend to manage the cluster through YEKE. |
| Restricted | The list of impersonable users and groups is written into the manifest; nothing outside it can be assumed. | When you want to draw the ceiling yourself. The list cannot be empty. |
The agent's own permissions are deliberately narrow: read, discovery
and impersonation. It has no write verb at all and no access to secrets. A user's
request does not run as the agent's ServiceAccount — the agent adds an impersonation
header and the apiserver makes its decision based on that identity. Details in
Permissions.
The mode can be changed later: rotating the agent token regenerates the manifest and drops the open tunnel — you then apply the new manifest.
Direct kubeconfig
The fastest path to set up; its price is stated plainly.
- 1 · Upload or paste the kubeconfig. If it holds several contexts you pick the one to use.
- 2 · YEKE measures the connection — it asks the apiserver who this credential is and puts the answer on screen. Not the configuration's claim: the apiserver's answer.
- 3 · Confirm. The confirmation card says outright that the credential will be stored in core.
There is no role separation in this mode: every YEKE user acts as the same kubeconfig identity and the apiserver's audit trail loses the distinction between people. YEKE's own trail still records who pressed the button. If you want that distinction at the cluster level, write a personal binding.
After connecting
- The inventory shows whether each cluster is connected, plus its Kubernetes and agent version.
- Permissions are the next step: connecting a cluster does not grant anyone the right to write to it.
Permissions come next.
The cluster is connected, but what anyone can actually do is still Kubernetes' decision. The next page is about exactly that.