Hardened Swarm & Gentoo Linux Security Architecture Specification

01

AWS Architecture: Network Perimeter & Load Balancing

The infrastructure is deployed within an isolated Amazon Web Services Virtual Private Cloud (VPC) with a custom configuration designed to maximize control over the trusted zone.

VPC Configuration

Parameter	Configured Value	Description
CIDR Block	`10.31.0.0/16`	Dedicated private IP range with zero risk of collision.
VPC ID	`vpc-0123456789abcdef0` (anonymized)	Unique virtual network identifier.
Instance Tenancy	`default`	Hardware tenancy mode.
Name (Tag Name)	`v2uat.secure-platform.net`	Environment tag for resource control.
Internet Gateway Block	`off` (manual routing)	Public internet access is strictly restricted and managed via Security Groups.

All subnets and routing tables are configured manually, avoiding default VPC resources and automatic resource association.

Load Balancing (AWS NLB)

Incoming platform traffic passes through an AWS Network Load Balancer (NLB) operating in TCP Passthrough (L4) mode. The TLS session is not terminated at the load balancer; instead, it is passed directly to the NGINX layer within the containers. This prevents traffic decryption inside the public cloud outside the controlled boundary.

Listener Configuration:

Parameter	Value
Protocol	`TCP`
Port	`443`
TLS Termination	⚠️ No (Passthrough to NGINX)
Action Type	`forward`
Target Group	`nginx-targets (port 443)`

ℹ️

Node Health Check (HealthCheck)

Health checks are configured over TCP directly to the container's active port (interval: 30s, timeout: 10s, healthy threshold: 5, unhealthy: 2). The check is performed without decrypting traffic.

02

Docker Swarm: Orchestration & Overlay Network Segmentation

Container orchestration is handled by native Docker Swarm. All services in the stack (frontend, backend, Redis, PgBouncer, and helper utilities) are isolated at the network level using dedicated overlay networks.

🚨

The Danger of a "Shared" Container Network

Using a single overlay network for all containers in a cluster negates network security: any compromised container could initiate connections to the database, cache, or internal APIs. We enforce a "strict isolation" principle.

Overlay Network Segmentation Map

Network Name (Overlay Network)	Connection Target	Services with Access
`frontend-net`	Route: NGINX ↔ Frontend	`nginx`, `frontend`
`backend-net`	Route: NGINX ↔ Backend	`nginx`, `backend`
`ws-nginx-net`	Route: NGINX ↔ WebSocket	`nginx`, `websocket`
`backend-db-net`	Route: Backend ↔ PgBouncer	`backend`, `pgbouncer`
`backend-redis-net`	Route: Backend ↔ Redis (cache/queues)	`backend`, `redis`
`ws-redis-net`	Route: WebSocket ↔ Redis (Pub/Sub)	`websocket`, `redis`
`backend-json2xml-net`	Route: Backend ↔ JSON2XML Microservice	`backend`, `json2xml`
`backend-ws-net`	Route: Backend ↔ WebSocket	`backend`, `websocket`
`pdf-nginx-net`	Route: PDF Generator ↔ NGINX	`pdf`, `nginx`
`pdf-backend-net`	Route: PDF Generator ↔ Backend	`pdf`, `backend`
`portainer-agent`	Management Loop: Portainer Agent	Portainer System Container
`(No network)`	Watcher (Cluster Monitoring)	`watcher` (only docker.sock access)

Thanks to this mapping, the network layout prevents lateral movement: even if the frontend is compromised, the attacker has no network route to the database, PgBouncer, or Redis.

03

Gentoo Linux: Hardened System & Kernel Compilation

Gentoo Linux with the hardened profile is used as the base operating system on all host servers. Excluding systemd, snapd, cloud-init, and PAM reduced the attack surface to an absolute minimum.

World updates are performed strictly via emerge with pre-validation of package hashes. We run a binpkg workflow: packages are compiled once inside a secure CI environment and then distributed to production hosts as binary packages.

Hardened Linux Kernel Configuration

The Linux kernel is built manually from the hardened-sources branch. Key security options enabled in the kernel:

