各种 Kubernetes 安全建议告诉你避免使用 SSH 进入容器，并要求改用 kubectl。引用的主要原因是可以通过 SSH 转义到容器中的底层主机资源。因此，我有以下具体疑问：
-
kubectl 的哪些功能阻止您访问主机资源，为什么与 kubectl 相比，ssh 访问主机资源的风险更大？库贝克特尔如何更安全？
-
SSH 是否可以跳过底层主机上受 Pod 安全策略限制的 Pod 安全策略和访问/挂载路径？
-
如果SSH进入容器是不可避免的，如何以最佳方式保护它？
如果原因是"你可以通过一个而不是另一个逃脱"，那么我认为它来自不了解所涉及的安全机制的人。 还有其他原因更喜欢kubectl exec而不是SSH，例如与其他Kubernetes集成的审计日志记录，以及轻松的访问撤销，但它们也可以使用SSH。这只是更多的工作
-
Kubectl 运行客户端。如果其中有一些功能可以阻止你逃脱，你可以把它们修补掉。
-
不，这些都在 Pod 上并由底层内核处理。SSH只会让你在容器中得到一个shell，就像
kubectl exec一样。 -
使用公钥身份验证，确保有一个策略来确保容器中的软件是最新的。考虑一下您将如何管理
authorized_keys文件并在那里撤销受损的SSH密钥。考虑是否应使用防火墙规则锁定对运行 SSH 的端口的访问。
仅仅因为您必须在容器中运行ssh服务器;因此，在容器中运行的额外进程并且必须管理密钥，才足以说明不想通过 SSH 连接到容器。
所以，这是一个缺点。另一个将与用例一起使用，这是一种风险。为什么要通过 SSH 连接到容器？我看到的一个原因是因为您想从外部主机执行此操作(没有安装kubectl并针对api-server进行身份验证(。因此，您必须向外部世界公开端点，或者至少向网络公开端点。