Contact UsGet started
© 2025 Direct Cursus Technology L.L.C.

Access management in Managed Service for Kubernetes

Written by
Improved by
Updated at November 11, 2025

In this section, you will learn about:

Access management

Yandex Identity and Access Management checks all operations in Yandex Cloud. If an entity does not have required permissions, IAM returns an error.

To grant permissions for a resource, assign the relevant resource roles to an entity performing operations. You can assign roles to a Yandex account, service account, local user, federated user, user group, system group, or public group. For more information, see How access management works in Yandex Cloud.

To assign roles for a resource, you need to have one of the following roles for that resource:

  • admin
  • resource-manager.admin
  • organization-manager.admin
  • resource-manager.clouds.owner
  • organization-manager.organizations.owner

Resources you can assign a role for

You can assign a role to an organization, cloud, or folder. The roles assigned to organizations, clouds, and folders also apply to their nested resources.

You can also assign a role for a separate cluster.

Roles this service has

The chart below shows service’s roles and their permission inheritance. For example, editor inherits all viewer permissions. You can find role descriptions below the chart.

Roles required to access the Kubernetes API

The following roles give the permission to manage Managed Service for Kubernetes cluster resources via the Kubernetes API. Roles of the Kubernetes API employ the role-based access control (RBAC) model. To manage a Managed Service for Kubernetes cluster, combine these roles with roles for the Yandex Cloud API. Learn more about roles in the Kubernetes RBAC in this Kubernetes guide.

To view permissions for Managed Service for Kubernetes cluster resources available for a specific role, run this command:

kubectl describe clusterrole <role_in_Kubernetes_RBAC>

k8s.cluster-api.viewer

Users with the k8s.cluster-api.viewer role get the yc:viewer group and the view role in Kubernetes RBAC for all namespaces in a cluster.

k8s.cluster-api.editor

Users with the k8s.cluster-api.editor role get the yc:editor group and the edit role in Kubernetes RBAC for all namespaces in a cluster.

k8s.cluster-api.cluster-admin

Users with the k8s.cluster-api.cluster-admin role get the yc:admin group and the cluster-admin role in Kubernetes RBAC.

Managed Service for Kubernetes roles

The roles described below allow you to manage Managed Service for Kubernetes clusters and node groups without public access via the Yandex Cloud API. To manage Managed Service for Kubernetes cluster resources, combine these roles with roles for the Kubernetes API. When creating a Managed Service for Kubernetes cluster, the roles of its service account are verified.

To manage a Managed Service for Kubernetes cluster and a node group without public access, you need the k8s.clusters.agent role.

To manage a Managed Service for Kubernetes cluster and a node group with public access, you need the following roles:

  • k8s.clusters.agent
  • vpc.publicAdmin

To manage a Managed Service for Kubernetes cluster with a cloud network from a different folder, you will additionally need the following roles in this folder:

To manage a Managed Service for Kubernetes cluster with tunnel mode, you only need the k8s.tunnelClusters.agent role.

k8s.viewer

The k8s.viewer role enables you to view information about Kubernetes clusters and node groups.

k8s.editor

The k8s.editor role enables you to create, delete, edit, stop, and start Kubernetes clusters and node groups.

It includes the k8s.viewer role.

k8s.admin

The k8s.admin role enables you to create, delete, edit, stop, and start Kubernetes clusters and node groups.

It includes the k8s.editor role.

k8s.tunnelClusters.agent

k8s.tunnelClusters.agent is a special role for creating Kubernetes clusters with tunnel mode. It enables you to create node groups, disks, and internal load balancers. You can use previously created Yandex Key Management Service keys to encrypt and decrypt secrets. It includes the following roles:

  • compute.admin
  • iam.serviceAccounts.user
  • k8s.viewer
  • kms.keys.encrypterDecrypter
  • load-balancer.privateAdmin

k8s.clusters.agent

k8s.clusters.agent is a special role for the Kubernetes cluster service account. It enables you to create node groups, disks, and internal load balancers. You can use previously created Yandex Key Management Service keys to encrypt and decrypt secrets and connect previously created security groups. When combined with the load-balancer.admin role, it enables you to create a network load balancer with a public IP address. It includes the following roles:

  • k8s.tunnelClusters.agent
  • vpc.privateAdmin

Primitive roles

