-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
Description
Parent Epic: #250 - Implement Automated Docker Image Vulnerability Scanning
Overview
Enhance the Trivy scanning workflow to dynamically detect Docker images from environment configuration instead of using a hardcoded list. This eliminates manual maintenance and ensures the workflow automatically adapts when images change.
Goals
- Convert hardcoded Docker Compose image references to Tera variables
- Store Docker image references in environment data structure
- Expose image information through
showcommand - Update Trivy workflow to dynamically detect images
- Eliminate manual image list maintenance
Docker Images to Extract
From templates/docker-compose/docker-compose.yml.tera:
- Tracker:
torrust/tracker:develop - MySQL:
mysql:8.0 - Grafana:
grafana/grafana:11.4.0 - Prometheus:
prom/prometheus:v3.0.1
Implementation Phases
Phase 1: Domain Model Changes (1.5 hours)
- Create
DockerImagevalue object insrc/shared/docker_image.rs - Add
docker_imagefield to service configs (TrackerConfig, DatabaseConfig, PrometheusConfig, GrafanaConfig) - Implement
Defaulttrait with image constants - Add unit tests for
DockerImagevalue object
Phase 2: Template Updates (1 hour)
- Update Docker Compose template to use service-specific image variables
- Update template context (DockerComposeContext with tracker field)
- Test template rendering produces correct output
Phase 3: Show Command Enhancement (1 hour)
- Extend show command formatter to display Docker images from service configs
- Add unit tests for image formatting
- Test show command output includes images
Phase 4: Workflow Update (1.5 hours)
- Add
extract-imagesjob to workflow - Parse show command output for images
- Update
scan-extracted-imagesjob to use dynamic list - Remove hardcoded image list
Phase 5: Testing and Documentation (1 hour)
- Test complete workflow end-to-end
- Verify workflow adapts when images change
- Update documentation
Architecture
Key Design Principles:
- Service-specific variables belong in service config types (TrackerConfig, DatabaseConfig, etc.)
- Global/shared variables (database, ports) stay in DockerComposeContext
- Each service config owns its
docker_imagefield - Image versions are NOT user-configurable (compatibility/security)
Template Structure:
services:
tracker:
image: {{ tracker.docker_image.repository }}:{{ tracker.docker_image.tag }}
mysql:
image: {{ database.docker_image.repository }}:{{ database.docker_image.tag }}
prometheus:
image: {{ prometheus_config.docker_image.repository }}:{{ prometheus_config.docker_image.tag }}
grafana:
image: {{ grafana_config.docker_image.repository }}:{{ grafana_config.docker_image.tag }}Acceptance Criteria
Functional Requirements:
- Docker images stored in service configurations with constants
- Template uses service-specific image variables
- Show command displays Docker image information
- Workflow dynamically extracts images from show command
- Changing an image constant updates workflow automatically
- No manual image list maintenance required
Domain Model:
DockerImagevalue object validates image references- Images stored in each service configuration independently
- Default images set from constants in service
Defaultimplementations
Dependencies:
- Requires Implement Environment Show Command #241 (Show command) to be completed first
- If Implement Environment Show Command #241 not ready: implement minimal show command for images only
Estimated effort: 4-6 hours (depends on #241 completion)
Full specification: docs/issues/implement-dynamic-image-detection-for-scanning.md