1. Proposed title of this feature request Request to have ability to add users to an image and deploy SSH public keys for these users. 3. What is the nature and description of the request? It would add value and improve the service if you can add users to an image and deploy SSH public keys for these users. 4. Why does the customer need this? (List the business requirements here) We add some user with sudo privileges and SSH public key to our templates to be able to manage them with Ansible once a new VM is provisioned using the template. To be able to use the Image Builder service we would need this functionality. Otherwise, we would have to edit the image after download locally which would be inconvenient and is the reason we don't use Image Builder today. 5. How would the customer like to achieve this? (List the functional requirements here) Add the option to image builder to allow users to be added to image with SSH public keys 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Test the functionality once it is available within image builder 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? No 8. Does the customer have any specific time-line dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? RHEL 8 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages or components. Image Builder 11. Would the customer be able to assist in testing this functionality if implemented? Yes
Hello, I'm Joerg, the customer who sent this RFE to support. Product an Compoment of this bugzilla might be wrong as I've requested this feature for the Image Builder Saas which is part of the Red Hat Hybrid Cloud Console at https://console.redhat.com. Best regards, Joerg
Hello, So far we've refrained from enabling user customization for all images, mostly to align with best practices for each of the image types. For the cloud images (aws/azure/gcp) users should be created when launching the instance via the cloud platform's interface, and the UX around that is usually really nice. For the private cloud images it's a bit less obvious. The vmware image is mostly intended for (and tested on) vSphere, which supports cloud-init https://kb.vmware.com/s/article/82250, so we decided to encourage that. For the guest image/qcow2 we currently mirror Red Hat policy, which is that the guest image should not have a default user baked in, but rather a user should be created using cloud-init (or virt-customize). I think it would actually be ok to enable user customization for this type as well. We have enabled this for the installer, as there users are customized either during the installation process, and there's no standardized/default first-boot configuration method supported. This is currently only available in the api, as we only expose the customizations which are available for all image types in the ui.
Hello Sanne, Thank you for your detailed feedback. I can understand that there are advantages to stick to the best practices for the different image types as well as only expose customizations which are available for all image types in the UI. Maybe I have thought to much about my own use case. We like to put everything we need for the configuration management to take over into the image. Provisioning an image and to be able to run your playbooks against the new VM afterwards is a lot faster than waiting for cloud-init to finish and then start with the configuration management. Thanks, Joerg