К основному содержанию
скилл CX Codex

docker-security-guide — скилл для Claude Code: аудит безопасности

Скилл для ИИ-агента, который проверяет Docker-конфигурации на уязвимости и подсказывает, как закрыть дыры.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add JosiahSiegel/claude-plugin-marketplace --skill docker-security-guide -a claude-code
Открыть на GitHub

Что делает docker-security-guide

Скилл включается, когда агент видит работу с контейнерами: ревью Dockerfile, запуск от non-root, read-only rootfs и tmpfs, сброс capabilities через --cap-drop ALL, профили seccomp и AppArmor, сканирование образов (Docker Scout, Trivy, Grype), подпись образов и SBOM, секреты через Docker secrets и BuildKit --secret, сегментация сетей и соответствие CIS Docker Benchmark.

Внутри — чек-лист харденинга, рецепты подключения сканеров, маппинг на пункты CIS, шаблоны работы с секретами и справочник по сбросу capabilities. Часть рецептов вынесена в references/build-runtime-security.md: там команды для build secrets, multi-stage сборки, seccomp/AppArmor/SELinux и rootless-режима. Если файла нет в проекте, агент не сможет открыть эти рецепты — это повод проверить, что скилл установлен целиком, а не одним SKILL.md.

Скилл работает поверх Docker и не заменяет сканеры: Docker Scout, Trivy и Grype нужно иметь в системе отдельно. Для проверки подписей понадобится DOCKER_CONTENT_TRUST=1.

Какие задачи решает

  • проверить Dockerfile на утечку секретов в слоях
  • запустить контейнер от non-root с read-only rootfs
  • сбросить все capabilities и вернуть только нужные
  • настроить сканирование образов в CI на CRITICAL
  • изолировать базу данных в internal-сети Compose

Примеры запросов агенту

  • проверь мой Dockerfile на безопасность и покажи, что исправить
  • настрой запуск этого контейнера от non-root с read-only rootfs
  • добавь в GitHub Actions шаг сканирования образа через Trivy с падением на CRITICAL

Как установить docker-security-guide

1Через Skills CLI (Vercel)

npx skills add JosiahSiegel/claude-plugin-marketplace --skill docker-security-guide -a claude-code

2Вручную: положить файлы

~/.claude/skills/docker-security-guide/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/docker-security-guide/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора11

tailwindcss-mobile-first Скилл для ИИ-агента, который подсказывает, как верстать адаптивные интерфейсы на Tailwind CSS v4 по принципу mobile-first. Пригодится, когда нужно разложить брейкпоинты, типографику и сетки по полочкам. CX Codex +1 2 100установок powershell-master Скилл для работы со скриптами PowerShell: подсказывает синтаксис cmdlet, модули PSGallery, шаблоны CI/CD и безопасность. Пригодится, когда агент пишет .ps1 или правит пайплайн. CX Codex +1 1 100установок docker-best-practices Скилл по Docker: подсказывает, как писать Dockerfile, выбирать базовый образ и настраивать контейнеры для продакшена. CX Codex +1 938установок git-master Скилл по Git для ИИ-агентов: подсказывает команды, страхует опасные операции и разбирает конфликты. Пригодится, когда агент лезет в историю репозитория. CX Codex +1 787установок tailwindcss-advanced-design-systems Скилл для сборки дизайн-системы на Tailwind v4: токены в @theme, цветовые шкалы, типографика, тени и тёмная тема. CX Codex +1 655установок tailwindcss-responsive-darkmode Скилл по Tailwind CSS: адаптивная вёрстка, тёмная тема, переключение на лету и защита от вспышки нестилизованного контента. CX Codex +1 476установок context-master Скилл для планирования сложных задач и многофайловых проектов. Заставляет агента сначала составить план, а потом писать файлы. CX Codex +1 397установок tailwindcss-fundamentals-v4 Скилл по Tailwind CSS v4: установка, CSS-first настройка через @theme, миграция с v3 и новые утилиты. Пригодится, когда проект переезжает на v4. CX Codex +1 389установок

Похожие

docker-expert sickn33 Скилл для ИИ-агента, который разбирает Dockerfile, multi-stage сборки и безопасность контейнеров. Пригодится, когда нужно навести порядок в образах и Compose. CX Codex +1 27 300установок docker-patterns affaan-m Скилл с проверенными шаблонами Dockerfile и Docker Compose: локальная разработка, сети, тома, безопасность контейнеров. CX Codex +1 6 400установок docker-management devops-skills Набор инструкций для сборки многоэтапных Dockerfile, настройки сетей и отладки контейнеров в Docker. Помогает изолировать окружение и находить ошибки в упавших процессах. CX Codex +1 508установок container-hardening devops-skills Настраивает запуск контейнеров без root-прав, монтирует файловую систему только для чтения и формирует манифесты Kubernetes securityContext. CX Codex +1 433установок docker-development Alireza Rezvani Скилл анализирует Dockerfile, Docker Compose и контейнеры: ищет проблемы с размером, сборкой и безопасностью. Подойдёт для настройки контейнеризации. 702установок hardening-docker-containers-for-production mahipal Скилл укрепляет Dockerfile, образы и настройки контейнеров по CIS Docker Benchmark v1.8.0. Пригодится перед production-развёртыванием и аудитом. CX Codex +1 320установок

