Connection methods

Registering a cluster is admin only. The decision you make is how Seylo reaches it.

Method	Reaches a private cluster	Seylo holds a credential	Use when
In-cluster agent	Yes	No	Almost always
azure (AKS)	No	Yes	You own the subscription and the API server is reachable
aws (EKS)	No	Yes	Same, for EKS
gcp (GKE)	No	Yes	Same, for GKE
oci (OKE)	No	Yes	Same, for OKE
existing-context	No	Yes	A kubeconfig context already on the server
paste	No	Yes	A kubeconfig you paste in

Short version

Choose In-cluster agent unless you have a specific reason not to. It is the only method that works for a private cluster, the only one that leaves Seylo holding no credential for your cluster, and it is available for every provider.

Why the agent is the default recommendation

Every other method needs two things a distributed fleet cannot reliably give:

1. a network path from Seylo to the cluster’s API endpoint, and
2. credentials for that cluster, held by Seylo.

Private and firewalled clusters have no inbound path, and their owners frequently will not hand over cloud credentials. The agent inverts the connection: it runs inside your cluster, dials out over WSS, and authenticates to Kubernetes with its own ServiceAccount.

The consequence worth repeating: there is no cloud credential on our side to leak. See the trust model.

What is identical regardless of method

Everything above the transport. Approvals, roles, the audit trail, manifest editing, the dashboard matrix, environment comparison, rollout progress, scheduled deployments — all the same. A single place in the code decides “direct call” or “agent command”, and nothing above it knows which happened.

Credential-based methods

If you do use one, two rules apply:

• No CLI and no exec credential plugin, ever. Seylo does not shell out to az, aws, gcloud or oci, and it does not honour a kubeconfig exec block. Credentials are acquired through the provider SDKs or are static.
• Credentials are encrypted at rest and are never returned by any endpoint, page, log or export.

These methods cannot reach a cluster with no inbound path. For a private endpoint, the agent is not merely preferable — it is the only option.

Namespace policy

Independently of the method, each cluster carries an allow or deny list of namespaces. It applies to everyone equally — it is cluster configuration, not a per-user permission. For a boundary enforced by Kubernetes rather than by Seylo, use a namespace-scoped agent: see choose an RBAC posture.

Next

• Install the agent
• Choose an RBAC posture