[RFC] Azure Admin User Creation Proposal

[peytonr18]

Summary

Currently, Flatcar uses WALinuxAgent to create the Azure admin account specified in Azure VM configuration. The WALinuxAgent component responsible for this has been deprecated in favor of azure-init. To maintain compatibility and user expectations going forward, this functionality can be migrated to either Ignition, Afterburn, and/or Azure-init.

User creation involves:

• Creating admin user (if specified)
• Setting SSH keys (if supplied)
• Setting the password (if supplied)

Additionally, WALinuxAgent configures SSHd’s PasswordAuthentication=[no|yes] based on disable_password_authentication option.

Option 1: Ignition

Ignition-fetch.service fetches user data from IMDS and mounts Azure’s provisioning media. This option will add the capability for ignition to fetch Azure configuration related to the Azure admin account and add/merge it into ignition config.

For example, an empty ignition config in user data would result in something like:

{ 
  "ignition": { 
    "version": "3.4.0" 
  }, 
  "passwd": { 
    "users": [ 
      { 
        "name": "azureuser", 
        "passwordHash": "$6$...", 
        "sshAuthorizedKeys": [ 
          "ssh-ed25519 AAAA...B" 
        ], 
        "groups": [ 
          "sudo", 
          "wheel" 
        ], 
        "homeDir": "/home/azureuser" 
      } 
    ] 
  }, 
  "storage": { 
    "files": [ 
      { 
        "path": "/etc/ssh/sshd_config.d/10-password-auth.conf", 
        "mode": 420, 
        "contents": { 
          "source": "data:,PasswordAuthentication%20yes" 
        } 
      } 
    ] 
  } 
} 

...When the user specifies the following Azure configuration:

'osProfile': {'computerName': 'vm-a083', 'adminUsername': 'azureuser', 'adminPassword': 'mypassword', 'linuxConfiguration': {'disablePasswordAuthentication': False, 'ssh': {'publicKeys': [{'path': '/home/azureuser/.ssh/authorized_keys', 'keyData': 'ssh-ed25519 AAAA...B\n'}]}} 

Option 2: Afterburn

Add the following features, which would only be done on the Microsoft Azure cloud:

• User creation
• Password handling (if specified)
• SSHD config password fragment to allow password-login

Option 3: Azure-init

Create a new systemd service file that runs azure-init with command-line option to limit scope of actions, e.g.:

azure-init --create-user
--configure-user-password
--configure-user-ssh-keys
--configure-sshd-password-authentication

[pothos]

Thank you, I think that Ignition is not a good fit and would prefer option 2 and 3. I think that while it's nice to have Afterburn be able to do this, I think it's also nice if azure-init could do it with a similar CLI switch so that one can limit its action and call it when appropriate in the OS integration.
This would allow us to pick afterburn or azure-init as fits, e.g., a Linux distro using only one of them would prefer the one its already using, or one would prefer to switch to the other implementation when it offers newer features but having similar interfaces allows one to be able to switch more easily than when they have completely different concepts on how they run.
For Flatcar's case I would say that it can use any of both and if azure-init is ready to use this way but upstream afterburn takes a while we can do the switch to azure-init. Another option is to carry an afterburn downstream patch while the feature is not upstream.
To summarize, I don't see a need to decide between option 2 and 3, they both should be done in parallel.

[cjp256]

@pothos can you share a little bit on why you think I think that Ignition is not a good fit? If ignition already has the configuration semantics and capability for creating users, it seems like a better integration point than afterburn which does not.

From the ignition readme:
Ignition is a utility created to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users.

In cloud-init we merge the Azure admin user into cloud configuration and is a pretty natural fit for cloud-init (we are using existing cloud-config and modules) and I'm just wondering why it's not here.

[pothos]

While Ignition has a way to merge configs from different sources, the config would need to provided with the right values from some Azure metadata server as Ignition JSON.