Access management in Managed Service for Kubernetes
In this section, you will learn:
- Which resources you can assign a role for.
- Which roles exist in the service.
- Which roles are required for managing Managed Service for Kubernetes.
- What roles are required for Managed Service for Kubernetes cluster service accounts.
- What roles are required to work with Managed Service for Kubernetes via the Yandex Cloud management console.
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 permission for a resource, assign roles for this resource to the subject that will perform operations. Roles can be assigned to a Yandex account, a service account, federated users, a user group, or a system group. For more information, see How access management works in Yandex Cloud.
Only users with the admin
, resource-manager.clouds.owner
, or organization-manager.organizations.owner
role for a resource can assign roles for this resource.
Which resources you can assign a role for
As with other services, you can assign roles for clouds, folder and service accounts. The roles assigned for clouds and 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 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 create 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 permission to read resources.
The viewer
role includes all permissions granted by the auditor
role. Unlike auditor
, the viewer
role allows access to service data in read mode.
For example, the viewer
role allows you to perform the following operations:
- View information about a resource.
- Get a list of nested resources, such as a list of VMs in a folder.
- View a list of operations with a resource.
editor
The editor
role grants permissions to perform any operation related to resource management, except assigning roles to other users. The editor
role includes all permissions granted by the viewer
role.
For example, the editor
role lets you perform the following operations:
- Create a resource.
- Update a resource.
- Delete a resource.
admin
The admin
role grants all permissions to manage the resource, including assigning roles to other users. You can assign any role except resource-manager.clouds.owner
.
The admin
role includes all permissions granted by the editor
role.
For example, the admin
role lets you perform the following operations:
- Set permissions to the resource.
- Change permissions to the resource.
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:
- k8s.editor or higher
- iam.serviceAccounts.user
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 this 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 consolek8s.viewer
.
To get detailed information about a Managed Service for Kubernetes cluster and node group, you will need the additional k8s.cluster-api.viewer
role. This role corresponds to the viewer
role in Kubernetes RBAC and grants permissions to a limited set of resources in the Kubernetes API, so the console's features are limited.
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.
-
Expand the
view
andedit
role in Kubernetes RBAC using role aggregation . For example, you can allow all users with theview
role in the Kubernetes API (including users with thek8s.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"]