Kernel Option	Status	Purpose
`CONFIG_SECURITY`	✅ Enabled	Enables the Linux Security Module (LSM) framework
`CONFIG_SECURITY_SELINUX`	✅ Enabled	Mandatory Access Control (MAC) at the OS level
`CONFIG_SECURITY_LOCKDOWN_LSM`	✅ Enabled	Locks down raw kernel memory access from the superuser
`CONFIG_SECURITY_LOADPIN`	✅ Enabled	Restricts kernel module loading to a trusted initrd filesystem
`CONFIG_STRICT_KERNEL_RWX`	✅ Enabled	Kernel memory page protection: Write XOR Execute (W^X)
`CONFIG_VMAP_STACK`	✅ Enabled	Protects against kernel stack overflows using virtually mapped stacks
`CONFIG_HARDENED_USERCOPY`	✅ Enabled	Protects against memory leaks and corruption during copies between user space and kernel space
`CONFIG_SECURITY_LANDLOCK`	✅ Enabled	Allows unprivileged userspace processes to configure secure sandbox environments
`CONFIG_FORTIFY_SOURCE`	✅ Enabled	Detects buffer overflows in various glibc functions at runtime
`CONFIG_STATIC_USERMODEHELPER`	✅ Enabled	Restricts the path of user-mode helper binaries to prevent execution redirection

Secure Compiler Flags (Toolchain-Level Hardening)

make.conf
# Compiler flags for building all system libraries and binaries
COMMON_FLAGS="-O2 -pipe -mtune=generic -fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,relro,-z,now -pie"

04

Secure CI/CD Pipeline: Code Chain of Trust

The build and deployment process is fully automated, preventing untested or vulnerable code from entering the Docker Swarm production environment.

Step 1 · Git Push

Push to Private Bitbucket

Developers push code to a secure self-hosted Bitbucket repository. The commit triggers a build webhook.

Step 2 · Bamboo CI Build

Bamboo CI & Docker Build

The Bamboo agent runs an isolated Docker build using hardened base OS templates.

Step 3 · Trivy Scanning

Trivy Vulnerability Scan

Before publication, images are scanned with Trivy. If critical vulnerabilities (CVEs) or policy violations are found, the build fails immediately.

Step 4 · Cosign Signature

Cosign Signature

Verified images are signed cryptographically using Cosign. The signing keys are stored in an external HSM/KMS.

Step 5 · Harbor & Swarm Deploy

Harbor Push & API Deployment

Signed images are pushed to a private Harbor registry. The Swarm Manager pulls the image over secure HTTPS/mTLS and deploys it to worker nodes using strict placement constraints.

05

Runtime Container Hardening (Frontend, Backend, DB, Redis)

Every container running in the Swarm cluster is configured according to the principle of least privilege:

docker-compose.yml — hardened container template
read_only: true                # Disable writes to the container root filesystem
tmpfs:
  - /tmp                      # Limit write operations to memory (tmpfs)
security_opt:
  - no-new-privileges:true     # Block process privilege escalation
cap_drop:
  - ALL                       # Drop all Linux kernel capabilities
user: "1010:1010"              # Run process as a non-root user

Hardened Component Details

Frontend (Nginx + Static UI): Nginx receives external traffic and terminates SSL/TLS at the container border. mTLS is enforced for communication between Nginx and frontend containers. The root filesystem is mounted as read-only. All HTTP security headers (HSTS, CSP, X-Frame-Options) are configured to achieve an A+ score on SSL Labs.
Backend (Laravel Octane & FrankenPHP): Upgrading from the classic php-fpm setup to a modern Laravel Octane + FrankenPHP stack eliminated the overhead of process forking. The application runs persistently in memory (built-in event loop). Performance scaled from 3.5 to 50 requests per second (a 14x increase). Traffic between Nginx and the backend is protected by strict mTLS with client certificate verification on the FrankenPHP side.
PgBouncer: A lightweight connection pooler for AWS RDS PostgreSQL. PgBouncer is isolated from public access and resides entirely within the private overlay network. Connections from the backend are encrypted using TLS 1.2 with mandatory mTLS.

