【问题标题】:Kubernetes: Linux user managementKubernetes:Linux用户管理
【发布时间】:2018-05-21 10:41:32
【问题描述】:

我们在 Kubernetes 中运行 docker 容器。 Docker 允许在主机系统级别以不同用户运行容器。

我正在查看几个 Helm 图表,例如,Prometheus 似乎以“nobody”身份运行,而Grafana 正在使用 Dockerfile 中的 useradd 创建其用户(硬编码 id)。

有什么方法可以标准化 Kubernetes 中的行为,可能确保只有容器需要系统上的用户存在?并且一旦容器被安排在别处就被移除。

我也担心我们会得到 userId 冲突,导致意外的行为,这将很难测试......

【问题讨论】:

  • 如果我理解正确,您需要类似 rbac 的东西来限制用户。这在 kubernetes 中得到支持 kubernetes.io/docs/admin/authorization/rbac
  • RBAC afaik 仅解决了对 K8s 资源的限制(它的 API、Pod、谁可以进行部署/更改等)。我要解决的是操作系统级别的权限,因为容器和主机共享相同的内核、用户和组。如果一个容器被入侵,攻击者可以将攻击升级到给定主机上的其他容器。
  • 你认为它与 Docker 容器化的关系比与 Kubernetes 更相关吗?这篇文章可能会有所帮助:medium.com/@mccode/…
  • Stack Overflow 是一个编程和开发问题的网站。这个问题似乎离题了,因为它与编程或开发无关。请参阅帮助中心的What topics can I ask about here。也许Super UserUnix & Linux Stack Exchange 会是一个更好的提问地点。
  • 实际上将基础架构中的用户作为代码处理是一个开发问题。我不是在问用户如何在 *nix 系统中工作,我有一些想法。我在问,应用程序级别的合理自动化是什么。它是 IaC 中的一些构造,是额外的 init pod 吗? grafana 方法是正确的吗?一旦我将代码部署到生产中,这将造成最少的麻烦。 sw 开发的世界并非非黑即白。并且一旦包含系统用户,就不一定是服务器管理问题...

标签: linux docker kubernetes


【解决方案1】:

容器没有必要拥有具有在 docker 主机上容器内使用的 UID 的用户。

示例如下:

On the docker host machine:

# Mongo container is running
root@docker-test:~# docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
08495ae15f44        mongo:latest        "docker-entrypoint..."   23 minutes ago      Up 23 minutes       27017/tcp           some-mongo

# mongod process is running under UID 999
root@docker-test:~# ps aux | grep mongo | grep -v grep
999      14035  0.6  1.7 986136 67612 ?        Ssl  08:56   0:01 mongod --bind_ip_all

# there is no user with UID 999 id on the docker host machine
root@docker-test:~# cat /etc/passwd | grep 999
root@docker-test:~# 

Inside the container:

# attaching to container
root@docker-test:~# docker exec -it 08495ae15f44 bash

# mongod process is running with privileges of the mongodb user
root@08495ae15f44:/# ps aux | grep mongo | grep -v grep
mongodb      1  0.4  1.8 990320 70036 ?        Ssl  08:56   0:02 mongod --bind_ip_all

# user mongodb is present inside the container in /etc/passwd and has UID 999
root@08495ae15f44:/# cat /etc/passwd | grep mongodb
mongodb:x:999:999::/home/mongodb:/bin/sh
root@08495ae15f44:/# 

【讨论】:

  • 这并不完全正确。用户空间在主机内核级别共享,因此如果您以 id=1234 的用户身份运行一个 containerA,则它与 containerB 中的用户 1234 是同一用户。这也意味着您创建的任何文件都可以访问(在两个空间中)。因此,如果一个容器发生故障,其他容器发生碰撞就会成为问题。 (但是是的,这种情况下不会发生硬碰撞。仅在 Grafana 风格的用户创建中)
  • 你的意思是,这并不全是真的。 ) 当您的容器消失时,您在容器内使用的具有 UID 的用户的主机 docker 机器上没有任何痕迹。因此,您无需费心事后手动删除它。你是对的,如果你有两个容器,它们使用相同的进程 UID 运行,如果你为它们配置相同的共享目录,或者其中一个逃离 chroot 环境,理论上它们可以访问彼此的文件。
  • 谢谢,澄清一下。但是还有一件小事:在 prometheus 中,我们谈论的是可以访问主机磁盘的有状态组件。所以我想如果 Prom 的 UID=A,那么所有其他 UID=A 的组件(逃离沙箱)都可以访问这些文件? (尽管普罗米修斯本身早已死去)
  • Pod 默认无权访问主机文件系统。文件系统访问应通过卷或特殊绑定配置(例如:cloud.google.com/container-optimized-os/docs/how-to/toolbox)。如果您与不完全信任的人共享 Kubernetes 集群,您可能需要使用带有额外身份验证层的后端来配置卷。
猜你喜欢
  • 1970-01-01
  • 2023-03-28
  • 1970-01-01
  • 2011-09-16
  • 2015-03-07
  • 2017-01-08
  • 2010-12-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多