Container Security and DevSecOps Platform

An independently designed and implemented container-security and DevSecOps project demonstrating how security controls can be applied across the complete lifecycle of a containerised application—from source code and image construction to Kubernetes admission, network isolation, deployment, and operational validation.

Project scope: This is a practical, non-production security engineering environment intended to demonstrate defence-in-depth techniques and secure delivery patterns.

Overview

The project transforms a PHP and MariaDB application into a hardened, containerised platform supported by an automated DevSecOps pipeline and a GitOps deployment model. Rather than treating container security as a single image-scanning activity, the implementation applies controls at multiple layers:

• Source code and secret exposure
• Software dependencies and known vulnerabilities
• Dockerfiles and Kubernetes manifests
• Container images
• Container privileges and Linux capabilities
• Kubernetes admission control
• Pod-to-pod and external network traffic
• Deployment consistency and configuration drift

The result is a reproducible environment in which insecure configurations can be detected before deployment and non-compliant workloads can be audited or blocked at the Kubernetes API boundary.

Project Objectives

The project was developed to explore how a conventional containerised application can be strengthened through practical security engineering. Its principal objectives were to:

• Harden the web and database containers using least-privilege principles.
• Reduce the attack surface of container processes and runtime environments.
• detect exposed secrets, vulnerable dependencies, insecure images, and infrastructure misconfigurations through automated checks.
• Apply policy-as-code controls before workloads are admitted to Kubernetes.
• Restrict network communication through default-deny policies and explicit traffic rules.
• Establish Git as the source of truth for deployment configuration.
• Automate environment setup, validation, status reporting, and teardown.
• Document known limitations and identify a realistic path towards a more production-ready design.

Architecture

The application consists of two principal workloads deployed into a dedicated Kubernetes namespace:

• An Nginx and PHP-FPM web application exposed through a Kubernetes service.
• A MariaDB database accessible only through the required application path.

Both workloads use explicit security contexts, non-root identities, dropped Linux capabilities, health probes, resource controls, and restricted service-account behaviour. Kubernetes NetworkPolicy resources provide default-deny isolation and then permit only the traffic needed for web access, database communication, and DNS resolution.

Argo CD continuously reconciles Kubernetes manifests from Git, while Kyverno evaluates workloads during admission. This creates a controlled delivery path in which configuration changes are versioned, policy-checked, and automatically reconciled with the cluster.

Defence-in-Depth Controls

Secure container construction

The web and database images were redesigned to reduce unnecessary privilege and improve operational security. The implementation includes:

• Non-root container execution
• Removal of unnecessary Linux capabilities
• no-new-privileges controls
• Restricted filesystem and volume access
• Resource limits and health checks
• Hardened Nginx, PHP-FPM, PHP, and MariaDB configuration
• Custom seccomp profiles for the Docker Compose environment
• Persistent database storage separated from ephemeral containers

Automated security scanning

GitHub Actions coordinates a staged security and delivery workflow. The security stage includes:

• TruffleHog for secret detection
• Trivy filesystem scanning for vulnerable source dependencies
• Checkov for Dockerfile and Kubernetes misconfiguration analysis
• Trivy image scanning for vulnerabilities in the web and database images
• SARIF reporting for findings presented through GitHub code scanning

The build and deployment workflow is chained after the security workflow, creating a defined security checkpoint before later delivery activity.

Kubernetes admission control

Kyverno provides policy-as-code controls at the Kubernetes admission layer. Policies verify that workloads:

• Use the intended namespace rather than default
• Run as non-root users
• Define pod-level and container-level security contexts
• Drop all Linux capabilities
• Disable automatic service-account-token mounting where it is unnecessary
• Configure liveness and readiness probes

The project uses an audit-to-enforce workflow: policies can first identify violations without disrupting workloads and can then be moved into enforcement mode once compliance has been verified.

Network isolation

Kubernetes network policies use a default-deny model and add only the required communication paths:

• External HTTP traffic to the web application
• Web application traffic to MariaDB on port 3306
• Database ingress only from the authorised web workload
• DNS egress on TCP and UDP port 53

This limits lateral movement and prevents unrestricted communication between workloads.

