Skip to main content

K8s RBAC Management

Runtime Environment - Permissions Tab

"Want the dev team to only access the dev namespace, and the ops team to only access the prod namespace?" KIOPS's RBAC management feature lets you finely control Kubernetes cluster access by team and role.

Why is RBAC Important?

Giving all users full cluster access increases the risk of accidents causing outages. RBAC helps you grant "only the permissions needed to those who need them," improving security and stability.

What is RBAC?​

RBAC (Role-Based Access Control) is how Kubernetes defines "who can do what." Think of it like a company's access card system. Just as each employee can only access their department and necessary spaces, RBAC ensures users can only access the resources they need.

KIOPS's RBAC Structure​

KIOPS manages RBAC under [Runtime Environments] > select a Kubernetes cluster > Permission Management tab, which consists of the following 4 sub-tabs.

  • Service Accounts (RBACManagementTab): Directly queries, creates, and deletes ServiceAccounts on the cluster. When a SA is created, it is created on the cluster immediately via SSH (there is no separate createInCluster flag in this sub-tab).
  • Permission Bindings: Manages RoleBindings/ClusterRoleBindings for ServiceAccounts.
  • Permission Templates: Provides permission templates mapped to default ClusterRoles such as cluster-admin / admin / editor / viewer.
  • Unified Account Management (KiwiSAManagementTab, cluster-admin only): Manages the ServiceAccounts stored in the KIOPS DB along with namespace bindings, user assignments, and cluster synchronization. The SA creation modal in this sub-tab exposes the createInCluster flag, which controls whether the SA is registered only in the KIOPS DB or also created on the cluster.

Permission Levels​

The permission templates used in KIOPS map to Kubernetes default ClusterRoles.

  • cluster-admin: All permissions across the entire cluster. Grant only to cluster administrators.
  • admin: Can manage all resources within a namespace. Suitable for operations teams or administrators.
  • editor: Can create/modify/delete resources but cannot change RBAC settings. Suitable for development teams.
  • viewer: Read-only access. Suitable for monitoring or auditing.
Principle of Least Privilege

For security, follow the "principle of least privilege." Granting users only the minimum permissions they need minimizes damage from mistakes or malicious actions.

Prerequisites​

  • A Kubernetes cluster must be registered in KIOPS

Permission Notice: If you cannot access this feature, please request permission from your organization manager.

Permission Management Tab (RBAC Management)​

The Permission Management tab is located at [Runtime Environments] > select a Kubernetes cluster > Permission Management. It works directly with the cluster's ServiceAccount, RoleBinding, ClusterRole, and other RBAC resources.

Step 1: Navigate to the Permission Management Tab​

  1. Click [Runtime Environments] in the left menu.
  2. Select the target Kubernetes cluster.
  3. Click the Permission Management tab on the cluster detail page.

Step 2: Create a Service Account​

  1. In the Service Accounts sub-tab, click the Add button.
  2. Enter SA information:
    • Name: ServiceAccount name (e.g., developer-sa)
    • Namespace: When the modal opens, the cluster's actual namespaces are queried over SSH and shown in a dropdown.
    • Description: Purpose of the SA
  3. Click the Create button — the ServiceAccount is created on the cluster immediately via SSH.
Service Account Creation Behavior

The Service Accounts sub-tab of the Permission Management tab does not expose a createInCluster flag; SAs are created directly on the cluster via SSH at creation time. The flow of registering an SA only in the KIOPS DB and syncing it to the cluster later is provided by the Unified Account Management sub-tab (below).

Step 3: Create RoleBindings From Permission Templates​

The fastest way to create a permission binding is to start from the Permission Templates sub-tab.

  1. In the Permission Templates sub-tab, click a template card to use (cluster-admin / admin / editor / viewer).
  2. In the modal, select the ServiceAccount to bind.
  3. Choose the namespace or cluster scope to apply.
  4. Click Create — a RoleBinding (or ClusterRoleBinding) is created and the result is visible in the Permission Bindings sub-tab.

Step 4: System Resource Protection​

  • System ServiceAccounts (e.g., default, kube-*) and system namespaces (kube-system, kube-public, etc.) are protected against deletion.
  • If you attempt to delete them, the UI shows a warning and the operation is blocked.

Unified Account Management Tab (cluster admin only)​

The Unified Account Management tab is a separate screen accessible only to cluster admins. It manages the relationship between SAs in the KIOPS DB and KIOPS users.

Step 1: Navigate to the Unified Account Management Tab​

  1. From [Runtime Environments] > select a Kubernetes cluster > Permission Management, click the Unified Account Management sub-tab.
  2. Users without cluster-admin permission do not see this sub-tab.

