DevSecOps & Container Security Labs

Objective: Create a dedicated namespace to isolate tenant resources from other workloads in the cluster.

Command:
kubectl create namespace tenant-alpha

What this does: Creates a virtual cluster boundary that isolates resources, applies network policies, and enables granular RBAC controls specific to tenant-alpha.
💡 Tip: Namespaces are the foundation of multi-tenancy in Kubernetes, providing logical isolation between different customers or applications.

Objective: Apply Kubernetes Pod Security Standards to enforce strict security policies on all pods in the namespace.

Command:
kubectl label namespace tenant-alpha pod-security.kubernetes.io/enforce=restricted

What this does: Enforces the "restricted" Pod Security Standard, which prevents privileged containers, requires non-root users, drops dangerous capabilities, and enforces read-only root filesystems.
💡 Tip: The restricted policy is the most secure tier and aligns with hardening best practices from CIS Kubernetes Benchmark.

Objective: Create default-deny network policy to block all ingress/egress traffic, then selectively allow required connections.

Command:
kubectl create -f deny-all-policy.yaml

What this does: Implements a zero-trust network model where all traffic is blocked by default. You must explicitly allow specific ingress/egress rules for legitimate communication.
💡 Tip: Start with deny-all, then whitelist only required connections. This prevents lateral movement in case of pod compromise.

Objective: Create a dedicated service account with minimal permissions following the principle of least privilege.

Command:
kubectl create serviceaccount app-sa -n tenant-alpha

What this does: Creates a unique identity for your application pods that can be bound to specific RBAC roles. Never use the default service account for applications.
💡 Tip: Service accounts enable fine-grained access control. Grant only the API permissions your app actually needs (e.g., list pods, but not delete).

Objective: Create Kubernetes secrets for sensitive data like database passwords, ensuring they are encrypted at rest.

Command:
kubectl create secret generic app-secret --from-literal=db_password=secure123 -n tenant-alpha

What this does: Stores sensitive configuration data in a Secret object. When mounted in pods, secrets are stored in tmpfs (memory-only) and never written to disk.
💡 Tip: Enable encryption at rest by configuring EncryptionConfiguration in kube-apiserver to encrypt secrets using AES-CBC or KMS.

Objective: Configure Kubernetes audit logging to track all API requests for security monitoring and compliance.

Command:
kubectl apply -f audit-policy.yaml

What this does: Enables comprehensive logging of all API server requests including who made the request, what resources were accessed, and what actions were taken. Critical for forensics and compliance (PCI-DSS, SOC2).
💡 Tip: Configure audit rules to capture metadata, request/response bodies for sensitive resources, and set appropriate retention policies.

Objective: Enable Docker Content Trust to ensure only cryptographically signed images can be pulled and run.

Command:
export DOCKER_CONTENT_TRUST=1

What this does: Activates image signature verification using The Update Framework (TUF). Docker will refuse to pull or run unsigned images, preventing supply chain attacks and image tampering.
💡 Tip: DCT uses Notary for signing. When pushing images, Docker automatically generates signing keys and pushes signatures to the registry. This prevents man-in-the-middle attacks and ensures image provenance.

Objective: Create a minimal, security-hardened base image following container best practices.

Command:
docker build -t secure-base:latest -f Dockerfile.secure .

What this does: Builds a container image with security hardening: uses Alpine Linux (minimal attack surface), removes shell and package managers, creates non-root user, sets read-only filesystem, and drops all Linux capabilities except what's required.
💡 Tip: Best practices - use distroless or scratch images, run as UID > 10000, use COPY instead of ADD, set USER directive, avoid latest tags, and implement multi-stage builds to exclude build dependencies.

Objective: Use Trivy (open-source vulnerability scanner) to detect CVEs in OS packages, application dependencies, and misconfigurations.

Command:
docker run aquasec/trivy image secure-base:latest

What this does: Scans all layers of the container image against vulnerability databases (NVD, Red Hat, Debian, Alpine, etc.). Reports CVEs with severity ratings (CRITICAL, HIGH, MEDIUM, LOW) and provides remediation guidance.
💡 Tip: Integrate Trivy into CI/CD pipelines and fail builds on CRITICAL/HIGH vulnerabilities. Scan regularly as new CVEs are discovered daily. Also scan for secrets (API keys, passwords) accidentally committed.

Objective: Set up Harbor - an enterprise-grade container registry with built-in security scanning, RBAC, and replication.

Command:
docker run -d -p 443:443 --name harbor goharbor/harbor:latest

