KubeShop is a DevSecOps portfolio project. This document explains how to report vulnerabilities and how to run/operate KubeShop safely.

Note: For a portfolio project, the “supported version” is typically the main branch and the latest tagged release.

Please report security issues responsibly.

1. Do NOT open a public GitHub issue for security problems.
2. Prefer using GitHub Security Advisories (private report).
3. If Security Advisories are not enabled, contact the maintainer privately.

Include:

• A clear description of the issue and impact
• Steps to reproduce (or a PoC)
• Affected component(s) and version/commit
• Any suggested fix/mitigation

This repository contains demo-friendly defaults that are NOT production safe.

Examples:

• k8s/secrets.yaml includes example credentials in stringData and a placeholder JWT secret.
• Some CI/container patterns (e.g., privileged Docker-in-Docker) are convenient for demos but not ideal for hardened environments.

If you use KubeShop beyond demos, apply the recommendations below.

Primary assets:

• Customer/user identity data (Identity service + Postgres)
• Order data (Order service + Postgres)
• Catalog data (Catalog service + MongoDB)
• Tokens/secrets (JWT secret, DB passwords, registry credentials)
• CI/CD credentials and cluster access (Jenkins/ArgoCD/Kubeconfig)

Primary attack surfaces:

• Public Ingress (HTTP endpoints)
• Container images and supply chain
• Kubernetes RBAC + service accounts
• CI pipeline execution environment

• Kubernetes Secret manifest: k8s/secrets.yaml
  • Contains demo credentials (postgres-password, mongo-root-password) and jwt-secret placeholder.

• Do not commit real secrets to Git.
• Prefer one of:
  • External Secrets Operator + AWS Secrets Manager / SSM Parameter Store
  • SOPS (age/KMS) encrypted secrets committed to Git
  • SealedSecrets
• Rotate all secrets if they were ever exposed.

Minimum baseline:

• Use strong random JWT secret (≥ 32 bytes)
• Separate credentials per environment (dev vs prod)
• Avoid stringData for real environments (use secure secret provisioning)

Recommended checks per service:

• Frontend/Cart (Node): npm audit / pnpm audit and lockfile pinning
• Catalog (Go): govulncheck and go mod tidy hygiene
• Identity/AI (Python): pip-audit and pinned requirements.txt
• Order (Java): OWASP Dependency-Check or mvn -DskipTests org.owasp:dependency-check-maven:check

This repo includes Trivy-related tooling:

• Trivy config: tests/security/trivy-config.yaml
• Makefile target: make security-scan

Recommended scans:

• Images: trivy image <image:tag>
• Filesystem: trivy fs .
• K8s/Docker misconfig: trivy config k8s/
• Secrets scanning: enable in Trivy scans for repo filesystem

Best practices:

• Pin image tags and prefer digests for production
• Use minimal base images (distroless/alpine where appropriate)
• Run as non-root whenever possible
• Generate and store SBOMs (CycloneDX/SPDX)
• (Optional) Sign images (cosign) and enforce verification

For each workload, aim for:

• runAsNonRoot: true
• readOnlyRootFilesystem: true
• Drop Linux capabilities (capabilities.drop: ["ALL"])
• Disallow privilege escalation (allowPrivilegeEscalation: false)
• Resource requests/limits

In a hardened cluster:

• Use least-privilege service accounts per workload
• Avoid using the default service account for application pods
• Restrict cluster-admin usage and enable audit logs

This repo does not currently ship Kubernetes NetworkPolicy manifests.

Recommended:

• Default-deny ingress/egress
• Allow only required pod-to-pod flows (frontend → APIs, APIs → DBs)

Recommended:

• Use HTTPS with a real certificate (ACM / cert-manager)
• Enforce TLS-only, HSTS, and sane request size/timeouts
• Consider AWS WAF in front of the public Load Balancer

The Jenkins pipeline (cicd/jenkins/Jenkinsfile) uses Kubernetes agents and includes a placeholder “Security Scan” stage.

Important risk:

• It uses docker:dind with privileged: true for convenience.

Recommendations:

• Prefer Kaniko/BuildKit (rootless) instead of privileged DinD
• Store credentials in Jenkins credentials store
• Use short-lived AWS credentials (OIDC / IRSA / STS) instead of long-lived keys
• Add Trivy scan step that fails the build on HIGH/CRITICAL (tune policy)

ArgoCD manifests exist under cicd/argocd/.

Recommendations:

• Use separate ArgoCD Projects per environment
• Restrict cluster destinations and namespaces
• Protect main with PR reviews and required checks
• Use image tags (immutable) instead of latest

Recommended baseline:

• Private subnets for nodes, restrict inbound to load balancers
• Enable Control Plane logs (audit, authenticator)
• Use IRSA for pods that need AWS access
• Encrypt EBS volumes (default) and (optionally) KMS for secrets
• Restrict security groups and IAM policies
• Use least-privilege ECR permissions

Recommended:

• Centralize logs (e.g., Loki/CloudWatch)
• Alert on:
  • Elevated 4xx/5xx
  • Latency spikes (p95/p99)
  • CrashLoopBackOff and restart storms
  • Suspicious auth patterns (rate limit/lockout signals)