Cloud Security in Practice

Chapter 1: Docker Security

1.1 Docker Core Concepts and Architecture

Docker is the most widely adopted containerization platform today. Containerization is not virtualization—it leverages Linux kernel features like Namespaces and Cgroups to achieve lightweight process isolation.

Core Concepts

Image: A read-only template containing everything an application needs to run—code, runtime, libraries, and environment variables. Images are built in layers, each layer representing a single Dockerfile instruction. Images are immutable—once built, they cannot be modified.

Container: A running instance of an image. A writable layer is added on top of the image's read-only layers. Containers are isolated from each other but share the host kernel.

Registry: A storage and distribution hub for images. Docker Hub is the default public registry. Enterprises typically set up private registries (e.g., Harbor).

Architecture Layers

┌──────────────────────────────┐
│  docker CLI（用户输入命令）    │
├──────────────────────────────┤
│  dockerd（Docker 守护进程）    │ ← 以 root 运行，监听 /var/run/docker.sock
├──────────────────────────────┤
│  containerd（容器运行时管理）   │
├──────────────────────────────┤
│  runc（OCI 容器运行时）        │ ← 实际创建容器进程
└──────────────────────────────┘

dockerd runs with root privileges. Any user or process that can access the Docker socket (/var/run/docker.sock) effectively has root access on the host—this is the single biggest security risk in Docker.

1.2 Docker Security Isolation Mechanisms

Docker is not a "secure VM"—it is a packaged combination of Linux kernel features.

**Namespaces—Isolating What a Container Can See**

**Cgroups (Control Groups)—Limiting Resources**

Restricts how many CPU cores, how much memory, and what disk I/O rate a container can use. Prevents a single container from exhausting all host resources.

Capabilities—Splitting Root's Power into Pieces

In traditional Linux, root has absolute power. Capabilities break that power into fine-grained units. By default, Docker drops the following dangerous capabilities when starting a container:

• CAP_SYS_ADMIN (system administration—including mount)
• CAP_NET_RAW (raw sockets—including network sniffing)
• CAP_SYS_PTRACE (process tracing—including ptrace debugging of other processes)
• CAP_SYS_MODULE (loading/unloading kernel modules)
• and 10 others, 14 in total

Seccomp (Secure Computing Mode)—System Call Filtering

Limits which Linux system calls a process inside a container can invoke. Docker's default Seccomp profile blocks around 44 dangerous syscalls (such as reboot, kexec_load, and clock_settime).

1.3 Container Escape

Container escape means breaking through multiple isolation mechanisms from inside a container to gain access to the host. At its core, it happens because the user granted the container too many privileges, undermining the isolation.

Path 1: Privileged Containers (--privileged)

# 启动特权容器
docker run -d --privileged --name test nginx:1.25

--privileged does not just give the container "a few more capabilities"—it lets the container do anything the host can do. This includes loading kernel modules, accessing all devices (/dev/), modifying kernel parameters, and more.

Inside a privileged container:

# 1. 查看宿主机磁盘设备
fdisk -l/df -h
# 输出：
# /dev/sda1  → 宿主机的系统盘
# 2. 挂载宿主机根分区
mkdir /tmp/host
mount /dev/sda1 /tmp/host
# 3. 切换到宿主机环境
chroot /tmp/host
# 4. 此时已在宿主机上，可以：
# - 读取 /etc/shadow（密码哈希）
# - 安装 SSH 后门
# - 修改任何文件

Quick detection script:

docker ps --quiet | xargs docker inspect --format ''{{.Name}}: Privileged={{.HostConfig.Privileged}}''
# 示例输出：/test: Privileged=true  ← 危险

Path 2: Mounting the Docker Socket

docker run -d -v /var/run/docker.sock:/var/run/docker.sock --name test nginx:1.25

The Docker socket (/var/run/docker.sock) is the API entry point for dockerd. Any process that can talk to this socket has full control over Docker—creating containers, deleting containers, pulling images, executing commands. Mounting it into a container = handing over control of the host's Docker to that container.

This is currently the most common and most easily exploited escape path in Kubernetes clusters.

1. Why Is This Socket So Powerful?
/var/run/docker.sock is the UNIX socket for the Docker daemon (dockerd). dockerd always runs as rootroot. Accessing this socket means you have root-level API access on the host.

Exploiting it from inside a container:

# 在容器内安装 Docker CLI
apt update && apt install -y docker.io

