RFD: Add Automatic User Provisioning

[lxea]

This adds an RFD with requirements for the implementation of automatic user provisioning on Teleport SSH nodes.
Related issue: #10486

[Joerger]

Does this mean it will default to false, making this an opt-out feature? My main concern here is unless we're dropping PAM support, we'll need to ensure that they play nicely together. Maybe this will end up being trivial, or we could turn off auto_create_user when PAM is enabled.

[lxea]

I dont think this and PAM should interact, teleport will be operating separately to create users, if the user has a pam script/module also creating users then there could be problems but the PAM script could be doing other things too.

This is defaulting to false, just so on a per node level user creation can be disabled

[Joerger]

Do we want to also de-provision groups? I'm not sure how we could discern which groups were created by teleport other than keeping an internal record, so if we want this it may make sense to alter the clean-up process. Or maybe created groups could have a -teleport suffix?

[lxea]

I was originally just going to just create groups at startup and leave them around

I'm not sure how group deletion would work, it doesnt seem to cause an error if a group gets deleted while a user in that group has a running process. Maybe it could work by checking that there are no users in the teleport-system group anymore and then deleting groups made by teleport.

I think having a -teleport suffix would work but might make it a bit unclear when configuring software, why users have some groups with -teleport and some groups that already existed dont have a suffix,

[r0mant]

@lxea In addition to making the changes we already discussed, can you please add a separate UX section describing the following use-cases and how the configuration would look like from Teleport administrator perspective:

• Teleport admin wants each user has a dedicated SSH account defined in their Okta attributes.
• Teleport admin wants to define which Linux groups each auto-created user will be added to.
• Teleport admin wants to make each auto-created user a sudoer.
• Teleport admin wants to define particular commands user will be able to run as root.
• Teleport admin wants to prohibit some nodes from auto-creating users.

In addition, can you also add a section addressing the security concern with preventing a user who was auto-added to sudoers from privilege escalation (e.g. modifying the sudoers file to their liking).

[lxea]

@r0mant

In addition, can you also add a section addressing the security concern with preventing a user who was auto-added to sudoers from privilege escalation (e.g. modifying the sudoers file to their liking).

I've updated the document for this however it requires a command allow list, i dont really think there is a sensible way to stop the user from editing the sudoers file if they have anything like $USER ALL=(ALL) ALL

[r0mant]

@xinding33 @stevenGravy Could you folks please take a look at this as well from the UX perspective?

[r0mant]

Worth mentioning that useradd, compared to adduser, does not provision home directory. I think it should be fine for dynamic users. Any there any other differences between these 2 commands?

[lxea]

adduser is distro specific so its sometimes not available or has different command sets available.

useradd can create home directories, i think it just doesnt by default, its flag is --create-home

[r0mant]

If a user has multiple roles attached and only some (or one) of them enable the auto_create_user - what would the behavior be? I think that it should only take effect if all roles matching the node you're accessing (by labels) enable it. Could you add a section describing this scenario?

[lxea]

Added a example to the UX section with my understanding of how this should work

[klizhentas]

@r0mant @lxea create_host_user: true to differentiate between teleport users and host users. Also auto is really not necessary, as everything that Teleport does it automated :)

[stevenGravy]

Can we make this configurable and start with this. This doesn't have @, _ which are pretty common. Also GCP will create users with their personalized emails.

[lxea]

I'm dont know how to make this configurable or what the ux should be like for such a thing, I intended to replace any characters that dont fit with -.

I was operating under the impression that the users unix username would need to match the teleport user however I think it would make sense that it be any user available in the logins trait, in which case it could be up to the user to provide an external trait -- something like {{external.linix_username}}, which conforms to the requirements of whatever Linux distro is being used and have Teleport try to blindly create users and just log an error when it fails

[klizhentas]

Would agent recycle users that are inactive automatically? Same for sudoers lines

[lxea]

What do you mean by recycle inactive users?

[lxea]

After sessions end the user and their sudoers files are deleted, if they're leftover (due to, for example a running process remaining) they and their sudoers file will be removed also.

[klizhentas]

Props for UX examples, makes it much easier to understand

[lxea]

@klizhentas

• I suggest to use the terms: create_host_user, host_groups and host_sudoers to make it specifically about host changes.

👍

• It is unclear to me from the spec how multiple host_sudoers entries will be processed

Clarified in document -- if a user has multiple roles with separate sudoers specifications they will all be written to a /etc/sudoers.d/teleport-$unix_username` with each on a separate line

• It is unclear from this RFD whether old groups/users will expire and be removed after a while

This is specified in the User deletion section, I added some clarification about what will happen to groups.

• Not clear why all roles have to have this feature enabled at the same time.

Replied in comment

[espadolini]

Should we prohibit arbitrary additions to a sudoers file and manually prepend the actual unix username to the lines in host_sudoers instead? Or perhaps add another escape for the unix username that's being used to log in, as {{internal.logins}} can have a lot of usernames, some of which might belong to other users in the system.

[espadolini]

I'm also not sure about using a naked systemctl as an example in our docs, as that can be used to escalate to arbitrary command exec pretty easily (just edit and restart some existing service). Perhaps something along the lines of this?

Suggested change

	host_sudoers: ["{{internal.logins}} ALL = (root) NOPASSWD: /usr/bin/systemctl"]
	host_sudoers: ["{{internal.logins}} ALL = (root) NOPASSWD: /usr/bin/systemctl restart nginx.service"]

[lxea]

Should we prohibit arbitrary additions to a sudoers file and manually prepend the actual unix username to the lines in host_sudoers instead? Or perhaps add another escape for the unix username that's being used to log in, as {{internal.logins}} can have a lot of usernames, some of which might belong to other users in the system.

I'm not sure, I think teleport should do as little as possible that isnt explicitly set by the user for sudoers file entries,

[espadolini]

How do we deal with leftover files? Are we ok with the UID being reused by some other user (real or ephemeral) in the future?

[lxea]

As it stands I expected UIDs to be reused, but perhaps it could make sense to have user deletion set the shell to /bin/nologin or something, this way UIDs wont clash

[xacrimon]

Is this field an array of entries for the sudoers file? Just want to make sure

[lxea]

yeah, each entry will be a new line

[lxea]

@espadolini @klizhentas Are there outstanding issues with this RFD that need to be addressed, or is this in an okay state to be merged? Implementation is here #11830 and sudoers is here #12061

[espadolini]

I've already voiced my doubts around automatic user cleanup with regards to race conditions, background processes, UID reuse and home directory cleanup/reuse - we addressed some of it on the implementation side, but some flaws are part of the design, IMO.

A different question: should we add some way to specify which host users can be automatically provisioned for a given user/role? AIUI with the current design there's no way to allow a user to have a handful of login names that can be used for existing host users and only some login names for autoprovisioning, so any (teleport) user with permissions for host user creation must be restricted to only the intended autoprovisioning logins. Perhaps the users that should be autoprovisioned should only come from the roles that allow autoprovisioning, similarly to how the check for create_host_user is only done on the roles that match a specific node?