> For the complete documentation index, see [llms.txt](https://docs.acecloud.ai/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.acecloud.ai/knowledge-base/kubernetes-hosted/how-to-configure-rbac-for-a-hosted-kubernetes-cluster.md).

# How to Configure RBAC for a Hosted Kubernetes Cluster?

## **Overview**

Role-Based Access Control (RBAC) in Hosted Kubernetes allows you to control who can access a Kubernetes cluster and what actions they can perform.

The **RBAC** tab provides two options:

* **Access Policies** – View standard policies and create custom policies.
* **Access Rules** – Grant and revoke cluster access for users or groups by assigning an access policy.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2Fzd76sUIzfS5nS14TJXxY%2Funknown.png?alt=media\&token=7055dc85-6ef7-47e5-a1c5-08328a01a1b2)

## **Default Access When a Cluster Is Created**

When a Hosted Kubernetes cluster is created, AceCloud automatically creates two default access rules to ensure that the cluster is accessible immediately after creation.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FK7SiSTzdZXKQf15jgXW3%2Funknown.png?alt=media\&token=2baf1188-7bad-4c14-9bc3-2eded3a8576c)

The following access rules are created automatically:

1. **Admins Group Access** An access rule is created for the **Admins** group with the **acecloud:cluster-admin** policy. Users who are members of the **Admins** group in the AceCloud portal automatically receive cluster-admin access to newly created Hosted Kubernetes clusters.
2. **Cluster Creator Access** A separate access rule is created for the **user who created the cluster**, also with the **acecloud:cluster-admin** policy. This ensures that users who can create clusters but are not members of the **Admins** group can access and manage the cluster they created.

Both access rules are displayed under **RBAC > Access Rules > Active access rules** and use the same **Binding Name**, **Subject**, **Policy**, and **Scope** fields as user-created access rules.

You can **review and revoke** these default access rules.

## **Access Policies**

The **Access Policies** tab displays the policies available for the cluster.

### **Standard Policies**

Standard policies are applied automatically and cannot be modified from the cluster.

The following standard policies are available:

| **Policy**        | **Kind**     | **Scope** |
| ----------------- | ------------ | --------- |
| **Admin**         | Cluster Role | Cluster   |
| **Cluster Admin** | Cluster Role | Cluster   |
| **Editor**        | Cluster Role | Cluster   |
| **Viewer**        | Cluster Role | Cluster   |

The **Rules** column displays the number of permission rules associated with each policy. To view the specific permissions and actions allowed by a policy, select the policy to view its detailed rules.

## **View Policy Details and Permissions**

You can view the permissions associated with any **standard** or **custom policy** from the **Access Policies** tab.

### **View Policy Details**

1. Go to the **RBAC** tab of the required Hosted Kubernetes cluster.
2. Select **Access Policies**.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FDKt19vHJqCYdghpv1DXy%2Funknown.png?alt=media\&token=b8081670-afb8-4f25-a1d8-d18b4019cd7a)

3. Click the required policy name.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FrYZjuqsk5HaKArPOn68Z%2Funknown.png?alt=media\&token=e5aebf7e-6684-4392-b85b-26c9ed03ffc0)

4. Review the policy details, including:

* **Kind** – The type of policy, such as **Cluster Role**.
* **Scope** – The scope to which the policy applies.
* **Namespace** – The namespace associated with the policy, or **Cluster-scoped** if the policy is not limited to a specific namespace.
* **Created At** – The date and time when the policy was created.
* **Permission Rules** – The individual rules that define the permissions granted by the policy.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FdqdboGvisvrY3gRwBzaZ%2Funknown.png?alt=media\&token=4d92beb3-5f6c-4587-8309-15440859dbfd)

AceCloud provides four standard access policies: **Viewer, Editor, Admin, and Cluster Admin**. Each policy consists of one or more permission rules that define the Kubernetes **API Groups**, **Resources**, and **Verbs** available to the policy.

Click a policy name to view its permission rules and understand the exact access it provides.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FSrrv8amQLPLcsuSAKrFv%2Funknown.png?alt=media\&token=bf6f5ac3-26e1-42d5-8a6d-69658e7bd21d)

#### **Viewer**

The **Viewer** policy consists of **7 permission rules** and provides **read-only access** to Kubernetes resources.

It allows the **get**, **list**, and **watch** operations on resources such as:

* Pods, services, endpoints, ConfigMaps, persistent volume claims, replication controllers, service accounts, events, and namespaces.
* Deployments, ReplicaSets, StatefulSets, and DaemonSets.
* Jobs and CronJobs.
* Horizontal Pod Autoscalers.
* Ingresses, IngressClasses, and NetworkPolicies.
* EndpointSlices.
* Pod and node metrics.

