Linux容器安全加固实战——用户命名空间Rootless Docker

安全背景与威胁模型

容器安全是云原生时代的核心议题。尽管容器技术提供了轻量级的隔离机制，但传统Docker和Kubernetes运行方式存在多个安全漏洞：

1. 容器逃逸风险：容器内root用户实际上与宿主机root共享同一个UID，攻击者可通过命名空间逃逸获得宿主机权限。

2. 内核漏洞利用：容器共享宿主机内核，内核漏洞可直接导致容器逃逸。

3. 特权容器滥用：privileged: true的容器拥有宿主机的全部设备访问权限。

4. Capabilities过度授予：默认Capabilities过多，增加了攻击面。

用户命名空间（User Namespaces）和Rootless Docker是解决上述问题的关键技术。

用户命名空间原理

映射机制

用户命名空间的核心是UID/GID映射。通过将容器内的UID映射到宿主机的非特权UID，实现：

容器内 UID范围        →  宿主机 UID范围
0 (root)             →  65534 (nobody)
1-65535              →  65535-131070
65536+               →  无法映射（超出范围）

内核配置要求

# 检查当前配置
cat /proc/sys/user/max_user_namespaces
cat /proc/sys/kernel/unprivileged_userns_clone
cat /proc/sys/kernel/userns_remap_rootfs

# 修改配置（需要root权限）
echo 65536 > /proc/sys/user/max_user_namespaces
echo 1 > /proc/sys/kernel/unprivileged_userns_clone
echo 1 > /proc/sys/kernel/userns_remap_rootfs

# 持久化配置 /etc/sysctl.d/99-userns.conf
user.max_user_namespaces = 65536
kernel.unprivileged_userns_clone = 1
kernel.userns_remap_rootfs = 1

Rootless Docker配置

什么是Rootless Docker

Rootless Docker是一种无需root权限即可运行Docker守护进程的模式。在Rootless模式下：
- Docker守护进程以普通用户身份运行
- 容器内的进程被映射到宿主机的非特权UID
- 不需要sudo或root权限来执行Docker命令

安装步骤

# 步骤1：安装Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

# 步骤2：安装Rootless Docker组件
sudo apt-get install -y uidmap slirp4netns

# 步骤3：配置当前用户为Docker用户组（可选，Rootless模式不需要）
sudo usermod -aG docker $USER

# 步骤4：初始化Rootless Docker
dockerd-rootless-setuptool.sh install

验证Rootless Docker状态

# 检查Docker服务状态
systemctl --user status docker

# 检查Docker信息
docker info

# 验证UserNS映射
docker run --rm alpine id
# 输出应显示非root UID，如 uid=65534(nobody)

# 检查容器进程命名空间
docker run -d --name test alpine sleep 3600
cat /proc/$(docker inspect -f '{{.State.Pid}}' test)/root/ns/user

Rootless Docker配置示例

# ~/.config/docker/daemon.json
{
  "userns-remap": "default",
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "features": {
    "buildkit": true
  }
}

Cgroup v2前置条件

为什么需要Cgroup v2

Cgroup v2是Linux控制组第二版，提供了更简单、更安全的资源控制机制。Rootless Docker和Kubelet-in-UserNS都需要Cgroup v2支持。

检查Cgroup版本

# 检查当前cgroup版本
stat -fc %T /sys/fs/cgroup
# 输出cgroup2fs表示已启用cgroup v2
# 输出cgroupfs表示仍在使用cgroup v1

# 检查systemd是否统一管理cgroup
systemd-cgls

启用Cgroup v2

# 编辑GRUB配置
sudo nano /etc/default/grub

# 在GRUB_CMDLINE_LINUX行添加
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"

# 更新GRUB
sudo update-grub

# 重启系统
sudo reboot

# 验证cgroup v2已启用
stat -fc %T /sys/fs/cgroup
# 应输出: cgroup2fs

Cgroup v2资源配置

# 创建用户级cgroup
systemctl --user import-environment
systemctl --user set-property docker.service MemoryMax=4G

# 配置容器资源限制
cat > ~/.config/systemd/user/docker.service.d/resources.conf << EOF
[Service]
MemoryMax=8G
CPUQuota=80%
EOF

# 重新加载配置
systemctl --user daemon-reload
systemctl --user restart docker

Kubelet-in-UserNS Beta特性

特性概述

