1. Zero Trust Architecture: Isolation as the Foundation

The production infrastructure is built on the zero trust model: no component is trusted by default. All servers reside in an isolated network segment using private IPv4 addresses (e.g., 10.x.x.x or 192.168.x.x). Direct internet access to databases, microservices, or internal APIs is physically impossible.

This isn’t just a “restriction”—it’s an architectural requirement that enables:

  • Reducing the attack surface to a single, hardened entry point.
  • Eliminating risks of direct scanning or exploitation of service vulnerabilities.
  • Simplifying audits and ensuring compliance with regulatory standards (PCI DSS, GDPR).

2. Defense in Depth: Two Frontline Layers

All incoming traffic passes through a two-layer defense system, implemented using the principle of defense in depth:

  1. FortiGate WAF (Web Application Firewall)
    A hardware gateway at the network edge provides L3–L7 filtering:

    • Blocks DDoS attacks and vulnerability scanners.
    • Signature- and behavior-based protection against SQLi, XSS, and RCE.
    • Integrates with threat intelligence feeds for up-to-date signatures.

  2. Nginx as a policy enforcement point
    Behind the WAF sits Nginx, configured as a strict reverse proxy:

    • Whitelists allowed HTTP methods, paths, and headers.
    • Validates User-Agent and Origin headers.
    • Rate-limits requests and blocks fuzzing attempts.
    • Maintains detailed logs of all traffic (for SIEM and forensic analysis).

This layered approach ensures that even if an attacker bypasses the WAF (e.g., via a zero-day), they immediately face strict application-layer policies and cannot reach business logic directly.

3. Microservices and Network Discipline

The application architecture follows the 12-Factor App methodology, especially regarding isolation and configuration. Critically:

  • Internal microservices expose no public ports. Communication happens exclusively within trusted networks:
    • In Kubernetes — via Pod-to-Pod traffic with NetworkPolicy.
    • In Docker Swarm or Compose — through overlay networks with strict egress/ingress rules.
  • Public-facing services never handle sensitive data over open channels. Even when called over TLS, raw sensitive data is never transmitted in plaintext.

This eliminates the risk of an internal service accidentally becoming public due to a load balancer or DNS misconfiguration.

4. Data Protection “In Transit” and “At Rest”

Data is the core asset. Therefore:

  • All PII, tokens, and financial identifiers in PostgreSQL are encrypted at the application layer.
  • Administration tools (pgAdmin, DBeaver) cannot retrieve decrypted values—even with valid database credentials.
  • Decryption occurs only within the context of an authorized request inside a trusted service.

This isn’t an “extra measure”—it’s the foundation of compliance. Even in the event of a database credential leak or data dump, the information remains useless to attackers.

5. CI/CD as a Quality and Security Gate

Every change flows through a three-stage pipeline that serves as both a quality and audit mechanism:

Stage Purpose Automation
Dev Stage Initial feature testing by developers Unit tests, linting, image builds
QA Stage Smoke tests, regression, UX validation Integration tests, UI tests, security scans (Trivy/Snyk)
Pre-Prod / Prod Final acceptance or progressive rollout Blue/Green (bare metal) or Canary (K8s + Istio)
  • Pre-Prod is used in traditional infrastructure setups. Final manual sign-off occurs here, and traffic can be selectively routed (e.g., to the product team).
  • Canary deployments in Kubernetes are used in cloud-native environments: 5% of traffic goes to the new version, 95% to stable. Automated monitoring of errors, latency, and resource usage triggers rollbacks if needed.

Critical: no stage is skipped. A production release is blocked unless all tests pass and artifacts are signed and verified by CI.

Conclusion: Control Is a Design Choice—Not a Reaction

This model demonstrates that “full production control” is neither a myth nor an ops-team demand—it’s the result of:

  • Architectural discipline (isolation, 12-Factor principles, zero trust),
  • Engineering automation (CI/CD as a delivery and verification mechanism),
  • A security-first culture (data encryption, layered defense).

Together, these practices ensure not only compliance but also predictability, reproducibility, and resilience—the hallmarks of a mature production environment.

“Reliability isn’t something you add at the end. It’s something you design from the very beginning.”
— Adapted from the Google SRE Workbook

Architecture Diagram

Below is a schematic illustrating the described structure:

+---------------------+
|     Internet        |
+----------+----------+
           |
           v
+----------+----------+
|   FortiGate WAF     | ← L3–L7 protection (DDoS, SQLi, XSS)
+----------+----------+
           |
           v
+----------+----------+
|      Nginx Proxy    | ← Path whitelisting, header filtering
+----------+----------+
           |
           v
+----------+----------+
|   Public-Facing     |
|   Microservices     | ← External APIs only, no sensitive data
+----------+----------+
           |
   +-------+-------+
   |               |
   v               v
+--+--+        +---+---+
| K8s |        | Docker| ← Internal-only services
| Net |        | Net   |    (Pod-to-Pod / Overlay)
+--+--+        +---+---+
   |               |
   v               v
+--+--------------+--+
| PostgreSQL (application-layer encryption) |
| Redis, Consul, etcd                      |
+--------------------+
      (isolated network, no external access)
← Back to Portfolio