Welcome to the forum!
I don’t use cloud-init, so I’m not familiar with its quirks. I tried to read about the group config a bit and there’s none. It’s too limited. I think best workaround you can do is add a group, add the user to the group, skip the sudo part of cloud-init and write a file using cloud-init.
groups:
- myadmins
users:
- name: foobar
gecos: probably optional
primary_group: foobar
selinux_user: staff_u
groups: myadmins
write_files:
- path: /etc/sudoers
content: |
%myadmins ALL=(ALL:ALL) ALL
owner: "root:root"
permissions: "0660"
append: true
runcmd:
- "groupmod -g 1234 myadmins"
- "usermod -u 1000 foobar"
- "groupmod -g 1000 foobar"
- "chmod -R foobar:foobar /home/foobar"
This is by no means complete, just an example I made up. Add your user’s creation config template, but without adding the sudo: part. Sudo should be done from the content from the sudoers file, at the group level, group of which your user should now be part of.
The runcmd part is optional, but it’s a good idea to have your groups created with higher GIDs, because when you create new users on the system, they’ll (most of the time) get their own groups with the same GID. If you have a group without a user on the system, then you will have a mismatch between the user and gid. It’s not bad, but annoying to see on any system. So I made the gid of myadmins higher and made sure to set the uid of the user foobar to 1000 and the gid of the group foobar to 1000 as well (1000 is generally the ID that they will be created with).
Rant
I find cloud-init to be such an inconvenience. It has weird quirks, like not having to start the VM before you config this and other stuff like missing group configs for sudo and more. And it has a CMD option, because it is limited. If I wanted to write a bash script to initialize my system, I would have wrote it already. Actually, that would be what I’d be doing if I were to deploy many systems at once.
Instead of using cloud-init, I preferred to just create a VM, set it up with not just the main users, but also the software necessary for it to be a proper template, then convert it to a template. Before, I didn’t know each VM had a unique machine ID and they’d be cloned with the template, but all you have to do is remove the machine id and run a command, which can be used when initializing the VM.
We were cloning VMs on demand, generally not more than 2 VMs at a time. The IP address was static on the VM (because DHCP is not to be trusted) and the test IP was always unused. When the VMs booted, we changed it with something available (the only reason DHCP existed for the VM VLAN was to keep track of assigned IPs). I can see how this would not be ideal with cloning tens of VMs at once, you’d immediately get IP conflicts if you don’t use DHCP. But by then, you need a better automation tool, like ansible and have a discovery mechanisms for new VMs, to have them automatically configured.
Cloud-init just feels so limiting to me. I don’t judge people using it, if it works for you, then great! But I would like to understand why is it that people choose to use it.