I have done that in the past, in order to be able to automate copying files to the container during testing or data migration. It was an ugly hack and now I need to make double sure none of those containers are still running…

Probably a lot of companies which have their own k8s cluster and segregate kubectl access to operations only. Developers still need a way to their app backend in some cases.

Kubernetes already comes with better solutions for that sort of thing. I could see a ssh bastion container for bridging to legacy infrastructure though. Manage its keys right and it's probably more secure than a lot of alternatives.

Even if you do this why allow it outside VPN?

You wouldn’t, but it would still remain an avenue for lateral movement

Everyone who has access to their container and not the host except by some terrible vnc or web console.

Several CICD solutions which offer "shell into container to debug a build failure".

You'd think they'd all do the smart thing and exec a shell into the container's namespace. You'd be wrong.

I've done it in the past with "serverless" sftp servers, which is how a lot of inter-company batch transfers happen for historical reasons, especially in the financial sector. I don't recall what images I used, but it was far easier to patch with a CI/CD pipeline. We did use keys, though.