Bug 2096382

Summary: [RFE] Request to have ability to add users to an image and deploy SSH public keys for these users with image builder
Product: Red Hat Hybrid Cloud Console (console.redhat.com) Reporter: lnarvaez
Component: Image BuilderAssignee: Image Builder team <osbuilders>
Status: NEW --- QA Contact: Image Builder team <osbuilders>
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: jangerrit.kootstra, jcastran, joerg.kastning, Martien.van.den.Akker, sraymaek
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description lnarvaez 2022-06-13 16:50:13 UTC
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

Comment 3 Joerg K 2022-06-14 06:24:18 UTC
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

Comment 4 Sanne Raymaekers 2022-10-05 10:40:22 UTC
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.

Comment 5 Joerg K 2022-10-11 06:16:27 UTC
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