Update host user creation RFD to allow for permanent users

[lxea]

Related #26892

[codingllama]

@lxea I suggest you assign your original RFD reviewers here, they are bound to have more context and do a better job than the bot reviewers.

[espadolini]

I don't like this, it means that unless someone is very very careful with how they define their roles, they might accidentally end up with drop behavior instead of the correct one.

[espadolini]

Should this be a role option, or should this be a host option like ssh_service.disable_create_host_user?

[lxea]

I suggested this when speaking to @r0mant however I think we want this as a role option

What would be preferred behavior in this case?

[Joerger]

What is the downside to letting remain take precedence over drop?

[r0mant]

It should be a role option, yeah. I think it's ok to default to keep, then it will also be consistent with automatic user provisioning for database and Windows access which always keep the user. As long as there's no surprise change in behavior for existing users which are using the current setting.

That said, I think that the option on the SSH service should be updated accordingly as well, and converted to an enum: create_host_user_mode: off|keep|drop.

[Joerger]

@espadolini so essentially you mean if create_host_user=off && create_host_user_mode=remain, when connecting to an old node, the node should read it as create_host_user=off, right?

Is there any real benefit to this flexibility? I think having old nodes default to drop behavior when create_host_user_mode=remain is reasonable.

If we want to disable host user creation on a specific node, including old nodes, we can allow the user to set create_host_user=off or create_host_user_mode=off and prioritize that setting over role options.

[r0mant]

I think we should deprecate existing "create_host_user" option so we don't have to maintain both and follow our normal deprecation logic:

• If "create_host_user_mode" is set, it always takes precedence.
• Keep "create_host_user" for backwards compatibility and respect it if it's set (unless there's "creaet_host_user_mode") but remove it from all user-facing docs.

@lxea Can you update the RFD with this deprecation plan?

[klizhentas]

What is the deprecation plan? I assume we should trigger role migration and update all old roles to the new option. In this case new role version will reject the deprecated option.

The alternative is to keep the option, but instead treat true as drop and keep as the other additional value, it's a hack, but should work :)

[lxea]

I've updated it for this and included a bit about the plan for migration after the deprecated option is removed. The implementation PR implements the precedence as you mention here.

What is the consensus on the creaet_host_user_mode option in ssh_service, do we want this?

[r0mant]

I think the service-level "mode" option is not needed as it may make things confusing around conflict resolution as we discussed above. Just keeping the "on/off" toggle we have should be fine for now IMO.

[r0mant]

lgtm after you add the SSH service option to the scope as well.

@klizhentas @xinding33 Can you folks review the UX here when you get a chance?

[r0mant]

It should be a role option, yeah. I think it's ok to default to keep, then it will also be consistent with automatic user provisioning for database and Windows access which always keep the user. As long as there's no surprise change in behavior for existing users which are using the current setting.

That said, I think that the option on the SSH service should be updated accordingly as well, and converted to an enum: create_host_user_mode: off|keep|drop.