GitOps delivery

Argo CD monitors the Kubernetes manifest directory and reconciles the cluster against the version-controlled desired state. The workflow provides:

• Git-based change history and reviewability
• Automated synchronisation of approved configuration
• Detection and correction of configuration drift
• A consistent deployment path through admission controls
• Separation between declarative configuration and runtime state

Once GitOps management is active, deployment changes are made through Git rather than direct, untracked modification of cluster resources.

Key Contributions

I independently designed and implemented the project across the application, container, pipeline, Kubernetes, policy, automation, and documentation layers. This included:

• Containerising and hardening the PHP, Nginx, and MariaDB application stack.
• Creating Docker Compose configuration for local development and security validation.
• Developing custom container configuration and seccomp profiles.
• Building GitHub Actions workflows for secret, dependency, infrastructure-as-code, and image scanning.
• Producing hardened Kubernetes deployments, services, persistent storage, secrets integration, and health checks.
• Defining Kyverno admission policies for workload security requirements.
• Designing default-deny Kubernetes network policies with explicit application traffic paths.
• Integrating Argo CD to implement automated GitOps reconciliation and self-healing.
• Writing integration tests and operational validation procedures.
• Creating idempotent setup and teardown scripts with prerequisite checks, readiness waits, status reporting, and safeguards for destructive actions.
• Documenting architecture, operating procedures, troubleshooting guidance, security decisions, limitations, and future improvements.

Automation and Reproducibility

The environment is managed through dedicated setup and teardown scripts rather than a collection of undocumented manual commands. The automation supports:

• Minikube provisioning and validation
• Ordered deployment of Kubernetes resources
• Kyverno installation and policy application
• Controlled transition from audit to enforcement
• Argo CD installation and application creation
• Consolidated component and application status checks
• Selective or complete environment teardown

The scripts are designed to be repeatable, fail clearly when prerequisites are absent, wait for workloads to become ready, and require confirmation before destructive operations.

Security Validation

The project includes tests and operational checks that compare the hardened implementation with the original application configuration. Validation covers areas such as:

• Container health checks
• Logging behaviour
• Resource restrictions
• Image vulnerability findings
• Seccomp and no-new-privileges controls
• Linux capability removal
• Privileged-container settings
• Filesystem and volume restrictions
• Persistent application data
• Kubernetes policy compliance
• Admission-control enforcement
• Network access restrictions
• Argo CD synchronisation and self-healing

These checks help demonstrate that the controls are active and observable rather than existing only as configuration declarations.

Outcome

The project demonstrates a complete secure-delivery path for a containerised application: code and configuration are scanned, images are assessed, Kubernetes manifests are policy-checked, network access is restricted, and the deployed state is reconciled continuously from Git.

It also demonstrates an important security engineering principle: effective container security depends on coordinated controls across build-time, deployment-time, and runtime configuration, not on a single tool or isolated vulnerability scan.

Current Limitations and Future Work

The environment is intentionally designed as a local practical implementation rather than a production platform. Identified future improvements include:

• Replacing manually created Kubernetes secrets with Sealed Secrets or an External Secrets Operator.
• Publishing images to a managed registry such as GitHub Container Registry.
• Replacing fixed manifest values with Helm or Kustomize configuration for multiple environments.
• Adding runtime threat detection through Falco.
• Introducing stronger network visibility and Layer 7 controls through Cilium and Hubble.
• Generating and retaining software bills of materials for supply-chain assurance.
• Adding image signing and admission verification.
• Expanding the deployment model beyond local Minikube environments.
• Replacing local-only image handling with a complete registry-backed GitOps workflow.

Repository

The complete implementation, documentation, automation, manifests, policies, tests, and pipeline definitions are available on GitHub:

View the container-security repository

Technologies / Concepts

Container Security · Docker · Docker Compose · Kubernetes · Minikube · GitHub Actions · DevSecOps · GitOps · Argo CD · Kyverno · Trivy · TruffleHog · Checkov · SARIF · NetworkPolicy · Seccomp · Linux Capabilities · Nginx · PHP-FPM · MariaDB · Bash · Policy as Code · Infrastructure as Code