The policy does not grant permissions to create, update, patch, or delete these resources.

**Use Viewer when:** Users need to monitor and inspect cluster workloads and resources without making changes.

#### **Editor**

The **Editor** policy consists of **7 permission rules** and provides permissions for day-to-day workload and application management.

It covers resources such as:

* Pods, pod logs, pod execution and attachment, port forwarding, services, service proxies, endpoints, ConfigMaps, persistent volume claims, replication controllers, and events.
* Deployments, deployment scaling, ReplicaSets, ReplicaSet scaling, StatefulSets, StatefulSet scaling, and DaemonSets.
* Jobs and CronJobs.
* Horizontal Pod Autoscalers.
* PodDisruptionBudgets.
* Ingresses and NetworkPolicies.

Most of these rules use the wildcard (\*) for **Verbs**, allowing operations such as getting, creating, updating, and deleting the applicable resources. EndpointSlices are limited to **get**, **list**, and **watch** operations.

**Use Editor when:** Users need to deploy, modify, scale, and manage workloads and related networking resources.

#### **Admin**

The **Admin** policy consists of **10 permission rules**. It provides the workload-management capabilities of Editor and extends access to additional resources required for broader namespace-level administration.

In addition to workload, networking, autoscaling, and policy resources, Admin provides permissions for resources such as:

* **Service accounts**
* **Resource quotas**
* **Limit ranges**
* **Roles**
* **RoleBindings**

These permissions allow an administrator to manage workloads as well as access and resource configuration within the applicable namespace.

**Use Admin when:** Users require extensive control over workloads and namespace-level configuration, including managing service accounts, resource quotas, and RBAC permissions.

#### **Cluster Admin**

The **Cluster Admin** policy consists of **2 permission rules**. Both rules use the wildcard (\*) for **API Groups**, **Resources**, and **Verbs**.

This provides unrestricted access to Kubernetes resources and operations across the cluster, including **cluster-level and node-level resources** that are not covered by the Viewer, Editor, or Admin policies.

**Use Cluster Admin when:** A trusted administrator requires complete control over the Kubernetes cluster.

**Important:** The number of permission rules shown in the **Rules** column indicates how many rules make up a policy; it does not, by itself, indicate the level or scope of access. Click the policy name to review the individual **API Groups, Resources, and Verbs** and determine exactly what the policy permits.

### **Permission Rules**

The **Permission Rules** section displays each rule associated with the policy and includes:

* **API Groups** – The Kubernetes API groups to which the rule applies.
* **Resources** – The Kubernetes resource types covered by the rule, such as Pods, Deployments, and Secrets.
* **Verbs** – The actions permitted on the specified resources, such as get, list, create, and delete.

**Note:** Review the permission rules of a policy before assigning it to a user or group. The policy name alone may not fully describe the permissions currently defined for it.

**Policy Scope**

The policy itself does not determine whether access is granted to the entire cluster or a specific namespace. The access scope is selected when the policy is assigned through **Access Rules**.

When granting access, you can select:

* **Entire cluster** – Applies the policy across the cluster.
* **Specific namespace** – Limits the policy assignment to the selected namespace.

Follow the **principle of least privilege** by assigning the minimum level of access required for a user's responsibilities and, where possible, limiting access to the required namespace. For example, assign **Viewer** access to a specific namespace when a user only needs read-only visibility into that namespace.

### **Custom Policies**

You can create custom policies to define your own permission sets according to your requirements.

To create a custom policy:

1. Go to the **RBAC** tab of the required Hosted Kubernetes cluster.
2. Select **Access Policies**.
3. Under **Custom policies**, click **Create custom policy**.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FDvohh95rmPoXdZgAkGGw%2Funknown.png?alt=media\&token=7b49b304-aefd-4470-b7c3-26dda6721521)

4. Configure the required permissions.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FA2hFOcEmmURA5lYbyfh3%2Funknown.png?alt=media\&token=1d264ca1-47b8-430a-9441-587f10334994)

5. Save the custom policy.

The created policy is then available for assignment through **Access Rules,** and like any policy you can reopen it later to review exactly which permission rules it contains.

## **Grant Cluster Access**

The **Access Rules** tab allows you to assign an access policy to a user or group.

To grant access:

1. Select **Access Rules**.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FRfiMhjuek2fXGSElc8FR%2Funknown.png?alt=media\&token=ec06305d-8992-4ce4-9503-ab9599f54b0c)

