Project brief — secure, observable GitOps platform on EKS — CI/CD, GitOps, DevSecOps & Observability

The capstone project integrates every capability built across this course into a single coherent platform: a secure, fully automated GitOps delivery pipeline that takes code from a developer's commit to a production Kubernetes workload through verified security gates, cryptographic supply chain attestation, progressive canary deployment with automated rollback, and real-time observability. This platform is the reference architecture for a production-grade CI/CD system on AWS, and completing it demonstrates mastery of the entire CI/CD, GitOps, DevSecOps, and Observability stack.

The platform is built incrementally across three lab sessions: Lesson 37 completes the secure CI pipeline with SAST, SCA, Trivy scanning, and Cosign signing; Lesson 38 deploys a canary rollout via ArgoCD with automated rollback driven by Prometheus error-rate analysis; and Lesson 39 completes the observability layer with PrometheusRule alerts, Alertmanager routing, and the Grafana golden signals dashboard. Lesson 40 is the capstone submission where you deliver all three artefacts as a complete platform.

Analogy🏏Cricket

Think of it like cricket: Imagine the BCCI's team management system for an international tour with matches in three different countries simultaneously. Rather than a coordinator manually managing each match day's logistics, the system reads the official tour schedule document and automatically dispatches the right squad, equipment, and support staff to each venue. When the tour schedule changes—a match is rescheduled, a squad member is replaced—the system detects the change and updates the arrangements automatically. Just as the tour management system uses the official document as the source of truth and orchestrates multiple concurrent deployments to multiple venues, ArgoCD uses the Git repository as the source of truth and orchestrates multiple concurrent Application syncs to multiple clusters. Just as the system provides a dashboard showing which venues are 'ready', 'delayed', or 'degraded', ArgoCD provides a dashboard showing which Applications are Synced, OutOfSync, or Degraded. This reveals why ArgoCD is valued at scale: managing dozens of applications across multiple clusters manually is operationally equivalent to coordinating an international cricket tour by phone.

Platform Architecture

The capstone platform consists of four integrated layers. The CI layer—built in Lesson 37—takes a code commit through automated security gates before producing a signed container image. The delivery layer—built in Lesson 38—deploys the signed image through ArgoCD with a Kyverno admission gate that rejects unsigned images, using Argo Rollouts for progressive canary deployment with automated analysis. The cloud security layer—from Module 4—provides the AWS account guardrails: SCPs, KMS encryption, and Security Hub compliance monitoring that the platform operates within. The observability layer—completed in Lesson 39—provides real-time visibility into the platform's health and feeds the Prometheus metrics that drive Argo Rollouts' automated rollback decisions.

Analogy🏏Cricket

🏏 Think of it like cricket: The capstone platform's four layers are like the four departments that together run a professional cricket franchise, each handing off to the next. The CI layer is the talent academy: it puts every prospect (a code commit) through fitness and character screening (security gates) before issuing them an official, tamper-proof registration (a signed container image). The delivery layer is the selection-and-debut process: ArgoCD is the selector picking who takes the field, a Kyverno gate is the match official at the boundary rope turning away any player without valid registration (rejecting unsigned images), and Argo Rollouts is the graduated debut that eases a newcomer in with automated performance checks. Just as each department is useless in isolation but together forms a functioning club, each layer only becomes a secure platform through its handoffs to the others. The payoff: understanding the layer boundaries is what lets you build a pipeline where security, delivery, and safety reinforce each other rather than sit as disconnected tools.

The critical integration point that makes the platform coherent is the connection between the CI pipeline and the GitOps repository. When the CI pipeline signs an image and pushes it to ECR, it also commits the new image tag to the GitOps repository. ArgoCD detects the commit, Kyverno verifies the Cosign signature on admission, Argo Rollouts begins a canary promotion, and the Prometheus AnalysisTemplate continuously evaluates whether the canary's error rate justifies continuing promotion. This chain—from code commit to verified canary to full promotion—is the platform's core value: it automates the entire delivery lifecycle with security gates at every transition.

yaml

# Capstone platform architecture — reference diagram.

