# 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

```bash
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?

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### 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.

</details>

## Task 2 - Dockerfile runs as root and ships extra tooling

```dockerfile
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.

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### 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

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

</details>

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

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

### Prompt

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

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### 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.

</details>

## Task 4 - Ansible uses `ignore_errors: true` on hardening tasks

```yaml
- 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?

<details>

<summary><strong>Reveal the worked answer</strong></summary>

#### 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.

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-1/docker-linux-and-ansible-assessment-pack.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.