ssh when sshAccess disable

[tedteng]

What this PR does / why we need it:
for issue, #325, however, check with MCM colleagues, don't find the solution to Enable/disable sshd service on a specific node. it seems the only way is enabling sshaccess then generate ssh key and enable sshd service to affect all the worker nodes.

the solution here is

1. to patch shoot workersSettings.sshAccess when shoot workersSettings.sshAccess is false,
2. waiting for ssh key to generate
3. then create a bastion with the annotation ["WorkerSSHD"] = false , to keep the original shoot workersSettings.sshAccess value , usually value is false
   will add extra logic in delete phase in the bastion extension repo individually and verify it. in delete phase will handle revert back code to patch shoot workersSettings.sshAccess back to original value false when detecting annotation ["WorkerSSHD"] = false in case any issue gardenctl break or keep bastion case

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

gardenctl ssh worker node when shoot disable sshAccess 

[petersutter]

Hi @tedteng, I understand that the PR is in draft, however I think this is heading in the wrong direction.

You suggested patching the shoot setting with gardenctl and then reverting it back to its previous value using gardenctl once a signal is received. However, if the ssh command is run multiple times for the same shoot, an incorrect value could be restored.

You also proposed setting an annotation on the bastion to store the "initial" enabled state. This would potentially allow the extension to patch the shoot to restore this value if it was not restored by gardenctl for any reason. However, this approach has the same issue: it's unclear what the real initial value is if the command was run multiple times.

Additionally, this approach would require another controller (the bastion extension controller) to patch the shoot resource, but does the user even have the permission to change this setting on the shoot?

I do not think it is a good idea to try to solve / workaround above mention issues. Lets first agree upon a design in #325 before investing any further time in this PR.

Also, if ssh access is disabled, do not silently enable it. The user/operator should be notified and asked if it should be enabled and there should be a flag to bypass the need for confirmation, similar to the confirm-access-restriction flag.

[tedteng]

@petersutter welcome any feedback for the solution discussion. I'm also verifying and looking for a solution.

You suggested patching the shoot setting with gardenctl and then reverting it back to its previous value using gardenctl once a signal is received. However, if the ssh command is run multiple times for the same shoot, an incorrect value could be restored.
You also proposed setting an annotation on the bastion to store the "initial" enabled state. This would potentially allow the extension to patch the shoot to restore this value if it was not restored by gardenctl for any reason. However, this approach has the same issue: it's unclear what the real initial value is if the command was run multiple times.

it should only have a value stored once. user A executed the gardenctl , then shoot patch to true. start from this pointer, the next user will ssh directly due to workersSettings.sshAccess being true already, there is no difference like before using ssh.

From the bastion object pointer, it should only have one bastion object with annotation to store the initial value (["WorkerSSHD"] = "false") at the beginning when user A executed the gardenctl and shoot ``workersSettings.sshAccessisfalse`.

The next/new user will create a new bastion object same as the normal ssh process (["WorkerSSHD"] = "true") because workersSettings.sshAccess is true already. then only the first bastion with ["WorkerSSHD"] = "false" annotation, will process the shoot reverting process when bastion object delete phase triggered by gardenctl or keep-life end

The purpose for reverting it back to its previous value using gardenctl once a signal is received is only in case the user cancel(Ctrl+C) the session during the shoot workersSettings.SSHAccess.Enabled patch before bastion created at that time. just for double safety, I involved another controller (the bastion extension controller) to revert the value back during the bastion delete phase. in this way always make sure the value is revetted back the initial value.

Additionally, this approach would require another controller (the bastion extension controller) to patch the shoot resource, but does the user even have permission to change this setting on the shoot?

I have the same concern too and will experiment with it.

Also, if ssh access is disabled, do not silently enable it. The user/operator should be notified and asked if it should be enabled and there should be a flag to bypass the need for confirmation, similar to the confirm-access-restriction flag

sure, I also want to have a similar flag or reminder when executed gardenctl

Lets first agree upon a design in #325 before investing any further time in this PR.

agree

[tedteng]

close this PR based on the discussion the new feature might be implemented in g/g side instead of triggering from gardenctl