Рядом в теме «Безопасность»

Всё по теме «Безопасность» →

Вопросы о docker-security-guide

Как установить docker-security-guide в Claude?

Выполните npx skills add JosiahSiegel/claude-plugin-marketplace --skill docker-security-guide -a claude-code. Скилл появится в ~/.claude/skills/docker-security-guide/SKILL.md.

Что делает docker-security-guide?

Даёт агенту правила и рецепты по безопасности Docker: харденинг контейнеров, сканирование образов, работа с секретами, сегментация сетей и проверка по CIS Docker Benchmark.

Какие инструменты нужны для сканирования?

Скилл описывает работу с Docker Scout, Trivy и Grype. Сами сканеры устанавливаются отдельно — скилл только подсказывает команды и настройку CI.

Исходный текст

SKILL.md · MIT
---
name: docker-security-guide
description: |
  Comprehensive Docker security guidelines and threat mitigation.
  PROACTIVELY activate for: (1) container security review, (2) running as non-root user, (3) read-only root filesystems and tmpfs mounts, (4) capability dropping (--cap-drop ALL), (5) seccomp and AppArmor profiles, (6) image vulnerability scanning (Docker Scout, Trivy, Grype), (7) supply-chain security (signed images, SBOM, provenance), (8) secrets management (Docker secrets, BuildKit --secret, external vaults), (9) network segmentation (user-defined networks, no --net=host), (10) CIS Docker Benchmark compliance.
  Provides: hardening checklist, scan-tool integration recipes, CIS benchmark mapping, secret handling patterns, and capability-drop reference.
---

## 🚨 CRITICAL GUIDELINES

### Windows File Path Requirements

**MANDATORY: Always Use Backslashes on Windows for File Paths**

