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

Access management in Managed Service for Kubernetes

Written by
Improved by
Updated at November 27, 2024

In this section, you will learn:

About access management

In Yandex Cloud, all transactions are checked in Yandex Identity and Access Management. If a subject does not have the required permission, the service returns an error.

To grant permissions for a resource, assign roles for this resource to the subject that will perform the operations. You can assign roles to a Yandex account, service account, federated users, user group, system group, or public group. For more information, see How access management works in Yandex Cloud.

Roles for a resource can be assigned by users who have at least one of the following roles for that resource:

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

Which resources you can assign a role for

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

Which roles exist in the service

The chart below shows which roles are available in the service and how they inherit each other's permissions. For example, the editor role includes all the permissions of viewer. You can find the description of each role under 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. For more information about roles in Kubernetes RBAC, see the Kubernetes documentation.

To view permissions to the 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:view 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:edit 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:cluster-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 also 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 also 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 also includes the editor permissions.

Note

With Kubernetes RBAC, you can provide users with granular access to the 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 creating resources in the cluster. In other namespaces, the user will have no permissions to create or edit resources.

Roles required for creating a Managed Service for Kubernetes

When creating a Managed Service for Kubernetes cluster and a node group, make sure that the account used for creating the cluster 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

To access Managed Service for Kubernetes via the Yandex Cloud management console, the minimum required role is k8s.viewer.

To get detailed information about a Managed Service for Kubernetes cluster and a node group, you will need the additional k8s.cluster-api.viewer role. This role corresponds to the view role in Kubernetes RBAC and grants access permissions to a limited pool of resources in the Kubernetes API, so the console will have a limited set of features.

Users with the k8s.cluster-api.cluster-admin role have full access to the Managed Service for Kubernetes cluster's Kubernetes API and can use all the management console features.

To provide more granular access to the necessary resources, you can:

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

  • Use role aggregation to expand the view and edit roles in 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"]
Previous
Managed Service for Kubernetes usage recommendations
Next
Pricing policy