<p>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:</p>

<ol>
<li><p>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?</p></li>
<li><p>Can SSH skip the Pod Security policies and access/mount paths on the underlying host which are restricted in pod security policy?</p></li>
<li><p>If SSH into containers is unavoidable, how to secure it in the best possible way?</p></li>
</ol>

<p>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 <code>kubectl exec</code> 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</p>

<ol>
<li><p>kubectl runs client-side. If there were features in it that would prevent you from escaping, you could just patch them out.</p></li>
<li><p>No, those are on the pod and handled by the underlying kernel. SSH would only get you a shell in the container, just like <code>kubectl exec</code> would.</p></li>
<li><p>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 <code>authorized_keys</code> 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.</p></li>
</ol>