createInCluster flag in the Unified Account Management sub-tab: In this sub-tab's SA creation modal, enabling createInCluster registers the SA in the KIOPS DB and creates the ServiceAccount on the cluster immediately; disabling it registers the SA in the KIOPS DB only, to be synced to the cluster later.

Step 2: Assign SA to User​

  1. Search for the user to assign.
  2. Click the Assign SA button on the user row.
  3. Select the ServiceAccount to assign.
  4. Set the Expiration Date (expiresAt). The assignment is automatically revoked when the date passes.
  5. Click the Assign button.

Step 3: Sync to Cluster​

  1. When user assignments change, the cluster-side tokens/bindings must be synced.
  2. Click the Sync to Cluster button — KIOPS applies the changes to the cluster over SSH.

SA and Binding Management​

Modify ServiceAccount​

  1. Click the target SA in the SA list.
  2. Click the Edit button to modify the description or bindings.
  3. Click Save to apply.

Remove Namespace Binding​

  1. Open the SA details and review the binding list.
  2. Click the Delete button next to the binding to remove.

Unassign User SA​

  1. Find the target user in the Unified Account Management tab.
  2. Click the Unassign button.
  3. Click Unassign in the confirmation dialog.

Delete ServiceAccount​

  1. Select the target SA in the SA list and click the Delete button.
  2. If the SA has been synced to the cluster, two options are presented:
    • Delete in DB Only: Removes the SA only from the KIOPS DB; the cluster ServiceAccount is left intact.
    • Delete in Cluster Too: Removes the ServiceAccount from both the KIOPS DB and the cluster.
  3. Choose the appropriate option and click Delete.
SA Deletion Impact

Deleting an SA immediately removes access for users assigned to that SA.

Check My K8s Permissions (Estimated)​

Estimated: The menu location below may vary by KIOPS UI version.

Users are expected to be able to check their assigned K8s permissions. For the exact menu location, please ask your operations team.

Information likely to be displayed:

  • Cluster: List of accessible K8s clusters.
  • ServiceAccount: ServiceAccount name assigned in each cluster.
  • Namespaces: List of namespaces accessible through the SA.
  • Role: Permission level for each namespace.

Practical Use Scenarios​

Scenario 1: Grant Namespace Access to Development Team​

Situation: Grant edit permission for the dev namespace to 3 development team members.

Steps:

  1. In the Service Accounts sub-tab of the Permission Management tab, create SA dev-team-sa (created on the cluster immediately via SSH).
  2. In the Permission Templates sub-tab, click the editor card → select dev-team-sa → apply to the dev namespace.
  3. In the Unified Account Management sub-tab, assign dev-team-sa to 3 development team users (set expiration dates).

Scenario 2: Operations Team Multi-Namespace Management​

Situation: Grant management permissions for prod and staging namespaces to the operations team.

Steps:

  1. In the Service Accounts sub-tab of the Permission Management tab, create SA ops-team-sa (created on the cluster immediately via SSH).
  2. In the Permission Templates sub-tab, click the admin card → select ops-team-sa → apply to prod.
  3. In the Permission Templates sub-tab, click the admin card → select ops-team-sa → apply to staging.
  4. In the Unified Account Management sub-tab, assign ops-team-sa to operations team users.

Troubleshooting​

SA Sync Failure​

  • When permission error occurs: The ServiceAccount used by KIOPS lacks permissions to create RBAC resources. Request ClusterRole and RoleBinding creation permissions from the cluster administrator.
  • When namespace not found: The namespace you're trying to bind doesn't exist in the cluster. Create the namespace first and try again.
  • When connection failure occurs: There's a network connection issue with the cluster. Check the cluster connection status on the Runtime Environment page and reconnect if necessary.

User Cannot Access Resources​

  • Cause 1: SA not assigned → Verify the SA assignment in the Unified Account Management tab.
  • Cause 2: Expiration date passed → Renew the expiration or reassign.
  • Cause 3: Cluster not synced → Click the Sync button.

Security Recommendations​

Security best practices for operating RBAC safely.

Security is an Ongoing Process

RBAC configuration isn't a one-time setup. Review and update it regularly.

  1. Principle of Least Privilege: Grant users only the minimum permissions they need. Don't give extra permissions "just in case."

  2. Regular Review: Review SA assignments and bindings quarterly. Clean up permissions that are no longer needed due to departures or project completions.

  3. Use Expiration Dates: When assigning SAs to users, set expiration dates whenever possible so that permissions are automatically revoked.

  4. Audit Log Review: Regularly check RBAC changes. Monitor for any abnormal modifications.

  5. Namespace Separation: Separating namespaces by environment (dev, staging, prod) minimizes the impact of mistakes.