Kubelet-in-UserNS是Kubernetes 1.32引入的Beta特性，允许kubelet在用户命名空间中运行。这提供了以下安全增强：

1. 隔离kubelet进程：kubelet进程不再以root身份运行

2. 限制节点访问：即使kubelet被攻击，攻击者也无法直接访问宿主机

3. 兼容UserNS容器：与User Namespaces GA特性协同工作

启用Kubelet-in-UserNS

# /etc/kubernetes/kubelet-config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
userNSMode: "local"
# 或使用"strict"模式（更严格的隔离）
# userNSMode: "strict"

# 启用相关Feature Gate
featureGates:
  KubeletInUserNamespace: true
  UserNamespacesSupport: true

Kubelet配置示例

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# 用户命名空间配置
userNSMode: "local"
# 容器运行时配置
containerRuntimeEndpoint: "unix:///run/containerd/containerd.sock"
# 安全上下文配置
seccompDefault: true
# 只读端口
readOnlyPort: 0
# 认证授权
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
    cacheTTL: 2m0s
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 5m0s
    cacheUnauthorizedTTL: 30s

# 应用配置并重启kubelet
sudo cp kubelet-config.yaml /etc/kubernetes/
sudo systemctl restart kubelet
sudo systemctl status kubelet

# 验证UserNS模式
kubectl get nodes -o wide | grep -i userns

Device Plugin与DRA驱动兼容性

兼容性问题

当启用UserNS后，传统的Device Plugin可能无法正常工作，因为：
1. 设备文件权限问题
2. UID映射导致设备访问失败
3. NVIDIA等GPU驱动的用户空间组件需要特殊配置

NVIDIA GPU兼容性配置

# 配置NVIDIA Container Toolkit
cat > /etc/nvidia-container-runtime/config.toml << 'EOF'
[default]
return-base-capabilities = false

[nvidia-container-cli]
root = "/run/nvidia/driver"
path = "/usr/bin/nvidia-container-cli"
environment = []
ldcache = "/etc/ld.so.cache"
loads-primary = true
capabilities = ["cap_sys_admin"]
dmabuf-helper = true

[nvidia-container-runtime]
mode = "cri"
EOF

# 配置设备权限
sudo chmod 666 /dev/nvidia*
sudo chmod 666 /dev/nvidiactl
sudo chmod 666 /dev/nvidia-modeset

# Pod配置 - 启用UserNS并请求GPU
apiVersion: v1
kind: Pod
metadata:
  name: gpu-test
spec:
  securityContext:
    runAsUser: 0
    runAsGroup: 0
    fsGroup: 0
    sysctls:
      - name: kernel.unprivileged_userns_clone
        value: "1"
  containers:
  - name: gpu-container
    image: nvidia/cuda:12.0-base
    command: ["nvidia-smi"]
    resources:
      limits:
        nvidia.com/gpu: 1
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      seccompProfile:
        type: RuntimeDefault

DRA驱动适配

// DRA Driver需要适配UserNS环境
type UserNSAwareDriver struct {
    baseDriver
    uidMap []mapping
}

func (d *UserNSAwareDriver) Allocate(ctx context.Context, claim *ResourceClaim) (*AllocationResult, error) {
    // 检查UID映射
    if claim.Spec.UserNS != nil {
        // 使用映射后的UID访问设备
        d.uidMap = claim.Spec.UserNS.Mapping
    }
    return d.baseDriver.Allocate(ctx, claim)
}

安全加固最佳实践

1. 容器运行时安全

# 启用seccomp默认配置
# /etc/docker/daemon.json
{
  "seccomp-profile": "/etc/docker/seccomp.json",
  "userns-remap": "default",
  "no-new-privileges": true
}

# 自定义seccomp配置
cat > /etc/docker/seccomp.json << 'EOF'
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {"names": ["read", "write", "open", "close"], "action": "SCMP_ACT_ALLOW"},
    {"names": ["stat", "fstat", "lstat"], "action": "SCMP_ACT_ALLOW"},
    {"names": ["ioctl"], "action": "SCMP_ACT_ALLOW"},
    {"names": ["mmap"], "action": "SCMP_ACT_ALLOW"},
    {"names": ["brk"], "action": "SCMP_ACT_ALLOW"},
    {"names": ["execve"], "action": "SCMP_ACT_ALLOW"}
  ]
}
EOF

2. Kubernetes安全配置