# 通过挂载的 Socket 在宿主机上创建新容器
docker -H unix:///var/run/docker.sock run -it --privileged -v /:/host ubuntu chroot /host
# 这行命令的含义：
# -H unix:///var/run/docker.sock → 连接宿主机的 Docker 守护进程
# --privileged → 新容器拥有全部权限
# -v /:/host → 将宿主机根目录挂载到新容器的 /host
# chroot /host → 切换到宿主机根文件系统→ 获得宿主机完全控制

4. Defensive Measures
If your workload requires mounting this socket (e.g., CI/CD containers), apply the following mitigations to reduce risk:

• Disable the root user: inside the container, use USER 1000 to run processes. (The socket is still mounted, but non-root users have limited permissions and cannot execute destructive API calls.)
• **Use --group-add**: add the container user to the host's docker group (still dangerous; only appropriate for low-risk environments).
• Ultimate solution: use Rootless Docker or Podman to remove root privileges from the daemon entirely.

Path 3: CAP_SYS_ADMIN + cgroup

If a container has the CAP_SYS_ADMIN capability and cgroup is writable, an attacker can use the cgroup notify_on_release mechanism to execute arbitrary commands on the host. This path involves fairly complex kernel internals, but it is extremely dangerous when the conditions are met.

1.4 Image Security

CVE Vulnerability Scanning

Docker images are built on Linux distributions (like Debian or Alpine) that contain hundreds of system packages. Outdated images may harbor known critical vulnerabilities.

Real-World Case—Dependency Confusion Attack: In 2023, an attacker uploaded a malicious package named python-dateutil to PyPI (differing from the popular python-dateutil by just one hyphen). A developer mistakenly ran pip install python-dateutil, causing the malicious code to be baked into an image and deployed to production.

# 下载 Trivy
# https://github.com/aquasecurity/trivy/releases（下载 Windows 版）

# 扫描本地镜像
trivy image nginx:latest
# 输出：列出所有已知 CVE，按严重程度分类

# 对比：扫描一个多年未更新的镜像
docker pull node:14
trivy image node:14
# 输出：数百个漏洞，包括大量 HIGH 和 CRITICAL 级别

Dockerfile Security Principles

1.5 Unauthorized Registry Access

Docker Registry is a repository service for storing and distributing Docker images. When misconfigured (no authentication enabled), an attacker can:

1. Access the Registry API anonymously (no credentials required)
2. List all image repositories (leaking business information)
3. Pull or overwrite images (potentially planting backdoors)

This vulnerability is a high-severity configuration flaw (CWE-284: Improper Access Control).

# 测试匿名访问
curl https://<registry>/v2/_catalog
# 返回 {"repositories":["app1","app2",...]} → 未授权访问

# 列出所有镜像标签
curl https://<registry>/v2/<image>/tags/list

# 拉取镜像
docker pull <registry>/<image>:<tag>

Chapter 2: Kubernetes Security

2.1 K8s Architecture and Core Concepts

Kubernetes (K8s for short—there are 8 letters between K and s) is a container orchestration platform. When your application needs to run across dozens or even thousands of servers, manually managing Docker containers becomes impossible. K8s automates scheduling, scaling, load balancing, and self-healing for containers. You just tell it how many replicas you want, and it automatically finds machines, starts containers, and restarts them if they crash.

Control Plane (also called Master Nodes)—the brain of the cluster

Worker Nodes—where actual applications run

2.2 Core Resource Objects

2.3 RBAC Security Audit

RBAC (Role-Based Access Control) is the permission management system in K8s. Core principle: Who (Subject) + What Action (Verb) + On What (Resource) + Where (Namespace/Cluster).

Three High-Risk Configurations

High Risk 1: Wildcard *:*:*

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

This single rule grants every possible operation on every resource across all API groups—equivalent to cluster-admin.

# 审计命令：找出所有使用通配符的 Role/ClusterRole
kubectl get clusterroles -A -o yaml | grep -E "apiGroups.*\*|resources.*\*|verbs.*\*"

High Risk 2: Default SA Bound to cluster-admin

kubectl get clusterrolebindings -o json | jq ''.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}''

