Enable sshd service when using ssh on a specific node

[AleksandarSavchev]

What would you like to be added:
Currently it is not possible to use gardenctl ssh on nodes when the cluster has provider.workersSettings.sshAccess.enabled set to false. I would like to enable ssh access when using gardenctl ssh on a specific node if it had been disabled and disable it again when the ssh session ends.

Why is this needed:
Improve debugging of issues when cluster has provider.workersSettings.sshAccess.enabled set to false.

[petersutter]

I believe that gardenctl should not manipulate this setting and attempt to restore it afterwards, as suggested in #331. Please refer to my comment for reasons why I consider this to be a poor approach.

Instead, I suggest to extend Shoot.spec.provider.workerSettings.sshAcces and rather have something like
1.

    workersSettings:
      sshAccess:
        enabled: false
        # policy: # has no effect if set 

    workersSettings:
      sshAccess:
        enabled: true
        policy: 'ondemand' # allows Bastions to be created. sshd will be running on the worker nodes as long as there are Bastion resources

    workersSettings:
      sshAccess:
        enabled: true
        policy: 'always' # regardless if there are Bastion resources, the sshd is running on the worker nodes

We currently support options 1 and 3. The newly introduced feature is option 2. If a Bastion is created, the sshd will be initiated and subsequently terminated once the last bastion resource has been deleted.

This eliminates the need for gardentl to manipulate the sshAccess settings on the Shoot and attempt to restore the initial enabled state. Moreover, the shoot owner retains control of the setting. This means that if it's disabled, debugging is not possible unless it's explicitly enabled.

@AleksandarSavchev @rfranzke @dimityrmirchev (as you were involved in #7188), WDYT?

[AleksandarSavchev]

I agree with you that gardenctl should not modify the setting.

I approve your suggested approach and would like to point out that when option 2 is used it would work the same way as option 1. When a Bastion is created for a node in a cluster using option 2 the following steps should happen:

• sshd-ensurer service ( this service keeps sshd disabled) should be stopped for the specified node.
• sshd service should be enabled and started
• a SSHPublicKey should be created.

When all Bastions for a node are deleted we can start the sshd-ensurer service again.

[dimityrmirchev]

I also think that what @petersutter suggested is reasonable approach.

[tedteng]

if I understand correctly the implementation will not be in Gardenctl repo or Bastions repo. it will be enhanced from gardener/gardener? not clear if new implementation comes from gardener/gardener side? waiting answer from Devs