pgbouncer.ini
[pgbouncer]
client_tls_sslmode = verify-full
client_tls_key_file = /run/secrets/wildcard.secure-platform.net.key
client_tls_cert_file = /run/secrets/wildcard.secure-platform.net.cert
client_tls_ca_file = /run/secrets/ca.pem
auth_type = cert
auth_file = /run/secrets/userlist.txt

Redis: Used as a cache and Pub/Sub bus for WebSockets. Accessible strictly via mTLS for the backend and WebSocket containers. Runs under UID `1010` with read-only certificate mounts.
JSON2XML: An isolated Node.js microservice. Employs a native HTTPS server with mandatory client certificate validation (mTLS). The container is fully hardened (runs as non-root, read-only FS).
WebSocket (Express.js + Socket.IO): Client connections are proxied through Nginx. Upon establishing a WebSocket connection, the server validates the user session by initiating an internal HTTPS request to the backend API over an isolated overlay network.
Watcher: A lightweight background monitoring service. It exposes no ports and accepts no network connections. Instead, it interacts directly with `docker.sock` and pushes cluster health alerts to Mattermost and ntfy.sh over HTTPS.

06

Zero Trust & Defense in Depth Model

System security is not built around a single perimeter. Instead, a multi-layered defense-in-depth model is implemented:

Layered Defense-in-Depth Implementation

Layer	Security Control	Implementation Details
Layer 1: Network	Perimeter & Encryption	External access restricted to TLS 1.2/1.3. L4 Passthrough on the NLB. Internal data exchange is secured via mutual TLS (mTLS) with strict CA certificate validation.
Layer 2: Containers	Runtime Isolation	All images are hardened (non-root, read-only FS, tmpfs, capability drops). Secrets are injected strictly via Docker Secrets (never baked into images or environment variables).
Layer 3: Code	Logic Optimization	Laravel Octane runs in memory (no process forking). Input data is strictly validated via FormRequests. Shell command execution is banned within the application code.
Layer 4: CA & Governance	Trust Verification	Private infrastructure Certificate Authority (CA) for certificate issuance. Deep certificate chain verification (verify_depth) is enabled.

07

OWASP Top 10 Security Alignment

OWASP Top 10 threat categories are mitigated at both the infrastructure and application levels:

OWASP Category	Mitigation Status	Mitigation Strategy
A01: Broken Access Control	Mitigated	Role-based access control via Laravel Policies/Middleware. Container isolation enforced via Swarm overlay networks.
A02: Cryptographic Failures	Mitigated	Encryption of sensitive data in transit (mTLS, TLS 1.3) and at rest (AWS RDS AES-256). Secrets injected at runtime via Docker Secrets.
A03: Injection	Mitigated	Enforced use of Eloquent ORM & Query Builder (parameterized queries). Automated input validation using Laravel FormRequests.
A04: Insecure Design	Mitigated	Zero Trust architectural model implemented. Minimizing privilege and entry points at the design level. Segmented access control (RBAC).
A05: Security Misconfiguration	Mitigated	Debug mode disabled. Automated rolling deployments with container health checks. A+ security headers configured at proxy level.
A06: Vulnerable and Outdated Components	Mitigated	CI/CD build pipeline integrated with Trivy container scanner (blocks on critical CVEs). Base runtime utilizes minimal hardened images.
A07: Identification and Authentication Failures	Mitigated	OAuth2 token-based authentication (Laravel Passport). Rate limiting configured at the load balancer and proxy level. Login failures monitored via centralized logs.
A08: Software and Data Integrity Failures	Mitigated	Cryptographic verification of container images via Cosign. Explicit dependency pinning in project lockfiles.
A09: Security Logging and Monitoring Failures	Mitigated	Centralized telemetry (AWS CloudWatch, Sentry). Operational alerts routed in real time via Docker Swarm Watcher.
A10: Server-Side Request Forgery (SSRF)	Mitigated	Strict outbound network isolation at the container level. Egress rules restrict traffic to allowed external APIs.