Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure user account based on azure provider specific information #919

Open
JanZerebecki opened this issue May 4, 2023 · 1 comment
Open

Comments

@JanZerebecki
Copy link
Contributor

Feature Request

Configure a user account based on provider specific information and use it as the user for which to add authorized ssh keys.

Azure has a prominent setting for an administrator account name when creating an VM instance. It seems users seem to expect to be able to use this and have it work. (Screenshot of Azure VM instance administrator account username from some unrelated installation instructions.)

Is afterburn a good place for this functionality?

This information is provided as osProfile.adminUsername: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux#tabpanel_1_linux
Without having tested it I assume this would be metadata/instance/compute/osProfile/adminUsername?api-version=2021-12-13&format=text in therms of how the code currently accesses similar data: https://github.com/coreos/afterburn/blob/07333c051dbdccabdcf16fcb1df482d2eb56f429/src/providers/microsoft/azure/mod.rs#LL325C33-L325C98

Additionally boolean disablePasswordAuthentication will be provided. For if its false, I can't find how to get an adminPassword right now, probably similarly to authorized ssh keys.

(Choosing the default user at runtime might be useful independently so a generic way to configure this should also be provided. Currently it is set via the Makefile at build time. People might want to change that without rebuilding an image. And might want to build images with different default users without recompiling afterburn. I'm unsure what a good ways is to handle any of these being different.)

Environment

Azure

Desired Feature

Other Information

@bgilbert
Copy link
Contributor

bgilbert commented May 7, 2023

(Choosing the default user at runtime might be useful independently so a generic way to configure this should also be provided. Currently it is set via the Makefile at build time. People might want to change that without rebuilding an image. And might want to build images with different default users without recompiling afterburn. I'm unsure what a good ways is to handle any of these being different.)

The default instance is set at build time, but you aren't required to use it. This Butane config disables setting SSH keys for the core user and sets them for admin instead:

variant: fcos
version: 1.0.0
passwd:
  users:
    - name: admin
systemd:
  units:
    - name: [email protected]
      enabled: false
    - name: [email protected]
      enabled: true

Azure has a prominent setting for an administrator account name when creating an VM instance. It seems users seem to expect to be able to use this and have it work.

Is afterburn a good place for this functionality?

Afterburn is the best available place for this functionality, but it's not a clean fit. Afterburn currently doesn't create any user accounts; it expects the target account to exist already. The target account is currently set from the instance name of the systemd unit, so Afterburn would need to selectively ignore that on certain platforms. Or, it could have a separate systemd unit that autodetects the username, and then we'd need to decide which approach should be the default. But overall it seems a little counterintuitive that we'd start ignoring the existing configuration mechanism in favor of some field in the Azure console UI.

So yes, implementing this functionality is a possibility (and I think GCP could also make use of it) but I'm not sure it's a win. Would the confusion be better addressed by OS-level documentation?

Additionally boolean disablePasswordAuthentication will be provided. For if its false, I can't find how to get an adminPassword right now, probably similarly to authorized ssh keys.

I don't think we should support password authentication over the network in 2023, particularly not with a password held by the cloud provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants