With KDP, access to KubeV is managed entirely in KDP. KubeV has no users, roles or role bindings of its own, and in KDP mode its dashboard has no Users, Roles or Role Bindings pages: a link to one says Managed in KDP. This page explains who can do what, and which KDP roles to give your users.
The KubeV API server holds no credentials for KDP. It sends each request to kcp with the signed-in user’s own token, so kcp checks every request against the user’s roles in the project. Where KubeV has to act on its own cluster, for example to open a VM console, it asks kcp first, as the user.
kcp applies a role change in KDP at once. Three things follow it with a delay:
In same-layer mode, the platform administrators are the users named in the installer
configuration: the kdp.admin user, or the members of the kdp.adminGroup OIDC group. When
both are set, only the group counts. Platform administrators can:
root:kubev by default, which holds the KubeV service.Being a platform administrator doesn’t make you a member of the organizations other people created. An organization’s owner adds you there like any other user.
The tasks that affect the whole platform, such as edge routers, quotas and network policies,
are done with kubectl on the KubeV cluster. See
Operating the Platform.
With your own KDP, the KubeV service is managed by the administrators of the provider workspace:
whoever ran kdp connect first, and anyone granted cluster-admin there. If you set kdp.admin or
kdp.adminGroup, kdp connect grants them the same rights as above.
KDP lists a service in its catalog, and shows its Open KubeV Virtualization button, to users
who may bind the service’s API, and in projects where the service is already enabled. KubeV lets
every signed-in user bind its API: the installer sets this up, or kdp connect with your own KDP.
So every user sees KubeV.
Seeing KubeV in the catalog doesn’t let a user do anything in a project. Inside a project, the user’s roles there decide everything.
Members and their roles are managed on the project’s Members page in KDP. Give users a role in each project they work in.
When KubeV is enabled in a project, KDP adds a Developer and a Viewer role for the KubeV service, such as virtualization.k8c.io Developer, and includes them in its own Developer and Member roles. These are the roles that matter for KubeV:
| KDP role | What it allows in KubeV |
|---|---|
| Owner | Everything in the project: all KubeV resources and every project page of the KubeV dashboard, plus the project’s members and services. |
| Developer | Create, change and delete KubeV resources: virtual machines and pools, disks and images, VPCs, subnets, underlay subnets, security groups, NAT gateways and elastic IPs, SSH keys, backups, restores and migration objects. Start, stop and restart VMs, and open their consoles. Manage the project’s namespaces. |
| Access Manager | What Developer allows, plus managing the project’s members and their roles. |
| Member | View KubeV resources. Members can’t open VM consoles. |
| Service Manager | Enable and disable services in the project, KubeV included. It gives no access to KubeV’s own resources, but it can read every Secret in the project, including the credentials of backup targets and migration providers. |
Disabling KubeV in a project deletes its resources. When a service is disabled, kcp deletes every object of that service in the project, and KubeV then removes them from its cluster: VMs, their disks and networks included. Only disable KubeV in a project that should lose them.
KDP’s Developer and Member roles cover the resources KubeV adds to the project. Some KubeV pages also use standard Kubernetes resources in the project, which those roles don’t include:
| Kubernetes resource | Used by |
|---|---|
| Secrets | Adding a backup target (its credentials), adding a migration source provider (its vCenter login). |
| Events | The Events page, and the events shown on each object. |
| Pods | The serial log on a VM’s Monitoring tab. |
| Services | Load Balancers. |
| NetworkPolicies | Firewalls. |
| HorizontalPodAutoscalers | Auto Scaling. |
| PersistentVolumeClaims | The volumes behind disks, including the disks of migrated VMs. |
Give users who need these pages the Owner role, or create a role that adds them. KDP offers
any ClusterRole labelled for its dashboard on the Members page; see
RBAC in the KDP documentation. For example,
created in the project with kubectl by one of its owners:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kubev-workloads
labels:
rbac.kdp.k8c.io/display: "true"
annotations:
rbac.kdp.k8c.io/display-name: "KubeV Workloads"
rbac.kdp.k8c.io/description: "Secrets, events, pods, volumes, load balancers, firewalls and autoscalers used by KubeV"
rules:
- apiGroups: [""]
resources: ["secrets", "services", "persistentvolumeclaims"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["events", "pods", "pods/log"]
verbs: ["get", "list"]
- apiGroups: ["networking.k8s.io"]
resources: ["networkpolicies"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["autoscaling"]
resources: ["horizontalpodautoscalers"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
Assign it together with Developer, which gives access to the project itself. To include it in
Developer for everyone instead, add the label rbac.kdp.k8c.io/aggregate-to-developer: "true".
The role applies only in the project where it is created: repeat it in each project that needs it.
Reading Secrets means reading credentials. In a KDP project, the vCenter login of a migration provider and the credentials of a backup target are Secrets in the project. Anyone who may read Secrets in that namespace can read them, Service Managers included. Grant Secret access with that in mind.
The KubeV dashboard’s forms need a few objects that the whole platform shares, so any role in a project, Member included, lets a user read them:
They are read-only. Platform administrators can read them too.
Users sign in to KubeV through the same OIDC provider as KDP. Every click on Open KubeV Virtualization in KDP signs KubeV in again, as the user who clicked: a KubeV session left over from another account never carries over. Whether that asks for anything depends on how the user logs in to Dex:
| Login | Each click from KDP |
|---|---|
| Google, GitHub or another identity provider behind Dex | A redirect, without a prompt: that provider still has the KDP sign-in. |
Dex’s own password logins: email (local) and LDAP | The password, again: Dex keeps no session for them. |
If Dex offers more than one login method, users also pick theirs on Dex’s page, unless KDP’s link names the one they used in KDP:
dashboard.auth.oidc.connectors.
The installer then has KDP put the user’s login method in the link.Set connectors only when the issuer is a Dex: other providers, such as Keycloak, Okta and Entra
ID, refuse the scope this needs. Dex also asks users to approve KubeV on each sign-in, unless
Dex’s oauth2.skipApprovalScreen is set: the installer sets it on the Dex it deploys, and you set it
on a Dex you run yourself.
When the signed-in account can’t open the project, KubeV says which account it checked, and offers to sign in with a different one.
The button’s link carries no credential. Without completing the sign-in, a user gets nothing from KubeV.