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.
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.
The following access rules are created automatically:
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.
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
Go to the RBAC tab of the required Hosted Kubernetes cluster.
Select Access Policies.
Click the required policy name.
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.
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.
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:
Go to the RBAC tab of the required Hosted Kubernetes cluster.
Select Access Policies.
Under Custom policies, click Create custom policy.
Configure the required permissions.
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:
Select Access Rules.
Under Grant cluster access, enter a Binding name.
Under Who, select one of the following:
Group – Grant access to a group.
User – Grant access to an individual user.
Select the required group or user.
Under Access policy, select the policy to assign.
Under Where, select the access scope:
Entire cluster – Grants access across the cluster.
Specific namespace – Restricts access to a specific namespace.
Review the Binding preview to verify the selected subject, policy, and scope.
Click Grant access.
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:
Assign Permissions
Bind the service account to the required permissions using a standard Kubernetes ClusterRole or a custom Role/ClusterRole.
For example:
Generate a Service Account Token
Generate a token for the service account:
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.
Revoke Cluster Access
You can revoke an existing access rule from the Active access rules section.
Go to RBAC > Access Rules.
Locate the access rule that you want to remove.
Click Revoke in the Actions column.
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.
Last updated