SYS.DOCS // DOCS

Cluster Settings: Access & Security

Use Cluster Settings → Access to control who can see a cluster, which actions they can perform, and how credentials are issued.

What you can manage

The page is split into four areas:

Kubeconfig (personal): your own kubeconfig lifecycle.
Developer Permissions: per-cluster visibility and access levels for developers.
Team Access (organization admins): per-user kubeconfig management after credentials have been issued.
SSH Access: one-time private key download for node access.

How permissions work

Edka combines organization roles with cluster-level developer access.

Organization roles

Organization owners and admins always have full access to every cluster in the organization.
Developers only get access to clusters they own or clusters where they have been granted access explicitly.
A cluster owner is the user assigned to a specific cluster. This is separate from the organization-wide Owner role.

Cluster owner behavior

The cluster owner always keeps full write access to that cluster.
The cluster owner can manage Developer Permissions for that cluster.
Cluster owner access cannot be downgraded or removed from the Access page.

Cluster-level access for developers

Cluster-level permissions apply only to users with the organization role developer.

Access level	What it means
`No access`	The cluster is hidden from the developer in cluster lists, routes, and cluster-scoped features. Any active personal kubeconfig for that cluster is revoked.
`Read`	The developer can open the cluster and use read only features, but write actions are blocked. Their personal kubeconfig is issued with Kubernetes `view` access.
`Write`	The developer can manage that cluster in Edka for standard day-2 operations. Their personal kubeconfig is issued with Kubernetes `edit` access.

In practice, read is for observing and troubleshooting, while write is for day-2 operations such as updating non-sensitive cluster settings, managing workloads, editing secrets, and downloading the SSH key.

Who can manage what

Developer Permissions can be managed by the cluster owner and by organization owners/admins.
Team Access can only be managed by organization owners/admins.
Sensitive cluster actions are limited to the cluster owner and organization owners/admins. This includes enabling or disabling cluster protection, archiving or unarchiving a cluster, deleting a cluster, and setting, updating, or removing the cluster-specific Hetzner token.
Changing a developer from read to write, write to read, or no access revokes the developer’s current personal kubeconfig. They must download a new kubeconfig after access is restored or changed.

Sensitive actions for developers

If a developer has write access but is not the cluster owner, they can still perform normal operational tasks, but they cannot:

Change Cluster Protection
Archive or unarchive the cluster
Delete the cluster
Set, update, or remove the cluster-specific Hetzner API Token

These controls are available in Settings > General and Settings > Danger Zone.

Developer Permissions

Use Developer Permissions to decide whether a developer can see and operate a specific cluster.

This card shows:

The cluster owner, who always has write access.
Developers who currently have access.
Developers who are currently hidden from the cluster.

Use this card when you want to:

Grant a developer first-time access to a cluster.
Change a developer between Read and Write.
Remove a developer from the cluster entirely.

Use Team Access only after kubeconfig credentials have already been issued.

Personal kubeconfig

In the Kubeconfig card you can:

Download your personal kubeconfig.
Rotate credentials and immediately download a new kubeconfig.

Behavior and restrictions:

Kubeconfig download is available only when the cluster is active.
If your kubeconfig access is revoked, downloads are blocked.
Rotating invalidates your current kubeconfig immediately.
Your kubeconfig scope follows your effective access:
- organization owners/admins receive Kubernetes cluster-admin
- developers with write receive Kubernetes edit
- developers with read receive Kubernetes view

Team Access (organization admin only)

If you are an organization owner or admin, the Team Access card lets you manage credentials for other users:

View user credential versions and download status.
Rotate a user’s kubeconfig credentials.
Revoke a user’s kubeconfig access.
Toggle Show revoked to include revoked credentials in the list.

Notes:

This card manages issued credentials, not cluster visibility.
Rotate and Revoke actions apply to the latest credential version for a user.
Revoked users cannot download kubeconfig until access is restored.

SSH access

The SSH Access card lets you download the cluster SSH private key and copy a command template:

ssh -i ssh-key-<cluster-name>.pem root@<node-ip>

Important:

SSH private keys are download-once for security.
SSH private key download requires write access to the cluster.
After download, the UI shows download timestamp and a security notice.

Warnings and archived clusters

The page shows an Access Revoked warning when your personal kubeconfig access is revoked.
Kubeconfig generation, rotation, and SSH key download are disabled for archived clusters.