What this does: Deploys Harbor registry with integrated Trivy scanning, image signing enforcement, vulnerability policy gates, RBAC for multi-tenancy, and audit logging. Supports Docker Content Trust and Notary out of the box.
💡 Tip: Configure Harbor to automatically scan images on push, create severity-based policies (block CRITICAL CVEs), enable image retention policies, and set up replication for disaster recovery.

Objective: Run containers with AppArmor/SELinux MAC (Mandatory Access Control) and drop all Linux capabilities.

Command:
docker run --security-opt apparmor=docker-default --cap-drop=ALL secure-base

What this does: Applies AppArmor profile to restrict syscalls and file access. Drops all 38 Linux capabilities (CAP_CHOWN, CAP_NET_RAW, etc.) preventing privilege escalation. Container cannot perform privileged operations even if compromised.
💡 Tip: Start with --cap-drop=ALL, then add back only required capabilities (e.g., CAP_NET_BIND_SERVICE for ports <1024). Combine with --read-only, --security-opt=no-new-privileges, and user namespaces for defense-in-depth.

Objective: Deploy Falco for runtime threat detection - monitors syscalls to detect anomalous behavior in real-time.

Command:
docker run -d --privileged -v /var/run/docker.sock:/host/var/run/docker.sock falcosecurity/falco:latest

What this does: Installs kernel module to intercept syscalls. Detects threats like: shell spawned in container, sensitive file access, privilege escalation attempts, unexpected network connections, crypto mining, and reverse shells.
💡 Tip: Customize Falco rules for your environment. Integrate with SIEM for alerting. Falco catches zero-day exploits and post-exploitation activity that static scanning misses.

Objective: Add a security stage to the pipeline so security scans run before deployment.

How to do it:
1. In the YAML editor, find the stages: section (lines 1-4)
2. Add - security on a new line BETWEEN - test and - deploy

Your stages should look like this:

stages:
  - build
  - test
  - security
  - deploy

Then run this command to validate:
gitlab-ci validate

💡 Tip: The security stage must come BEFORE deploy so vulnerabilities block deployment.

Objective: Add Static Application Security Testing to scan source code for vulnerabilities.

How to do it:
1. In the YAML editor, add a new include: section AFTER the stages block (after line 5)
2. Add the SAST template as shown below

Add this code after the stages section:

include:
  - template: Security/SAST.gitlab-ci.yml

Then run this command:
gitlab-ci sast enable

💡 Tip: SAST scans your source code for SQL injection, XSS, hardcoded secrets, etc.

Objective: Scan third-party dependencies for known CVEs.

How to do it:
1. In the YAML editor, find the include: section you created in Step 2
2. Add another template line UNDER the SAST template

Your include section should now look like:

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml

Then run this command:
gitlab-ci dependency-scan enable

💡 Tip: This scans package.json, requirements.txt, etc. for vulnerable packages like Log4Shell.

Objective: Add Dynamic Application Security Testing to test the running app.

How to do it:
1. In the YAML editor, find the include: section
2. Add the DAST template as a third line

Your include section should now look like:

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/DAST.gitlab-ci.yml

Then run this command:
gitlab-ci dast configure --target=https://staging.app.com

💡 Tip: DAST tests your live app like a hacker would - finding XSS, SQL injection, etc.

Objective: Replace hardcoded secrets and environment variables with dynamic secrets from HashiCorp Vault.

Command:
gitlab-ci vault configure --url=https://vault.internal --role=ci-cd

What this does: Configures GitLab Runner to authenticate with Vault using JWT tokens. Pipeline jobs fetch secrets at runtime (DB passwords, API keys) instead of storing them in variables. Vault generates temporary credentials that auto-expire after the job completes.
💡 Tip: Vault provides credential rotation, audit logging, and fine-grained access control. Never commit secrets to git or store them in CI/CD variables. Use Vault's dynamic database credentials for zero-trust architecture.

Objective: Create automated policy gates that fail the pipeline if security thresholds are violated.

Command:
gitlab-ci security-gate create --critical=0 --high=3

What this does: Implements policy-as-code: if SAST/DAST/dependency scans find any CRITICAL vulnerabilities or more than 3 HIGH-severity issues, pipeline automatically fails and blocks deployment. Enforces "shift-left" security - catch issues early before they reach production.
💡 Tip: Set realistic thresholds that balance security and velocity. Too strict = constant build failures. Too loose = vulnerabilities slip through. Start with critical=0, high=5, then tighten over time.