2. Under **Grant cluster access**, enter a **Binding name**.
3. Under **Who**, select one of the following:

* **Group** – Grant access to a group.
* **User** – Grant access to an individual user.

4. Select the required group or user.
5. Under **Access policy**, select the policy to assign.
6. Under **Where**, select the access scope:

* **Entire cluster** – Grants access across the cluster.
* **Specific namespace** – Restricts access to a specific namespace.

7. Review the **Binding preview** to verify the selected subject, policy, and scope.
8. Click **Grant access**.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FjSfwQFaerP6XOk5ZkqQT%2Funknown.png?alt=media\&token=8490a9d2-9d6f-4d70-81f3-e993f9640064)

The new binding is added to the **Active access rules** section.

## **Use a Kubernetes Service Account for Automation and Shared Access**

**Access Policies** and **Access Rules** are intended for individual users and groups managed through AceCloud IAM. They are not recommended for:

* CI/CD pipelines and automation scripts.
* Shared credentials used simultaneously by multiple users or systems.

Access granted through the AceCloud portal is associated with a user's personal KubeConfig. The associated credential is automatically renewed and rotated in the background. This mechanism is designed for individual user access and should not be used for shared credentials.

If the same KubeConfig is used by multiple users, scripts, or systems, credential rotation can cause authentication failures when different clients attempt to use or refresh the credential.

For automation or shared access, create a Kubernetes **service account** in the cluster and assign the required permissions using native Kubernetes RBAC.

### **Create a Service Account**

Create the service account in the namespace where it needs to operate:

```
kubectl create serviceaccount ci-deployer -n my-namespace
```

### **Assign Permissions**

Bind the service account to the required permissions using a standard Kubernetes ClusterRole or a custom Role/ClusterRole.

For example:

```
kubectl create rolebinding ci-deployer-edit \
--clusterrole=edit \
--serviceaccount=my-namespace:ci-deployer \
--namespace=my-namespace
```

### **Generate a Service Account Token**

Generate a token for the service account:

```
kubectl create token ci-deployer -n my-namespace --duration=8760h
```

Use the generated token as the bearer credential in the automation's dedicated KubeConfig instead of using a personal, portal-issued KubeConfig.

**Note:** A service account provides an identity that is independent of an individual user's portal session. This keeps automation access separate from personal user access and prevents automation from depending on changes to an individual user's permissions or account status.

## **How Multiple Access Rules Combine**

RBAC permissions are **additive**. Kubernetes RBAC does not use explicit deny rules.

If a user receives permissions through multiple access rules, the permissions from all applicable bindings are combined.

For example, if a user:

* Receives **Viewer** access through a group binding, and
* Receives **Editor** access through an individual binding,

the user receives the combined permissions provided by both bindings.

A narrower or more restrictive binding does not override a broader binding. Therefore, assigning an additional broad or cluster-wide policy can provide more access than intended.

**Note:** Before granting access, review the user's existing group and individual bindings to ensure that the combined permissions provide only the access required for their role.

## **View Active Access Rules**

The **Active access rules** section displays the access bindings currently configured for the cluster.

The table includes information such as:

* **Name** – Name of the access binding.
* **Subject** – User or group assigned to the policy.
* **Policy** – Access policy assigned to the subject.
* **Scope** – Whether access applies cluster-wide or to a specific namespace.
* **Granted On** – Time when the access was granted.
* **Actions** – Available action for the access rule.

Use the search field to search for a specific subject, policy, or access rule.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2FuHYGO4hNUoCcQpNytz4e%2Funknown.png?alt=media\&token=0ccd97fb-6740-4c78-a12e-03cb2778406f)

## **Revoke Cluster Access**

You can revoke an existing access rule from the **Active access rules** section.

1. Go to **RBAC > Access Rules**.
2. Locate the access rule that you want to remove.
3. Click **Revoke** in the **Actions** column.

![](https://315001803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4J4izUBTSuiTE14qXBAP%2Fuploads%2Favigt8mXAm38xoK0tzHJ%2Funknown.png?alt=media\&token=d58c3132-370e-4522-b90a-3e4c89aa1b8c)

4. Confirm the action.

The access rule is removed, and the associated user or group no longer has access through that binding.

**Note:** The access revocation may take up to **15 minutes** to take effect when the user's access token is refreshed. For the change to take effect immediately, revoke the user's **KubeConfig** from **IAM** and ask the user to download a new KubeConfig from the AceCloud portal.

**Note:** Assign permissions according to the user's or group's responsibilities. Use namespace-specific access where cluster-wide permissions are not required.