# ╔══════════════════════════════════════════════════════════════════════╗
# ║  DEVELOPER WORKFLOW                                                  ║
# ║  git push → GitHub PR → GitHub Actions CI Pipeline                  ║
# ║                                                                      ║
# ║  CI PIPELINE (M1 + M3):                                             ║
# ║  ┌──────┐  ┌──────┐  ┌─────────────────────────────────────────┐   ║
# ║  │ Lint │→ │ Test │→ │ SAST (Semgrep) + SCA (Snyk)             │   ║
# ║  └──────┘  └──────┘  └─────────────────┬───────────────────────┘   ║
# ║                                         │ both pass                  ║
# ║                       ┌─────────────────▼───────────────────────┐   ║
# ║                       │ Build → Trivy Scan → Cosign Sign → ECR  │   ║
# ║                       └─────────────────┬───────────────────────┘   ║
# ║                                         │ image digest               ║
# ╚═════════════════════════════════════════╪════════════════════════════╝
#                                           │
# ╔═════════════════════════════════════════▼════════════════════════════╗
# ║  GITOPS DEPLOYMENT (M2):                                             ║
# ║                                                                      ║
# ║  GitOps Repo ──► ArgoCD ──► EKS Cluster                             ║
# ║  (image tag commit)    ↑                                             ║
# ║                   Kyverno                                            ║
# ║               (verifyImages)   ← M3: only signed images admitted    ║
# ║                                                                      ║
# ║  Argo Rollouts:  Stable ─── 10% canary ─── 50% ─── 100%            ║
# ║                                  ↓                                   ║
# ║                    AnalysisTemplate (error-rate from Prometheus)     ║
# ║                    Auto-rollback on analysis failure                 ║
# ╚══════════════════════════════════════════════════════════════════════╝
#
# ╔══════════════════════════════════════════════════════════════════════╗
# ║  CLOUD SECURITY (M4):                                               ║
# ║  AWS IAM SCPs + Permission Boundaries + Access Analyzer             ║
# ║  KMS CMK for ECR image encryption + CloudTrail audit               ║
# ║  Security Hub (CIS Benchmark) + GuardDuty threat detection          ║
# ╚══════════════════════════════════════════════════════════════════════╝
#
# ╔══════════════════════════════════════════════════════════════════════╗
# ║  OBSERVABILITY (M5):                                                ║
# ║                                                                      ║
# ║  App → OTel Collector → Prometheus → Grafana dashboard              ║
# ║                      → Jaeger (traces)                              ║
# ║                                                                      ║
# ║  PrometheusRule alerts → Alertmanager → Slack/PagerDuty on-call     ║
# ║  Argo Rollouts AnalysisTemplate ← Prometheus error-rate metric      ║
# ╚══════════════════════════════════════════════════════════════════════╝

What You Will Build

The deliverable for the capstone is three artefacts submitted as a single GitHub repository. The first artefact is the complete GitHub Actions workflow YAML implementing the secure CI pipeline from Lesson 37. The second artefact is the ArgoCD GitOps repository containing the Argo Rollouts Rollout resource, the Kyverno ClusterPolicy for image signature verification, and the Prometheus AnalysisTemplate from Lesson 38. The third artefact is evidence of a live Grafana dashboard showing the golden signals from Lesson 39, documented with a screenshot of the dashboard with real metrics from a deployment event.

Analogy🏏Cricket

🏏 Think of it like cricket: The capstone deliverable is like submitting one complete match-preparation dossier rather than three loose folders. Just as a franchise's championship submission bundles the academy's training-and-screening programme, the on-field playbook, and the match-day monitoring plan into a single binder a reviewer can leaf through, your capstone is one GitHub repository holding three artefacts. The first is the training-and-screening programme — the GitHub Actions workflow YAML that runs the secure CI pipeline. The second is the on-field playbook — the ArgoCD GitOps repo carrying the Argo Rollouts Rollout, the Kyverno ClusterPolicy that checks every player's registration signature at the boundary, and the Prometheus AnalysisTemplate that judges performance. Just as a scattered set of folders makes a reviewer doubt the club is really coordinated, three artefacts in one repo prove the pieces actually connect. The payoff: packaging the whole platform as one coherent submission demonstrates genuine integration, not just a pile of individual tools.

The three artefacts must function together: the CI pipeline must produce images that the Kyverno policy admits; the Rollout must reference an AnalysisTemplate that queries real Prometheus metrics; and the Grafana dashboard must show metrics that include the error rate metric used by the AnalysisTemplate. A platform where each component works in isolation but the connections between them are broken does not satisfy the capstone requirement. The submission checklist in Lesson 40 verifies each integration point explicitly.

