简体繁体 English

kubectl 如何比 SSH Daemon/访问容器更安全？

[英]How kubectl is more secure than SSH Daemon / access into containers?

原文 2020-01-25 08:14:52 8 2 security/ kubernetes/ ssh/ containers/ kubectl

Various Kubernetes security recommendations tell you to avoid SSH into containers and ask to use kubectl instead.各种 Kubernetes 安全建议告诉您避免 SSH 进入容器并要求改用 kubectl。 The prime reason quoted is the possibility of escaping to the underlying host resources via SSH into containers.引用的主要原因是通过 SSH 转义到底层主机资源到容器中的可能性。 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? kubectl 的哪些特性会阻止您访问主机资源，为什么与 kubectl 相比，ssh 访问主机资源的风险更大？ How kubectl is more secure? kubectl 如何更安全？
Can SSH skip the Pod Security policies and access/mount paths on the underlying host which are restricted in pod security policy? SSH 可以跳过 Pod 安全策略限制的底层主机上的 Pod 安全策略和访问/挂载路径吗？
If SSH into containers is unavoidable, how to secure it in the best possible way?如果 SSH 进入容器是不可避免的，那么如何以最好的方式保护它？

2 个解决方案

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.还有其他原因更喜欢kubectl exec不是 SSH，例如与 Kubernetes 的其他所有内容集成的审计日志记录，以及轻松的访问撤销，但它们也可以通过 SSH 获得。 It's just more work这只是更多的工作

kubectl runs client-side. kubectl 在客户端运行。 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.不，那些在 pod 上并由底层内核处理。 SSH would only get you a shell in the container, just like kubectl exec would. SSH 只会让你在容器中获得一个 shell，就像kubectl exec一样。
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.想一想您将如何管理authorized_keys文件并在那里撤销受损的SSH 密钥。 Consider whether you should lock down access to the port SSH is running on with firewall rules.考虑是否应该使用防火墙规则锁定对 SSH 正在运行的端口的访问。

Only because you have to run an ssh server in your container;只是因为您必须在容器中运行ssh服务器； 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.因此，在您的容器中运行一个额外的进程，并且必须管理密钥，这足以成为不想通过 SSH 进入容器的理由。

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?为什么要通过 SSH 连接到容器？ One reason I see is because you want to do it from an external host (without kubectl installed and authenticated against api-server ).我看到的一个原因是因为您想从外部主机执行此操作（未安装kubectl并针对api-server身份验证）。 So you have to expose an endpoint to outside world, or at least to your network.所以你必须向外界公开一个端点，或者至少向你的网络公开。