Week 10 - DevOps¶

Topic¶

Auditing a third-party container image for supply-chain risk (manual layer inspection with Dive, automated CVE scanning with Trivy), and migrating the existing MinIO and inventory API containers from raw docker run to a single Docker Compose stack — without losing the data they currently hold.

Company Requests¶

Ticket #1001: Audit the consultancy image

"We've started using a Docker image from an external consultancy team for the FizzOps inventory project. Compliance flagged it for review before we run it anywhere. Audit the image's layers manually — there have been a few high-profile supply-chain attacks lately and we don't want to be next. Specifically, identify any layer that introduces something it shouldn't."

Ticket #1002: Run an automated CVE scan

"On top of the manual audit, run a vulnerability scanner against the same image and report at least one CRITICAL CVE. We need this for the security review docs."

Ticket #1003: Consolidate Docker workloads with Compose

"Operations is tired of docker run commands buried in shell history. Our MinIO and inventory API containers should be managed declaratively. Move them into a single docker-compose.yml. The named volume holding our backup data and the inventory bind-mount must NOT be lost in the migration — those have real data."

Scoring Checks¶

• Check 10.1: The malicious layer's SHA256 digest is recorded in /home/centos/lab10/malicious_layer.txt.
  • Method: SSH into the VM, read the file, compare against the expected layer digest.
  • Expected: file exists; content (with optional sha256: prefix and any whitespace stripped) matches the expected digest. Unique prefixes of at least 12 hex chars are accepted.
• Check 10.2: A CRITICAL CVE-ID is recorded in /home/centos/lab10/malicious_cve.txt.
  • Method: SSH-based; read the file, validate the format, check membership in a curated allowlist of CRITICAL CVEs that Trivy reports against the image.
  • Expected: file exists; content matches CVE-YYYY-NNNNN; CVE-ID is on the accepted list.
• Check 10.3: The MinIO container is managed by Docker Compose.
  • Method: SSH; locate the MinIO container; check its labels for com.docker.compose.project.
  • Expected: MinIO container running with the Compose project label set.
• Check 10.4: The inventory API container is managed by Docker Compose.
  • Method: SSH; locate a container with /data/inventory mounted; check labels for com.docker.compose.project.
  • Expected: Inventory container running with the Compose project label set.

Tasks¶

Task 1: Prepare the audit environment¶

Create a working directory for this week's artefacts and install the two image-audit tools plus the Docker Compose plugin.

Reference: Technologies: Dive, Technologies: Trivy, Technologies: Docker Compose

Task 2: Audit the consultancy image with Dive¶

The consultancy team has provided a container image. Before running anything from it, audit its layers manually and identify the layer that introduces a clearly out-of-place file.

Reference: SOP: Container Operations — Audit an Image's Layers with Dive, Technologies: Dive

Task 3: Scan the consultancy image with Trivy¶

In parallel to the manual audit, run an automated vulnerability scan against the same image. The base image is deliberately old, so several CRITICAL CVEs will show up.

Reference: SOP: Container Operations — Scan an Image for Vulnerabilities with Trivy, Technologies: Trivy

Task 4: Migrate MinIO and the inventory API to Docker Compose¶

The two containers from week 9 (MinIO + inventory API) are currently managed by long docker run commands. Move them into a single docker-compose.yml so the stack can be brought up or down with one command. The migration must preserve the existing named volume backing MinIO and the /data/inventory bind mount used by the inventory API.

Reference: SOP: Container Operations — Migrate Containers from docker run to Docker Compose, Technologies: Docker Compose, Concepts: Container Orchestration

Ansible Tips¶

This section covers tips for automating the tasks in this lab with Ansible.

Audit Tools Installation¶

Both Dive and Trivy install idempotently:

- name: Install Dive
  dnf:
    name: "https://github.com/wagoodman/dive/releases/download/v0.13.1/dive_0.13.1_linux_amd64.rpm"
    state: present
    disable_gpg_check: yes

- name: Add Trivy repository
  yum_repository:
    name: trivy
    description: Trivy repository
    baseurl: "https://aquasecurity.github.io/trivy-repo/rpm/releases/$basearch/"
    gpgcheck: yes
    gpgkey: https://aquasecurity.github.io/trivy-repo/rpm/public.key

- name: Install Trivy and Compose plugin
  dnf:
    name:
      - trivy
      - docker-compose-plugin
    state: present

Compose File Deployment¶

Don't try to manage docker compose up from Ansible — it's not idempotent. Instead, deploy the supporting files and run Compose manually once. Same pattern as week 9's "build the supporting files, run the actual docker run once":

- name: Create lab10 project directory
  file:
    path: /home/centos/lab10
    state: directory
    owner: centos
    group: centos
    mode: '0755'

- name: Deploy docker-compose.yml
  copy:
    src: files/docker-compose.yml
    dest: /home/centos/lab10/docker-compose.yml
    owner: centos
    group: centos
    mode: '0644'

After Ansible has deployed the file, run sudo docker compose up -d from the project directory once.

Automation Limits¶

The Dive and Trivy audit steps are one-off security reviews — they don't need to be automated. Record the layer SHA and CVE-ID by hand. In a production setup, Trivy is usually invoked as a CI gate against every built image, but that's outside the scope of this lab.

Useful Modules¶

• dnf — install Dive (from a URL), Trivy, docker-compose-plugin
• yum_repository — declare the Trivy RPM repo
• copy / template — deploy docker-compose.yml from a fixed file or Jinja2 template
• file — create the project directory