Various Kubernetes security recommendations tell you to avoid SSH into containers and ask to use kubectl instead. The prime reason quoted is the possibility of escaping to the underlying host resources via SSH into containers. So, I have following specific queries:
Which features of kubectl prevent you to access host resources and why ssh has more risk of accessing host resources as compared to kubectl? How kubectl is more secure?
Can SSH skip the Pod Security policies and access/mount paths on the underlying host which are restricted in pod security policy?
If SSH into containers is unavoidable, how to secure it in the best possible way?
If the reason is "you can escape via one and not the other", then I think it comes from somebody who don't understand the security mechanisms involved. There are other reasons to prefer kubectl exec over SSH, such as audit logging integrated with everything else Kubernetes, and easy access revocation, but they are possible to get with SSH too. It's just more work
kubectl runs client-side. If there were features in it that would prevent you from escaping, you could just patch them out.
No, those are on the pod and handled by the underlying kernel. SSH would only get you a shell in the container, just like kubectl exec would.
Use public-key authentication, make sure to have a strategy for ensuring your software in the container is up-to-date. Think about how you're going to manage the authorized_keys file and revocation of compromised SSH keys there. Consider whether you should lock down access to the port SSH is running on with firewall rules.
Only because you have to run an ssh server in your container; thus an extra process running in your container, and have to manage the keys, is enough reason to not want to SSH into a container.
So, that's one drawback. Another one will go with the use case, and it's a risk. Why would you want to SSH into a container? One reason I see is because you want to do it from an external host (without kubectl installed and authenticated against api-server). So you have to expose an endpoint to outside world, or at least to your network.