Cloud-init configuration for VM applications
You can use cloud-init to configure VM guest instances, including user credentials, packages, and custom scripts on first boot. Without cloud-init configuration, a VM guest relies on credentials pre-defined in the base image, and many cloud images have no default password.
How cloud-init works in Red Hat Edge Manager Copy linkLink copied!
Cloud-init configuration is embedded directly in the KubeVirt VirtualMachine YAML as a cloudInitNoCloud or cloudInitConfigDrive volume.
When you use the Red Hat Edge Manager web console guided form, the form generates the cloud-init YAML from the credential fields and the cloud-init textarea.
For advanced use cases, you can supply your custom cloud-init YAML instead.
On the edge device, the Red Hat Edge Manager agent passes the cloud-init user-data through to the VM guest as part of the VM specification. No separate seed ISO is required. The cloud-init service inside the guest reads the configuration and applies it.
Default user for guided form credentials Copy linkLink copied!
When you enter an SSH key or password in the guided form, Red Hat Edge Manager does not set a user: directive in the generated cloud-init YAML.
Cloud-init applies those credentials to the default user account defined by the guest image.
For Red Hat Enterprise Linux VM guests, the default user is typically cloud-user when you set an SSH key or password in the guided form.
| Guest image | Default user |
|---|---|
|
Red Hat Enterprise Linux cloud images |
|
|
Fedora container disk images (for example, |
|
These are common examples only. If you use a different guest image, check that image’s documentation for its default user.
Guest image requirements Copy linkLink copied!
VM application cloud-init user-data is applied by the cloud-init service inside the guest operating system.
The guest disk image must include the cloud-init package and enable cloud-init.target before you package it as a container disk image.
When you build custom Red Hat Enterprise Linux VM guest images from a bootc base image, install and enable cloud-init in the Containerfile before you create the qcow2 or raw disk image.
For a Containerfile example, see Build for specific target platforms in the Additional resources section.
The guided form generates cloud-init similar to the following example when you provide both an SSH key and a password:
#cloud-config
ssh_authorized_keys:
- <ssh_public_key>
ssh_pwauth: true
chpasswd:
expire: false
password: <password>
To use a different username, set user: in the Cloud-init user-data field or in raw YAML.
To create a custom user account instead of the image default, use the users directive in cloud-init.
The guided form SSH key and password fields always target the image default user.
For examples, including how to create a custom user, see Configure cloud-init for a VM application in the Additional resources section.
Changing any field in the VM application specification, including cloud-init configuration, causes the VM to reboot. Plan configuration changes accordingly to minimize disruption to running workloads. This behavior applies to all application types and at both the device and fleet level.
Supported cloud-init volume types Copy linkLink copied!
Red Hat Edge Manager supports two KubeVirt cloud-init volume types:
-
cloudInitNoCloud - The recommended volume type. Provides user-data and optional network-data through the NoCloud datasource. Use this type unless your guest image specifically requires ConfigDrive.
-
cloudInitConfigDrive - Provides user-data through the ConfigDrive datasource. Use this type for guest images that expect ConfigDrive metadata.
Both volume types support inline userData (plain text cloud-config YAML) and userDataBase64 (Base64-encoded cloud-config YAML).
The secretRef field, which references a Kubernetes Secret, is not applicable in Red Hat Edge Manager.
Edge devices do not have a Kubernetes Secret store.
Security considerations Copy linkLink copied!
Cloud-init credentials, including passwords and SSH keys, are stored as plain text in the device specification. Any user with read access to the device specification can view these credentials. Use SSH key authentication instead of passwords when possible, and limit access to device specifications to users who need it.