# PodSecurityPolicy（已废弃，使用Pod Security Admission）
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65534
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
# Pod Security Admission配置
apiVersion: v1
kind: Namespace
metadata:
  name: secure-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. 网络隔离

# 启用NetworkPolicy
kubectl apply -f - << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - port: 8080
EOF

安全加固检查清单

# 1. 检查容器运行时安全配置
docker info | grep -E "Security|Rootless"

# 2. 验证seccomp配置
cat /proc/$(pidof dockerd)/root/seccomp/profile

# 3. 检查Capabilities
docker run --rm --cap-drop=ALL alpine cat /proc/self/status | grep Cap

# 4. 验证UserNS映射
docker run --rm alpine id
cat /proc/$(docker ps -q -l)/root/uid_map

# 5. 检查cgroup版本
stat -fc %T /sys/fs/cgroup

# 6. 验证Kubelet安全配置
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.nodeInfo.osImage}{"
"}{end}'

常见安全漏洞及修复

安全加固检查清单

# 1. 检查容器运行时安全配置
docker info | grep -E "Security|Rootless"

# 2. 验证seccomp配置
cat /proc/$(pidof dockerd)/root/seccomp/profile

# 3. 检查Capabilities
docker run --rm --cap-drop=ALL alpine cat /proc/self/status | grep Cap

# 4. 验证UserNS映射
docker run --rm alpine id
cat /proc/$(docker ps -q -l)/root/uid_map

# 5. 检查cgroup版本
stat -fc %T /sys/fs/cgroup

# 6. 验证Kubelet安全配置
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.nodeInfo.osImage}{"
"}{end}'

常见安全漏洞及修复

安全加固的最佳实践

1. 最小权限原则：容器应以非root用户运行，禁用不必要的Capabilities

2. 只读文件系统：使用readOnlyRootFilesystem防止容器内文件被篡改

3. 网络隔离：使用NetworkPolicy限制容器间的网络通信

4. 镜像安全：定期扫描镜像漏洞，使用经过验证的基础镜像

5. 运行时安全：部署运行时安全监控，实时检测异常行为

通过实施上述安全措施，可以显著降低容器环境的安全风险，保护业务系统的稳定性和安全性。

生产环境安全配置示例

以下是一个完整的生产环境安全配置示例：

# Pod安全配置
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  # 启用UserNS
  securityContext:
    runAsNonRoot: true
    runAsUser: 65534
    runAsGroup: 65534
    fsGroup: 65534
    seccompProfile:
      type: RuntimeDefault
  # 禁用特权模式
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
    - name: config
      mountPath: /etc/config
      readOnly: true
  volumes:
  - name: tmp
    emptyDir: {}
  - name: config
    configMap:
      name: app-config

自动化安全检查脚本

#!/bin/bash
# security-audit.sh - 容器安全审计脚本

echo "=== 容器安全审计 ==="
echo ""

# 检查特权容器
echo "1. 检查特权容器..."
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.privileged}{"
"}{end}' | grep true

# 检查root用户运行
echo ""
echo "2. 检查root用户容器..."
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.runAsUser}{"
"}{end}' | grep ":0"

# 检查Capabilities
echo ""
echo "3. 检查Capabilities配置..."
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{range .spec.containers[*].securityContext.capabilities}{.add}{" "}{end}{"
"}{end}'

echo ""
echo "=== 审计完成 ==="

安全事件响应流程

当发现安全事件时，建议按以下流程处理：

1. 检测：通过运行时安全监控发现异常行为

2. 隔离：立即隔离受影响的容器或Pod

3. 分析：收集日志和证据，分析攻击路径

4. 修复：修补漏洞，更新安全配置

5. 恢复：恢复服务，验证安全性

6. 总结：编写安全事件报告，改进安全策略

总结

Linux容器安全加固是一个系统性工程，需要综合考虑：

1. 用户命名空间：将容器root映射为宿主机非特权用户，从根本上消除特权提升风险。

2. Rootless Docker：以非特权用户运行Docker守护进程，减少攻击面。

3. Cgroup v2：提供更安全、更简单的资源隔离机制。

4. Kubelet-in-UserNS：在Kubernetes层面实现kubelet进程的安全隔离。

5. DRA驱动适配：确保硬件设备在UserNS环境下的正确访问。

运维团队应按照"纵深防御"原则，层层加固容器运行环境，同时建立完善的监控和审计机制，确保容器安全策略的有效执行。