Add ssh access to VMs

[claudious96]

Description

This PR presents a possible implementation of an SSH bastion using a sidecar approach. Each pod is composed of an ssh-bastion running sshd and a sidecar operator that whatches the Tenant resource updating the authorized_keys file at each tenant related event (creation/deletion/update of a Tenant resource).

Currently the operator gets a List of Tenants in the default namespace, this is good for testing but probably should be managed differently.
Assuming that a single deployment would manage all incoming ssh incoming traffic for the whole crownlabs cluster, since the Tenant resource could belong to one or more workspaces, a possible approach could be:

• establish (somehow) a list of workspaces that are going to use this feature i.e. Cloud Computing course
• perform a List operation on the Tenant CRD belonging to those workspaces
• update the authorized_keys file

Otherwise if the plan is to deploy it per workspace, the operator could just perform the List on the related workspace and the operator should be modified in order to be aware of the workspace (namespace might be useful).

Notes:

• bastion's host keys are generated in the Dockerfile but they should probably be set using a secret
• sshd configuration is created using a RUN command, could be created as file to be copied at build time
• give the possibility to set parameters such as port number, namespace name, etc (just like it's done for the lab operator)
• default message in /etc/motd/ in case a user connects to the bastion without the -J jump option
• Ginkgo tests

[frisso]

Quoting from the PR description:

Resource updating the authorized_keys file at each tenant creation/deletion.

I would suggest to update the authorized_keys also when the tenant is updated. It would be useful to allow users to update the list of authorized keys in their profile.

[giorio94]

Thanks @claudious96. At a first sight, this PR seems very good!

A couple of comments with regard to your notes (and a few very minor inline):

1. Tenant resources are not namespaced
   

   CrownLabs/operators/deploy/crds/crownlabs.polito.it_tenants.yaml

   Line 17 in a2b3c24

   scope: Cluster

2. Totally agree about using the keys from a secret and not statically generate them in the docker
3. From my point of view, both generating the configuration using RUN and using an external file is fine. In the first case, you could use only one echo instruction instead of multiples.
4. Fine to have a separate manifest with the cluster role (makes it easier to apply the others from the CI)
5. Yes, it would be nice to have a bit of templating for the namespace, image version and so on

[giorio94]

Suggested change

	var list crownlabsalpha1.TenantList
	var tenants crownlabsalpha1.TenantList

Just a proposal, to make the code more readable

[claudious96]

Thanks for the input @frisso , I've just tested the case (updated the keys on an existing Tenant resource) and the authorized_keys file is correctly updated.
I'll update the description.

[claudious96]

@giorio94 I updated the PR with your suggestions.

The manifest can now be generated like the lab operator, setting desired values, then exporting the envs and substituting them in the template. In case of using the default namespace the result of the kubectl apply is namespace/default configured, I'm not sure if actually changes something though.

I wrote some instructions in the README inside the infrastructure/ssh-bastion folder to generate host keys and create the relative secret. I'm not sure if it's okay to have the inscructions there since the kubectl command depends on the namespace the deployment is going to run.

I have also updated the var you suggested in the bastion controller and the message in motd.

[giorio94]

/lgtm

Just a couple of minor comments inline.
Could you also add the bastion-operator to this list in order to automatically generate the Docker images?

CrownLabs/.github/workflows/build.yml

Lines 91 to 94 in 31092a7

	matrix:
	component:
	- laboratory-operator
	- crownlabs-image-list

[palexster]

/merge

[kingmakerbot]

Your staging environment has been correctly teared-down!