If the output contains system:serviceaccount:default:default or something similar, it means the default ServiceAccount in the default namespace (shared by all Pods that don't specify a custom SA) has cluster-admin privileges. Anyone inside such a Pod can control the entire cluster.

High Risk 3: Pod Create + Exec Permissions

rules:
- apiGroups: [""]
  resources: ["pods", "pods/exec"]
  verbs: ["create", "get"]

An attacker with create pods + exec pods permissions can create a privileged Pod and escape.

2.4 Accessing the API Server from Inside a Pod

By default, every Pod has three files mounted at the following paths:

ls /var/run/secrets/kubernetes.io/serviceaccount/
# ca.crt      ← API Server 的 CA 证书
# namespace   ← Pod 所在的 Namespace
# token       ← JWT 格式的 ServiceAccount Token

Using the Token to Access the API Server

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
APISERVER=https://kubernetes.default.svc

# 列出当前 Namespace 的 Pod
curl -k -H "Authorization: Bearer $TOKEN" $APISERVER/api/v1/namespaces/default/pods

# 如果返回 Pod 列表 → 该 SA 有 list pods 权限
# 如果返回 403 Forbidden → 安全

2.5 Pod Security Configuration

Complete Secure Pod Template

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  # Pod 级别安全上下文
  securityContext:
    runAsNonRoot: true              # 强制以非 root 运行
    runAsUser: 1000                 # 指定运行用户
    seccompProfile:
      type: RuntimeDefault          # 使用默认 Seccomp 策略（阻止 ~44 个危险系统调用）
  containers:
  - name: app
    image: nginx:1.25
    securityContext:
      privileged: false             # 非特权
      allowPrivilegeEscalation: false  # 禁止任何形式的提权（包括 suid）
      readOnlyRootFilesystem: true     # 根文件系统只读（需要写入的目录需单独挂载 volume）
      capabilities:
        drop: ["ALL"]               # 移除所有 Capabilities

Quickly Check for Dangerous Pods in the Cluster

# 特权 Pod
kubectl get pods -A -o json | jq ''.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.name''

# 挂载宿主机目录的 Pod（hostPath）
kubectl get pods -A -o json | jq ''.items[] | select(.spec.volumes[].hostPath) | {name, paths: [.spec.volumes[].hostPath.path]}''

# 以 root 运行的 Pod
kubectl get pods -A -o json | jq ''.items[] | select(.spec.containers[].securityContext.runAsUser==0) | .metadata.name''

2.6 K8s Hardening Checklist

Chapter 3: CI/CD Security

3.1 Pipeline Attack Surface

源码仓库（GitHub/GitLab/Gitee）
  ↓ 凭据泄露、.git 目录暴露、分支保护缺失
构建系统（Jenkins/GitHub Actions/GitLab CI）
  ↓ 构建脚本注入、恶意依赖（typosquatting）、环境变量泄露
制品仓库（Docker Registry/Nexus/Artifactory）
  ↓ 镜像投毒、标签覆盖、未授权拉取/推送
部署环境（K8s/云主机）
  ↓ 部署配置错误、过度权限、Secret 泄露

3.2 Source Code Security—Credential Scanning

# 使用 GitLeaks 扫描（https://github.com/gitleaks/gitleaks）
gitleaks detect --source . --verbose

# 手动搜索国内云平台 AccessKey
grep -rE "LTAI[0-9A-Za-z]{16,20}" .     # 阿里云
grep -rE "AKID[0-9A-Za-z]{13,20}" .     # 腾讯云

# 搜索私钥
grep -rE "-----BEGIN (RSA|EC|DSA) PRIVATE KEY-----" .

# 搜索密码
grep -rE "password\s*=\s*[\x27\x22][^\x27\x22]+" .

3.3 Build and Deployment Security

• Do not print environment variables in build logs
• Configure authentication for artifact registries
• When deploying to K8s, check for hardcoded credentials in environment variables:

kubectl get pods -A -o yaml | grep -iE "SECRET|TOKEN|PASSWORD|ACCESS_KEY"

Chapter 4: Local Lab Environment

All labs run on your personal machine, at zero cost

# Docker Desktop
# https://www.docker.com/products/docker-desktop/

# 启用内置 K8s
# 设置 → Kubernetes → Enable Kubernetes

# 第三步：安装安全工具
# Trivy: https://github.com/aquasecurity/trivy/releases
# kubeaudit: https://github.com/Shopify/kubeaudit/releases

# 环境就绪后验证：
# docker run --rm alpine sh
# trivy image node:14-alpine
# kubectl get pods -A

# 或使用 minikube
# https://minikube.sigs.k8s.io/docs/start/
minikube start