PS Product SecurityKnowledge Base

Docker, Linux, and Ansible Security Assessment Pack

Intro: These tasks test whether the candidate can see the security meaning of everyday operational shortcuts.

Task 1 - Docker run command with broad host exposure

docker run -d \
  --privileged \
  -v /:/host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --network host \
  registry.example.com/debug-tool:latest

Prompt

List the main risks. Which two flags would you call out first in a review?

Reveal the worked answer

Main risks

  • --privileged greatly expands host-level capabilities;
  • mounting / exposes the host filesystem;
  • mounting the Docker socket gives effective control over the host Docker daemon;
  • --network host collapses network isolation.

First two to call out

There is not one perfect answer, but many senior reviewers would call out --privileged and /var/run/docker.sock first because together they are a classic host-compromise route.

Task 2 - Dockerfile runs as root and ships extra tooling

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl vim netcat-traditional python3
COPY app /app
CMD ["/app"]

Prompt

Find the main hardening improvements.

Reveal the worked answer

Improvements

  • use a smaller runtime base where practical;
  • install only what the app needs;
  • clean package metadata if package manager use is unavoidable;
  • create and switch to a non-root user;
  • pin or review base image source and rebuild discipline.

Better direction

FROM debian:stable-slim
RUN useradd -r -u 10001 appuser
COPY app /app
USER 10001
ENTRYPOINT ["/app"]

Task 3 - Linux service account has an interactive shell and broad sudo

useradd cicd
echo 'cicd ALL=(ALL) NOPASSWD:ALL' >/etc/sudoers.d/cicd

Prompt

Why is this bad for a runner host or build host?

Reveal the worked answer

Why bad

A CI or automation account becomes a near-admin user. If any job or tool running as that account is compromised, the host is effectively lost.

Better direction

  • non-interactive shell where possible;
  • no blanket sudo;
  • narrowly scoped command allowlists if elevation is unavoidable;
  • move privileged operations out of the general build host.

Task 4 - Ansible uses ignore_errors: true on hardening tasks

- name: disable root ssh login
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PermitRootLogin'
    line: 'PermitRootLogin no'
  ignore_errors: true

Prompt

Why is this a red flag in security automation?

Reveal the worked answer

Why it matters

Security automation that silently fails produces false assurance. The playbook says the control exists, but the host may not actually be hardened.

Better approach

  • fail loudly for mandatory controls;
  • add validation tasks after change;
  • use handlers to restart services only when a change succeeds.