为什么不需要在 Docker 容器中运行 sshd
发布网友
共2个回答
热心网友
What do you need SSH for?Most likely, you want to do backups, check logs, maybe restart the process, tweak the configuration, possibly debug the server with gdb, strace, or similar tools. We will see how to do those things without SSH.
How will you manage keys and passwords?Most likely, you will either bake those into your image, or put them in a volume. Think about what you should do when you want to update keys or passwords. If you bake them into the image, you will need to rebuild your images, redeploy them, and restart your containers. Not the end of the world, but not very elegant neither. A much better solution is to put the credentials in a volume, and manage that volume. It works, but has significant drawbacks. You should make sure that the container does not have write access to the volume; otherwise, it could corrupt the credentials (preventing you from logging into the container!), which could be even worse if those credentials are shared across multiple containers. If only SSH could be elsewhere, that would be one less thing to worry about, right?
How will you manage security upgrades?The SSH server is pretty safe, but still, when a security issue arises, you will have to upgrade all the containers using SSH. That means rebuilding and restarting all of them. That also means that even if you need a pretty innocuous memcached service, you have to stay up-to-date with security advisories, because the attack surface of your container is suddenly much bigger. Again, if SSH could be elsewhere, that would be a nice separation of concerns, wouldn’t it?
Do you need to “just add the SSH server” to make it work?No. You also need to add a process manager; for instance Monit or Supervisor. This is because Docker will watch one single process. If you need multiple processes, you need to add one at the top-level to take care of the others. In other words, you’re turning a lean and simple container into something much more complicated. If your application stops (if it exits cleanly or if it crashes), instead of getting that information through Docker, you will have to get it from your process manager.
You are in charge of putting the app inside a container, but are you also in charge of access policies and security compliance?In smaller organizations, that doesn’t matter too much. But in larger groups, if you are the person putting the app in a container, there is probably a different person responsible for defining remote access policies. Your company might have strict policies defining who can get access, how, and what kind of audit trail is required. In that case, you definitely don’t want to put a SSH server in your container.
译者信息
假设你正在假设一个Redis Server或Java Webservice的Docker镜像, 我会问你以下几个问题:
你需要用SSH来做什么? 一般来说, 你想做备份, 检查日志, 或者重启进程, 调整配置, 还有可能用gdb, strace或其他类似的工具来debug服务器。那我们会看一下我们怎么不使用SSH来做这些事情。
你怎么管理你的密钥和密码的？一般来说，你要么把它们写到你的镜像中，要么就把它们放在一个卷中。你想一下如果你要更新这些密钥或密码你会怎么做呢。如果你把它们写到镜像里了，你就需要重建镜像，重新部署它们，然后重启容器。这还好，不算是世界末日，但是这绝不是一个高大上的方法。把它们放到卷中，然后通过管理卷来管理它们倒是比前一种好得多。这种方法是可用的，可是却有严重的缺陷。你必须要确认容器没有这个卷的写权限；否则，容器有可能会破坏密钥（这让你之后就进不去容器了），如果你再用一个卷共享给多个容器的话，情况会变得更糟。如果不用SSH，我们不就少一个需要担心的事了吗？
你如何管理安全升级呢？SSH服务器是挺安全的，但是仍然会有安全问题，你会在必要的时候不得不升级所有使用SSH的容器。这意味着大量的重建和重启。也就是说，及时你有一个简单小巧的memcached服务，你还是不得不确保及时的安全更新，否则千里之堤可能毁于蚁穴。所以还是这句话，如果不用SSH，我们不就少一个需要担心的事了吗？
你需要“仅安装一个SSH服务器”来达到目的吗？当然不。你需要加装进程管理器，比如Monit或者Supervisor。这是因为Docker自己只会监视一个进程。如果你需要运行多个进程，你就必须在上面加装一层可以看着他们的应用。换句话说，你在把简单问题复杂化。如果你的应用停了（正常退出或者崩溃），你必须要从你的进程管理日志里面去查看，而不能简单的查看Docker提供的信息。
你可以负责把应用放到容器中，但你是否应该同时负责管理访问策略和安全*呢？在小机构中，这都不是事。但是在大型机构中，如果你是负责设立应用容器的人，那很可能有另外一个人负责定义远程访问策略。你所在的公司很可能有严格的策略定义说明谁能访问，如何访问或者其他各种审查跟踪的要求。那样的话，你肯定不会被允许把一个SSH服务器扔进你的容器中。