Success Criteria

The capstone platform is complete when five criteria are met simultaneously. First: a code commit to the application repository triggers the CI pipeline and produces a Cosign-signed image in ECR within 10 minutes. Second: an ArgoCD sync deploys the signed image to the squad-prod namespace, with Kyverno admitting the signed image and rejecting a manually crafted unsigned pod in the same namespace. Third: an Argo Rollouts canary promotion is active or has completed for the latest image, with the AnalysisTemplate referencing real Prometheus metrics from the running application.

Analogy🏏Cricket

🏏 Think of it like cricket: The five success criteria are like the conditions a ground must satisfy simultaneously to be certified to host an international match — not one at a time, but all at once on inspection day. Just as a venue must prove its pitch was prepared within the allowed window, that only accredited players walk out while an impostor is physically turned away at the gate, and that the floodlights and safety systems actually respond, your platform must show a commit produces a Cosign-signed image in ECR within ten minutes, that an ArgoCD sync deploys the signed image while Kyverno admits it yet rejects a hand-crafted unsigned pod in the same namespace, and that the downstream safety checks fire. Just as a ground failing any single criterion is not certified even if the others pass, the capstone is complete only when all five hold together. The payoff: simultaneous, verifiable criteria prove the platform is genuinely integrated rather than a set of parts that each happen to work in isolation.

Fourth: a PrometheusRule is deployed and evaluated by Prometheus, with at least the error rate and P99 latency alert rules appearing in the Prometheus Alerts page. Fifth: a Grafana dashboard is live showing request rate, error rate, and P99 latency for the india-squad-api service with at least 30 minutes of real metrics data.

The capstone is deliberately holistic rather than prescriptive: there is more than one correct way to connect these components, and the evaluation focuses on whether the integration works end-to-end rather than whether specific YAML lines match a reference implementation. A student who innovates—adding SBOM generation, enabling Flux CD instead of ArgoCD, or using Tempo instead of Jaeger—satisfies the criteria as long as all five integration points are functional.

How the Modules Connect

Module 1 provided the GitHub Actions workflow patterns, OIDC federation for ECR push, and Trivy scanning that form the CI pipeline's skeleton. Module 2 provided the ArgoCD deployment architecture, Argo Rollouts canary strategy, and Helm chart packaging for the application. Module 3 provided the Semgrep and Snyk security gates, the Cosign signing workflow, and the Kyverno admission policies that enforce supply chain security at runtime.

Analogy🏏Cricket

🏏 Think of it like cricket: How the modules connect is like how a cricketer's separate coaching blocks over a season combine into one complete match performance. Module 1 was the fitness-and-fundamentals block: it built the skeleton — the GitHub Actions workflow patterns, OIDC federation for pushing to ECR without stored keys, and Trivy image scanning. Module 2 was the tactics block: ArgoCD deployment architecture, the Argo Rollouts canary strategy, and Helm packaging — the playbook for taking the field. Module 3 was the discipline-and-integrity block: Semgrep and Snyk gates, Cosign signing, and Kyverno admission policies that keep the game clean. Just as no single coaching block wins a match — the player draws on fitness, tactics, and discipline together in one innings — the capstone pipeline only functions because each module's contribution slots into the others. The payoff: seeing the modules as one connected system, not isolated lessons, is what turns separate skills into a working end-to-end platform.

Module 4 provided the AWS IAM and KMS configuration that the CI pipeline operates within—OIDC roles, ECR encryption—and the Security Hub compliance monitoring that provides the account-level security context. Module 5 provided the Prometheus scraping, PromQL alerting rules, Alertmanager routing, and Grafana dashboard that complete the observability layer and feed the Argo Rollouts analysis.

The dependency order matters for implementation: the cloud security layer (Module 4) must be in place before the CI pipeline can push to ECR securely; the CI pipeline (Modules 1 and 3) must be working before ArgoCD can sync a signed image; the observability stack (Module 5) must be deployed before the Argo Rollouts AnalysisTemplate can query Prometheus metrics. Following this order minimises debugging effort by ensuring each layer's dependencies are satisfied before the next layer is built on top of them.