Manage access and tenancy

Grant a person or team exactly the RBAC they need, in exactly the clusters they should reach, through OIDC identities, with no shared admin credential and without giving out admin rights.

Prerequisites#

• kubectl configured to reach the workload cluster.
• An OIDC provider connected. OIDC (OpenID Connect) is a standard that lets users sign in through an external identity provider. See Configure OIDC .

The access model#

Access on Syself Autopilot works in layers, each adding a level of protection.

Layer 1: the API server is hardened by default#

Every workload cluster's API server ships with these settings locked in:

• authorization-mode: Node,RBAC: the Node authorizer limits what a kubelet (the agent running on each node) can read or write for its own node. Everything else goes through RBAC (Role-Based Access Control, Kubernetes' standard system for controlling who can do what).
• NodeRestriction admission: a kubelet can only modify its own Node and the pods bound to it. It cannot tamper with other nodes.
• EventRateLimit admission: API events are rate-limited per namespace and per user. A noisy or hostile client cannot flood the API server or etcd (the database that holds all cluster state).
• anonymous-auth: false: the API server rejects unauthenticated requests.
• profiling: false: the debug profiling endpoints are off.

You do not configure these. They are on by default in every cluster.

Layer 2: grant users least-privilege access#

Do not hand out raw kubeconfig files or cluster-admin. Users sign in with their OIDC identity, and you grant them standard Kubernetes RBAC bound to their OIDC groups. Membership lives in your identity provider, so you add and remove people there, not per cluster.

• Define a Role or ClusterRole with exactly the verbs, resources, and apiGroups the task needs. A Role is scoped to a namespace; a ClusterRole covers all namespaces. Prefer the narrower one.
• Bind it to an OIDC group with a RoleBinding (namespaced) or ClusterRoleBinding (cluster-wide). The binding names a group your IdP already manages, so it stays stable as people join and leave.
• Keep the scope tight. Read-only access for auditors and on-call. Manage-workloads access (deployments, services, ingress, config, secrets, PVCs) for developers, with no access to nodes or StorageClasses. Grant cluster management separately from cluster use.

The result: users get exactly the RBAC the role grants, in exactly the clusters where you bound it. There is no shared admin credential.

Layer 3: every cluster has its own control plane#

The strongest isolation boundary is structural, not a permission check: every workload cluster has its own API server, its own etcd, and its own certificate authorities, with nothing shared across tenants. An RBAC mistake or an authorization bug in one cluster reaches, at worst, that one cluster, because there is no shared authority for it to cross through. Multi-tenant isolation for agencies covers this boundary in full, and when to share a cluster instead.

The guardrails above work the same way, per cluster. Layer 1 hardening runs inside each cluster's own API server, RBAC bindings apply only in the cluster you create them in, certificates chain to the cluster's own CA so a credential from one cluster is rejected by every other, and even the entry point is per cluster: KubeGate verifies gate tickets against each cluster's own CA.

One boundary does cross clusters: the management cluster Syself operates, whose access is limited but not zero. What Syself can and cannot do describes that boundary in full, and running a dedicated management cluster in your own account closes it.

Step 1: write a least-privilege role#

Define a Role for the namespace the task needs, or a ClusterRole only when the access must span every namespace. Use the same verbs, resources, and apiGroups you know from any Kubernetes role, and keep it as narrow as the task allows. Read-only for auditors, manage-workloads for developers, and nothing touching nodes or StorageClasses unless the job requires it.

Step 2: bind it to an OIDC group#

Bind the role to a group your OIDC provider manages, with a RoleBinding for a namespaced Role or a ClusterRoleBinding for a ClusterRole. Apply it with kubectl against the workload cluster. Because the subject is a group, you manage who is in it from your IdP, not by editing the cluster.

Step 3: verify#

Have the user confirm what they can and cannot do:

		$ kubectl auth whoami                           # confirm identity: OIDC username + groups
$ kubectl auth can-i list pods -n team-a        # expect: yes (within scope)
$ kubectl auth can-i delete nodes               # expect: no (out of scope)
$ kubectl auth can-i '*' '*' --all-namespaces   # expect: no (not cluster-admin)
	

can-i reads the same RBAC the API server enforces. It is the authoritative check.

Rules that keep access least-privilege#

• Grant namespaced access, not cluster-wide, whenever possible. Scope a rule to specific namespaces with a Role and RoleBinding. Use a ClusterRole and ClusterRoleBinding only when the access must span all namespaces. Prefer the narrower form.
• Bind to groups, not individuals. Manage membership in your IdP. The binding stays stable as people join and leave.
• Never grant system:masters or kubeadm:cluster-admins. Those groups are for the platform, not tenants.
• Separate cluster use from cluster management. Permission to run workloads is different from permission to edit or delete the cluster itself. Grant them separately.