When using Edit or Write tools on Windows, you MUST use backslashes (`\`) in file paths, NOT forward slashes (`/`).

**Examples:**
- ❌ WRONG: `D:/repos/project/file.tsx`
- ✅ CORRECT: `D:\repos\project\file.tsx`

This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems


### Documentation Guidelines

**NEVER create new documentation files unless explicitly requested by the user.**

- **Priority**: Update existing README.md files rather than creating new documentation
- **Repository cleanliness**: Keep repository root clean - only README.md unless user requests otherwise
- **Style**: Documentation should be concise, direct, and professional - avoid AI-generated tone
- **User preference**: Only create additional .md files when user specifically asks for documentation


---

# Docker Security Guide

This skill provides comprehensive security guidelines for Docker across all platforms, covering threats, mitigations, and compliance requirements.

## Security Principles

### Defense in Depth

Apply security at multiple layers:
1. **Image security:** Minimal, scanned, signed images
2. **Build security:** Secure build process, no secrets in layers
3. **Runtime security:** Restricted capabilities, resource limits
4. **Network security:** Isolation, least privilege
5. **Host security:** Hardened host OS, updated Docker daemon
6. **Orchestration security:** Secure configuration, RBAC
7. **Monitoring:** Detection, logging, alerting

### Least Privilege

Grant only the minimum permissions necessary:
- Non-root users
- Dropped capabilities
- Read-only filesystems
- Minimal network exposure
- Restricted syscalls (seccomp)
- Limited resources

## Image Security

### Base Image Selection

**Threat:** Vulnerable or malicious base images

**Mitigation:**
```dockerfile
# Use official images only
FROM node:20.11.0-alpine3.19  # Official, specific version

# NOT
FROM randomuser/node  # Unverified source
FROM node:latest      # Unpredictable, can break
```

**Verification:**
```bash
# Verify image source
docker image inspect node:20-alpine | grep -A 5 "Author"

# Enable Docker Content Trust (image signing)
export DOCKER_CONTENT_TRUST=1
docker pull node:20-alpine
```

### Minimal Images

**Threat:** Larger attack surface, more vulnerabilities

**Mitigation:**
```dockerfile
# Prefer minimal distributions
FROM alpine:3.19           # ~7MB
FROM gcr.io/distroless/static  # ~2MB
FROM scratch               # 0MB (for static binaries)

# vs
FROM ubuntu:22.04          # ~77MB with more packages
```

**Benefits:**
- Fewer packages = fewer vulnerabilities
- Smaller attack surface
- Faster downloads and starts
- Less disk space

### Micro-Distros for Security-Critical Applications (2025)

**Wolfi/Chainguard Images:**
- Zero-CVE goal, SBOM included by default
- Nightly security patches, signed with provenance
- Available for: Node, Python, Go, Java, .NET, etc.

**Usage:**
```dockerfile
# Development stage (includes build tools)
FROM cgr.dev/chainguard/node:latest-dev AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Production stage (minimal, zero-CVE goal)
FROM cgr.dev/chainguard/node:latest
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
ENTRYPOINT ["node", "server.js"]
```

**When to use:** Security-critical apps, compliance requirements (SOC2, HIPAA, PCI-DSS), zero-trust environments, supply chain security emphasis.

See `docker-best-practices` skill for full image comparison table.

### Vulnerability Scanning

**Tools:**
- Docker Scout (built-in)
- Trivy
- Grype
- Snyk
- Clair

**Process:**
```bash
# Scan with Docker Scout
docker scout cves IMAGE_NAME
docker scout recommendations IMAGE_NAME

# Scan with Trivy
trivy image IMAGE_NAME
trivy image --severity HIGH,CRITICAL IMAGE_NAME

# Scan Dockerfile
trivy config Dockerfile

# Scan for secrets
trivy fs --scanners secret .
```

**CI/CD Integration:**
```yaml
# GitHub Actions example
- name: Scan image
  run: |
    docker scout cves my-image:${{ github.sha }}
    trivy image --exit-code 1 --severity CRITICAL my-image:${{ github.sha }}
```

### Multi-Stage Builds for Security

**Threat:** Build tools and secrets in final image

**Mitigation:**
```dockerfile
# Build stage with build tools
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o app

# Final stage - minimal, no build tools
FROM gcr.io/distroless/base-debian11
COPY --from=builder /app/app /
USER nonroot:nonroot
ENTRYPOINT ["/app"]
```

**Benefits:**
- No compiler/build tools in production image
- Secrets used in build don't persist
- Smaller, more secure final image

## Build-Time & Runtime Security

Complete recipes for build secrets (`--mount=type=secret`, BuildKit), multi-stage hardening, capability drops (`--cap-drop=ALL`), seccomp / AppArmor profiles, read-only root, user namespaces, resource limits, and rootless runtime live in `references/build-runtime-security.md`. Core principles:

- **Build secrets:** use `--mount=type=secret` and `--mount=type=ssh`; never `ARG`/`ENV` for sensitive values.
- **Runtime:** drop all capabilities and add back what is needed; run read-only root; non-root user; resource limits; pinned image digests.
- **Profiles:** apply seccomp, AppArmor, and SELinux; combine with user namespaces.

See `references/build-runtime-security.md` for all commands and recipes.

## Network Security

### Network Isolation

**Threat:** Lateral movement between containers

**Mitigation:**
```yaml
networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No external access

services:
  web:
    networks:
      - frontend

  api:
    networks:
      - frontend
      - backend

  database:
    networks:
      - backend  # Isolated from frontend
```

### Port Exposure

**Threat:** Unnecessary network exposure

**Mitigation:**
```bash
# Bind to localhost only
docker run -p 127.0.0.1:8080:8080 my-image

# NOT (binds to all interfaces)
docker run -p 8080:8080 my-image
```

**In Compose:**
```yaml
services:
  app:
    ports:
      - "127.0.0.1:8080:8080"  # Localhost only
```

### Inter-Container Communication

```yaml
# Disable default inter-container communication
# /etc/docker/daemon.json
{
  "icc": false
}
```

Then explicitly allow via networks:
```yaml
services:
  app1:
    networks:
      - app-network
  app2:
    networks:
      - app-network  # Can communicate with app1

networks:
  app-network:
    driver: bridge
```

## Secrets Management

### Docker Secrets (Swarm Mode)

```bash
# Create secret
echo "mypassword" | docker secret create db_password -

# Use in service
docker service create \
  --name my-service \
  --secret db_password \
  my-image

# Access in container at /run/secrets/db_password
```

**In stack file:**
```yaml
version: '3.8'

services:
  app:
    image: my-image
    secrets:
      - db_password

secrets:
  db_password:
    external: true
```

### Secrets Best Practices

1. **Never in environment variables** (visible in `docker inspect`)
2. **Never in images** (in layer history)
3. **Never in version control** (Git history)
4. **Mount as files** with restricted permissions
5. **Use secret management systems** (Vault, AWS Secrets Manager, etc.)
6. **Rotate regularly**

**Alternative: Mounted secrets:**
```bash
docker run -v /secure/secrets:/run/secrets:ro my-image
```

## Compliance & Benchmarking

### CIS Docker Benchmark

Automated checking:
```bash
# Clone docker-bench-security
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

# Or run as container
docker run --rm --net host --pid host --userns host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc:/etc:ro \
  docker/docker-bench-security
```

### Key CIS Recommendations

1. **Host Configuration**
   - Keep Docker up to date
   - Restrict network traffic between containers
   - Set logging level to 'info'
   - Enable Docker Content Trust

2. **Docker Daemon**
   - Use TLS for Docker daemon socket
   - Don't expose daemon on TCP without TLS
   - Enable user namespace support

3. **Docker Files**
   - Verify Docker files ownership and permissions
   - Audit Docker files and directories

4. **Container Images**
   - Create user for container
   - Use trusted base images
   - Don't install unnecessary packages

5. **Container Runtime**
   - Run containers with limited privileges
   - Set resource limits
   - Don't share host network namespace

## Monitoring & Detection

### Logging

```yaml
services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        labels: "service,env"
        env: "ENV,VERSION"
```

**Centralized logging:**
```yaml
services:
  app:
    logging:
      driver: "syslog"
      options:
        syslog-address: "tcp://log-server:514"
        tag: "{{.Name}}/{{.ID}}"
```

### Runtime Monitoring

**Tools:**
- Falco: Runtime security monitoring
- Sysdig: Container visibility
- Prometheus + cAdvisor: Metrics
- Docker events: Real-time events

**Monitor for:**
- Unexpected processes
- File modifications
- Network connections
- Resource spikes
- Failed authentication
- Privilege escalation attempts

```bash
# Monitor Docker events
docker events --filter 'type=container' --filter 'event=start'

# Watch specific container
docker events --filter "container=my-container"

# Runtime security with Falco
docker run --rm -it \
  --privileged \
  -v /var/run/docker.sock:/host/var/run/docker.sock \
  -v /dev:/host/dev \
  -v /proc:/host/proc:ro \
  falcosecurity/falco
```

## Platform-Specific Security

### Linux

**User namespace remapping:**
```json
// /etc/docker/daemon.json
{
  "userns-remap": "default"
}
```

Benefits: Root in container → unprivileged on host

**SELinux:**
```bash
# Enable SELinux for Docker
setenforce 1

# Run with SELinux labels
docker run --security-opt label=type:svirt_sandbox_file_t my-image

# Volumes with SELinux
docker run -v /host/path:/container/path:z my-image
```

**AppArmor:**
```bash
# Check AppArmor status
aa-status

# Run with AppArmor profile
docker run --security-opt apparmor=docker-default my-image
```

### Windows

**Hyper-V isolation:**
```powershell
# More isolated than process isolation
docker run --isolation=hyperv my-image
```

**Windows Defender:**
- Ensure real-time protection enabled
- Configure exclusions carefully
- Scan images regularly

### macOS

**Docker Desktop security:**
- Keep Docker Desktop updated
- Enable "Use gRPC FUSE for file sharing"
- Limit file sharing to necessary paths
- Review resource allocation

## Security Checklist

**Image:**
- [ ] Based on official, minimal image
- [ ] Specific version tag (not `latest`)
- [ ] Scanned for vulnerabilities
- [ ] No secrets in layers
- [ ] Runs as non-root user
- [ ] Signed (Content Trust)

**Build:**
- [ ] .dockerignore configured
- [ ] Multi-stage build (if applicable)
- [ ] Build secrets handled properly
- [ ] Build from trusted sources only

**Runtime:**
- [ ] Non-root user
- [ ] Capabilities dropped
- [ ] Read-only filesystem (where possible)
- [ ] Security options set
- [ ] Resource limits configured
- [ ] Isolated network
- [ ] Minimal port exposure
- [ ] Secrets mounted securely

**Operations:**
- [ ] CIS benchmark compliance
- [ ] Logging configured
- [ ] Monitoring in place
- [ ] Regular vulnerability scans
- [ ] Incident response plan
- [ ] Regular updates
- [ ] Audit logs enabled

## Common Security Mistakes

❌ **NEVER:**
- Run as root
- Use `--privileged`
- Mount Docker socket (`/var/run/docker.sock`)
- Hardcode secrets
- Use `latest` tag
- Skip vulnerability scanning
- Expose unnecessary ports
- Disable security features
- Ignore security updates
- Trust unverified images

✅ **ALWAYS:**
- Run as non-root
- Drop capabilities
- Scan for vulnerabilities
- Use secrets management
- Tag with specific versions
- Enable security options
- Apply least privilege
- Keep systems updated
- Monitor runtime behavior
- Use official images

This security guide represents current best practices. Security threats evolve constantly—always check the latest Docker security documentation and CVE databases.

© JosiahSiegel · MIT · JosiahSiegel/claude-plugin-marketplace

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой