Rendu DevOps S8

[Oetgin]

DevOps et sécurité
Théo GINGUENÉ, Ewen LAURENT et Mael ALLIÉ

[Oetgin]

DevOps and security : PR report

Authors : Mael Allié, Ewen Laurent and Théo Ginguené

What was checked and why

We reviewed Docker orchestration, backend configuration, reverse proxy behavior, container images, build contexts, ignore rules, and git workflow controls, because most incidents come from leaked secrets, over-exposed internal services, or unsafe defaults or configurations.

Changes implemented

Internal service exposure reduced by default

We removed host port publication for the internal DB and SMTP services, removed direct Etherpad publication in favor of routing it through the frontend Nginx proxy under /pad/, and updated the external Etherpad URL to use that reverse-proxy path. The result is a smaller direct attack surface, with internal services reachable only through controlled entry points and centralized header enforcement and logging at the proxy layer. This applies the zero-trust and least-exposure principles.

Image version updating and pinning, where supported

This change covered the docker-compose and Dockerfiles. We pinned and updated image versions to reduce CVEs. That makes builds more reproducible and improves rollback reliability. Reproducible infrastructure and deterministic environments are core CI/CD reliability practices.

Prod now requires explicit secrets/config

This update only touched api/src/main/resources/application.yml. We added a %prod profile section that requires explicit datasource and doodle username, password, ..., while keeping defaults for development purposes. This prevents startup in production with default values and forces explicit configuration.

Frontend runtime moved to non-root container

For the frontend, we now use nginxinc/nginx-unprivileged:1.27-alpine, and nginx listens on 8080, which is mapped to host 4200 in compose. This reduces even further the security risk by running the frontend as an unprivileged user inside the container.

Docker build context hardening

We added ignore patterns for git metadata, env files, secret artifacts, logs, and temporary or build outputs. That reduces the risk of secrets leaking into image builds or layers (and speeds up builds).

Simple local pre-commit and pre-push secret checks

The local Git hooks in .githooks/ now use gitleaks. The pre-commit hook scans staged changes, the pre-push hook scans repository history. This stops secret leaks before they reach CI or remote branches, gives developer feedback, makes changes faster. It is a shift-left of the security checks.

CI security changes

We implemented a GitHub Actions CI security workflow that includes gitleaks, trivy, npm audit, and OWASP dependency-check. Global ignore rules cover env files and potential secret files, example env and secret templates were added, and the real API key file was removed from the repo.

Tutorial : How to use the new security setup

1. Prepare local secrets safely

1. Copy every *.env.example to *.env.
2. Fill values for MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD, and DOODLE_PADAPIKEY.
3. Copy api/APIKEY.txt.example to api/APIKEY.txt.local and set a real key.

2. Enable local secret-scanning hooks

1. Install gitleaks (see gitleaks installation).

2. Activate repository hooks path :

   git config core.hooksPath .githooks

3. Test with a commit : hooks should run automatically.

While not recommended, you can bypass hooks if needed with :

SKIP_GITLEAKS=1 git commit -m "bypass"

3. Start stack

docker compose up --build

What we would do next if we had more time

1. Add scanning on built artifacts.
2. Enforce branch protection requiring security checks before merge.
3. Move secrets to a secret manager for production.
4. Apply other best practices listed in DevSecOps practices and tools, table 5.

CI Result