viewer

The viewer role grants the permissions to read the info on any Yandex Cloud resources.

This role includes the auditor permissions.

Unlike auditor, the viewer role provides access to service data in read mode.

editor

The editor role provides permissions to manage any Yandex Cloud resources, except for assigning roles to other users, transferring organization ownership, removing an organization, and deleting Key Management Service encryption keys.

For instance, users with this role can create, modify, and delete resources.

This role includes the viewer permissions.

admin

The admin role enables assigning any roles, except for resource-manager.clouds.owner and organization-manager.organizations.owner, and provides permissions to manage any Yandex Cloud resources (except for transferring organization ownership and removing an organization).

Prior to assigning the admin role for an organization, cloud, or billing account, make sure to check out the information on protecting privileged accounts.

This role includes the editor permissions.

Note

With the Kubernetes RBAC, you can provide users with granular access to cluster namespaces.

Example

  1. In your cluster, create a role to manage all resources in the specified namespace:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: <namespace>
  name: <role_name>
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

  2. Bind this role to a user account:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: iam-user
  namespace: <namespace>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <role_name>
subjects:
- kind: User
  name: <account_ID>

To learn more about getting the account ID, see Getting user information.

Check if you can create resources in the cluster. In other namespaces, you will have no permissions to create or edit resources.

Roles required for creating a Managed Service for Kubernetes cluster

When creating a Managed Service for Kubernetes cluster and a node group, make sure the account used for this purpose has these roles:

To create a Managed Service for Kubernetes cluster and node group with public access, you will also need the vpc.publicAdmin role.

Managed Service for Kubernetes cluster service accounts

When creating a cluster in Managed Service for Kubernetes, specify two service accounts:

  • Cluster service account: On behalf of this service account, Managed Service for Kubernetes manages cluster nodes, subnets for pods and services, disks, load balancers, encrypts and decrypts secrets. The minimum recommended role for such an account is k8s.clusters.agent.
  • Node group service account: On behalf of this service account, Managed Service for Kubernetes cluster nodes are authenticated in Yandex Container Registry. To deploy applications in a Managed Service for Kubernetes cluster using Docker images from Container Registry, grant to this account any service role. If you use a different container registry, you can skip assigning roles to this service account.

To manage a Managed Service for Kubernetes cluster and node groups with public access, you will also need the vpc.publicAdmin role.

If you use a cloud network from a different folder in a Managed Service for Kubernetes cluster, the cluster service account will additionally need the following roles in this folder:

Accessing the Managed Service for Kubernetes management console

k8s.viewer is the minimum required role to access Managed Service for Kubernetes via the Yandex Cloud management console. The role only provides access to basic information about node groups.

The combination of the k8s.viewer and k8s.clusters.agent roles allows you to view all information about node groups, but not about individual cluster nodes.

The combination of the k8s.cluster-api.cluster-admin, k8s.clusters.agent, and monitoring.viewer roles allows you to view detailed information about node groups and individual cluster nodes. All tabs become available for each node in the management console, including the Monitoring tab.

To provide more granular access to resources, you can:

  • Configure additional permissions in the Kubernetes RBAC for the appropriate users.

  • Use role aggregation to expand the view and edit roles in the Kubernetes RBAC. For example, you can allow all users with the view role in the Kubernetes API (including users with the k8s.cluster-api.viewer cloud role) to view information about nodes by adding the following role to the Managed Service for Kubernetes cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-extensions
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Workload identity federations Yandex Identity and Access Management

Managed Service for Kubernetes supports integration with Identity and Access Management workload identity federations.

Workload identity federations allow you to configure a link between external systems and Yandex Cloud via the OpenID Connect (OIDC) protocol. This allows external systems to perform actions on Yandex Cloud resources on behalf of service accounts without using authorized keys. This is a more secure method that minimizes the risk of credential leakage and the possibility of unauthorized access.

When this option is enabled, Managed Service for Kubernetes automatically creates an OIDC provider for the specific cluster and provides the following parameters for integration with workload identity federations:

  • Issuer URL.
  • JWKS key set URL.

For example, you can configure Accessing the Yandex Cloud API from a Managed Service for Kubernetes cluster using a workload identity federation in Identity and Access Management.

Previous
Recommendations on using Managed Service for Kubernetes
Next
Pricing policy