🛡️ Production-Grade DevOps & GitOps Microservices Platform

A production-grade 9-service microservices platform combining Kubernetes, GitOps, DevSecOps, progressive delivery, software supply-chain security, runtime protection, and full-stack observability.

Microservices · Kubernetes · GitOps · Kargo Promotion · DevSecOps · Progressive Delivery · Supply-Chain Security · Runtime Security · Observability

📖 Overview

This project is a production-grade DevOps & GitOps microservices platform built around a realistic 9-service digital banking architecture.

It demonstrates both sides of modern platform engineering:

Microservices architecture — independently deployable services, service-owned databases, API gateway routing, asynchronous messaging, distributed transactions, fault isolation, and service-level resilience.
Production delivery platform — Kubernetes, GitOps, CI security gates, signed artifacts, admission policies, progressive delivery, observability, runtime security, TLS, secrets management, and automated rollback.

The platform is not a single application wrapped in Kubernetes. It is a distributed system composed of multiple independently deployable workloads with different runtimes, data ownership boundaries, dependencies, and release strategies.

The core operating rule is:

Git is the source of truth. Production is changed through reconciliation, not by manually applying manifests.

The platform implements:

9 independently deployable microservices
service-owned PostgreSQL databases
YARP API gateway routing
RabbitMQ-based asynchronous messaging
Redis-backed distributed platform components
cross-service transaction saga with compensation
service-level fault isolation and resilience
automated container build and promotion
immutable commit-SHA releases
declarative GitOps deployment
Argo CD app-of-apps
Kargo continuous-promotion control plane
Warehouse → Freight → Stage promotion model
ordered sync waves
canary and blue-green delivery
automated health and metrics gates
container vulnerability scanning
SPDX SBOM generation
keyless image signing -Rekor transparency logging
Kyverno admission enforcement
Falco runtime threat detection
Prometheus metrics and alerting
Loki log aggregation with Grafana Alloy
Grafana dashboards
HashiCorp Vault secret management
automated TLS with cert-manager and Let's Encrypt
operational rollback and recovery runbooks

🧩 Microservices Architecture

The application layer consists of 9 independently deployable services behind a gateway.

                         ┌──────────────────────────┐
                         │        Frontend          │
                         │      Angular + nginx     │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                         ┌──────────────────────────┐
                         │       API Gateway        │
                         │          YARP            │
                         └────────────┬─────────────┘
                                      │
          ┌───────────────┬───────────┼───────────┬───────────────┐
          │               │           │           │               │
          ▼               ▼           ▼           ▼               ▼
     Identity         Account    Transaction   Payment         Lending
          │               │           │           │               │
          └───────────────┴──────┬────┴───────────┴───────────────┘
                                 │
                         ┌───────┴────────┐
                         ▼                ▼
                     Platform           Fraud
                                      FastAPI

                         + Gateway + Frontend
                         = 9 deployable services

Service boundaries

Service	Responsibility	Runtime
Identity	authentication, sessions, devices, recovery	ASP.NET Core 8
Account	account state and balances	ASP.NET Core 8
Transaction	ledger, transfers, reconciliation, distributed transaction workflow	ASP.NET Core 8
Payment	payment workflows and merchant-facing operations	ASP.NET Core 8
Lending	lending workflows and repayment schedules	ASP.NET Core 8
Platform	shared operational capabilities, audit and platform state	ASP.NET Core 8
Fraud	risk scoring and fraud analysis	Python · FastAPI
Gateway	API routing and edge service composition	YARP · ASP.NET Core
Frontend	browser application and `/api` proxy	Angular · nginx

Data ownership

Each backend service owns its own data boundary.

Identity      ──► identitydb
Account       ──► accountdb
Transaction   ──► transactiondb
Payment       ──► paymentdb
Lending       ──► lendingdb
Platform      ──► platformdb

The services do not read each other's tables directly. Cross-service interaction happens through APIs and messaging.

This matters operationally because each service can be:

deployed independently
rolled back independently
monitored independently
scaled independently
isolated when unhealthy
released with a strategy appropriate to its risk

Distributed transaction handling

Money movement crosses service boundaries, so transfers use a saga with compensation rather than pretending a single database transaction can cover the whole system.

Debit Account
     │
     ├── FAIL ──► transaction fails, nothing moved
     │
     ▼
Credit Account
     │
     ├── FAIL ──► compensate by refunding debit
     │
     ▼
Complete Transaction

A background reconciler handles operations left mid-flight and helps detect stranded transaction state.

Idempotency

Critical operations use idempotency protection at the database level so duplicate requests cannot race and both succeed.

Messaging and infrastructure

The platform also includes:

RabbitMQ for asynchronous service communication
Redis for distributed platform state and supporting workloads
HashiCorp Vault for sensitive key material and application secrets
Azure Database for PostgreSQL as the external database layer

Why microservices here?

The architecture deliberately accepts the operational complexity of microservices because the platform is designed around fault isolation and independent recovery.

A failure in one service should not require redeploying the whole banking platform.

That same separation carries into delivery:

One service changes
      │
      ▼
Build only the required artifact
      │
      ▼
Scan + sign
      │
      ▼
Update GitOps state
      │
      ▼
Argo CD detects change
      │
      ▼
Only that workload rolls out

This is where the microservices architecture and the GitOps platform reinforce each other: small deployment units, isolated blast radius, independent rollback, and service-level observability.

🔁 End-to-End Delivery Flow

Developer Push
      │
      ▼
GitHub Actions
      │
      ├── Test / validate
      ├── Build container images
      ├── Trivy vulnerability gate
      ├── Syft SPDX SBOM
      ├── Push immutable SHA-tagged images
      └── Cosign keyless signing + Rekor
      │
      ▼
Kargo Promotion Layer
      │
      ├── Warehouse discovers deployable artifacts
      ├── Freight represents an immutable release candidate
      ├── Production Stage records promotion state/history
      └── Promotion updates desired image tag in Git
      │
      ▼
Argo CD
      │
      ├── Detect desired-state change
      ├── Reconcile cluster
      └── Restore drift automatically
      │
      ▼
Kyverno Admission
      │
      └── Verify image identity + signature + digest
      │
      ▼
Argo Rollouts
      │
      ├── Canary or Blue-Green
      ├── Health analysis
      ├── Prometheus metric analysis
      └── Promote / Abort / Rollback
      │
      ▼
Production Workloads
      │
      ├── Prometheus / Alertmanager
      ├── Loki / Grafana Alloy
      ├── Grafana
      └── Falco / Falcosidekick

🏗️ DevOps & Microservices Platform Architecture

flowchart TB
    DEV["Developer<br/>git push"]

    subgraph CI["CI / Software Supply Chain"]
        TEST["Tests & validation"]
        BUILD["Build images<br/>commit-SHA tags"]
        TRIVY["Trivy<br/>HIGH / CRITICAL gate"]
        SBOM["Syft<br/>SPDX SBOM"]
        REG["Docker Hub"]
        SIGN["Cosign keyless signing<br/>GitHub OIDC + Rekor"]

        TEST --> BUILD --> TRIVY --> SBOM --> REG --> SIGN
    end

    subgraph GITOPS["GitOps & Promotion"]
        WAREHOUSE["Kargo Warehouse<br/>artifact discovery"]
        FREIGHT["Kargo Freight<br/>immutable release candidate"]
        STAGE["Kargo Stage<br/>production promotion"]
        VALUES["Production image tags"]
        ROOT["Root Application"]
        APPS["Argo CD Applications"]

        WAREHOUSE --> FREIGHT --> STAGE --> VALUES
        ROOT --> APPS
    end

    subgraph CLOUD["Microsoft Azure"]
        subgraph K3S["k3s Cluster"]
            ARGO["Argo CD"]
            KYVERNO["Kyverno"]
            ROLLOUTS["Argo Rollouts"]

            subgraph SERVICES["AEGIS Workloads"]
                APPSVC["9 application services"]
                VAULT["Vault"]
                RMQ["RabbitMQ"]
                REDIS["Redis"]
            end

            subgraph OBS["Observability"]
                PROM["Prometheus"]
                ALERT["Alertmanager"]
                GRAF["Grafana"]
                LOKI["Loki"]
                ALLOY["Grafana Alloy"]
            end

            subgraph RUNTIME["Runtime Security"]
                FALCO["Falco<br/>modern eBPF"]
                SIDEKICK["Falcosidekick + UI"]
            end

            TRAEFIK["Traefik"]
            CERT["cert-manager<br/>Let's Encrypt"]
        end

        PG["Azure Database<br/>for PostgreSQL"]
    end

    DEV --> TEST
    SIGN --> WAREHOUSE
    STAGE --> VALUES
    VALUES --> ARGO
    ROOT --> ARGO
    ARGO --> KYVERNO
    ARGO --> ROLLOUTS
    ROLLOUTS --> APPSVC
    KYVERNO --> APPSVC
    APPSVC --> PG
    APPSVC --> VAULT
    APPSVC --> RMQ
    APPSVC --> REDIS
    PROM --> GRAF
    LOKI --> GRAF
    ALLOY --> LOKI
    PROM --> ALERT
    FALCO --> SIDEKICK
    TRAEFIK --> APPSVC
    CERT --> TRAEFIK

🧰 Technology Stack

Layer	Technology
Application Architecture	9-service microservices platform
Backend Runtime	ASP.NET Core 8
Fraud Runtime	Python 3.11 · FastAPI
Frontend	Angular · nginx
API Gateway	YARP
Messaging	RabbitMQ · MassTransit
Caching / Distributed State	Redis
Cloud	Microsoft Azure
Kubernetes	k3s
GitOps	Argo CD
Continuous Promotion	Kargo 1.11 — Project · Warehouse · Freight · Stage
Progressive Delivery	Argo Rollouts
CI	GitHub Actions
Container Registry	Docker Hub
Image Scanning	Trivy
SBOM	Syft — SPDX JSON
Image Signing	Sigstore Cosign — keyless OIDC
Transparency Log	Rekor
Admission Policy	Kyverno
Runtime Security	Falco — modern eBPF
Security Events	Falcosidekick + UI
Metrics	Prometheus
Alerting	Alertmanager
Cluster Metrics	kube-state-metrics · node-exporter
Logs	Loki
Log Collection	Grafana Alloy
Dashboards	Grafana
Secrets	HashiCorp Vault
Ingress	Traefik
TLS	cert-manager + Let's Encrypt
Packaging	Helm
Database	Azure Database for PostgreSQL

🔀 Repository Separation

The delivery design separates application source and CI from cluster desired state.

Application / CI Repository
        │
        │ successful build only
        ▼
GitOps Repository
        │
        │ read-only reconciliation
        ▼
Argo CD
        │
        ▼
Kubernetes

This separation is deliberate.

CI is allowed to update only the deployment state required for promotion. The cluster only needs read access to the repository that describes it.

Two narrowly scoped deploy keys are used:

Key	Held by	Access
`argocd-cluster-readonly`	Argo CD / cluster	Read-only
`aegis-ci-promote`	CI	Read/write for promotion

A broad personal access token is intentionally avoided. The principle is:

One identity, one direction, one purpose.

🗺️ GitOps Repository Layout

.
├── bootstrap/
│   └── root-app.yaml
│
├── apps/
│   ├── cert-manager.yaml
│   ├── admission.yaml
│   ├── base.yaml
│   ├── infrastructure.yaml
│   ├── runtime-security.yaml
│   ├── observability.yaml
│   ├── logs.yaml
│   ├── promotion.yaml
│   ├── identity.yaml
│   ├── account.yaml
│   ├── transaction.yaml
│   ├── payment.yaml
│   ├── lending.yaml
│   ├── platform.yaml
│   ├── fraud.yaml
│   ├── gateway.yaml
│   └── frontend.yaml
│
├── manifests/
│   ├── namespace.yaml
│   ├── ingress.yaml
│   ├── redirect-middleware.yaml
│   ├── analysis-template.yaml
│   ├── promotion/
│   │   ├── project.yaml
│   │   ├── warehouse.yaml
│   │   └── stage-production.yaml
│   ├── admission/
│   ├── certs/
│   ├── infrastructure/
│   ├── observability/
│   ├── falco/
│   ├── argocd/
│   └── services/
│
├── charts/
│   └── aegis-service/
│
├── environments/
│   ├── base/
│   └── production/
│       └── values.yaml
│
└── scripts/

The service chart replaces repeated deployment manifests with a reusable deployment pattern, while environment-specific values keep image tags and configuration declarative.

🏷️ Immutable Releases

AEGIS deploys images using commit-derived SHA tags.

Example:

aegis-identity:sha-<commit>
aegis-account:sha-<commit>
aegis-transaction:sha-<commit>
aegis-payment:sha-<commit>
aegis-lending:sha-<commit>
aegis-platform:sha-<commit>
aegis-fraud:sha-<commit>
aegis-gateway:sha-<commit>
aegis-frontend:sha-<commit>

latest is not used as a production deployment reference.

Why:

a SHA tag identifies exactly which source revision produced the image
Git detects an actual desired-state change
rollbacks target a known artifact
a running Pod can be traced back to a commit
mutable tags cannot silently change the software behind an unchanged manifest

Before promotion, CI verifies that all expected service images actually exist. This prevents a GitOps update from referencing a commit for which no deployable container image was produced.

⚙️ CI & Software Supply Chain

The supply chain follows a fail-fast model: artifacts must pass required checks before becoming deployable.

🔍 Vulnerability scanning

Trivy scans built images for:

HIGH
CRITICAL

The pipeline uses a blocking exit code so failed security gates stop the release.

📋 SBOM

Syft generates an SPDX JSON Software Bill of Materials for container images.

The SBOM is associated with the image so software-component evidence is not limited to temporary CI logs.

✍️ Keyless signing

Images are signed using Sigstore Cosign keyless signing.

GitHub Actions
      │
      ├── GitHub OIDC identity
      ▼
Sigstore Fulcio
      │
      ├── short-lived certificate
      ▼
Cosign signature
      │
      ├── stored with the image
      ▼
Rekor transparency log

There is no long-lived private signing key stored in CI.

This reduces:

signing-key theft risk
manual signing-key rotation
hidden signing events
CI secret sprawl

The security question is not simply:

“Is this image signed?”

It is:

“Was this image signed by the expected CI identity for the expected repository and workflow?”

🛡️ Admission Control with Kyverno

Argo CD answers:

Does the cluster match Git?

Kyverno adds another question:

Can the artifact named by Git be trusted?

The verify-aegis-images policy runs in Enforce mode for AEGIS application images.

It verifies that:

the image has a valid Cosign signature
the signature comes from the expected OIDC identity
the image belongs to the expected workload scope
the image digest is verified
the artifact that was verified is the artifact that actually runs

Digest verification and mutation protect the deployment from a tag being repointed after verification.

A separate policy audits moving latest tags on workloads outside the enforced AEGIS image rule.

📦 Kargo — Continuous Promotion

Argo CD deploys desired state. Kargo models how a release becomes the desired state.

That distinction is important:

Container Registry
      │
      ▼
Kargo Warehouse
      │
      ▼
Freight
      │
      ▼
Stage
      │
      ▼
Git commit
      │
      ▼
Argo CD
      │
      ▼
Kubernetes

Kargo is installed and managed by Argo CD as part of the platform rather than being configured manually outside GitOps.

Why Kargo exists here

A shell command or CI job can change an image tag, but after the job ends it has very little durable understanding of:

which release candidates are available
which candidate is deployed
which candidate is waiting
what artifact set belongs together
what was promoted previously
what should move from one environment to another later

Kargo turns promotion itself into Kubernetes-native state with history, health and explicit release objects.

`Project` — `aegis-delivery`

The promotion model is scoped under a dedicated Kargo project:

aegis-delivery

Its configuration defines how Freight is allowed to move through Stages.

`Warehouse` — `aegis-images`

The Warehouse watches the AEGIS container stream and discovers release candidates.

kind: Warehouse
metadata:
  name: aegis-images
  namespace: aegis-delivery

A key design decision is to treat the banking platform as a coherent release unit.

All nine application images are produced from the same source commit and share the same sha-* version. The release model therefore represents “AEGIS at commit X” rather than allowing arbitrary combinations of unrelated service revisions to be promoted accidentally.

Freight — immutable release candidates

When Kargo discovers a valid artifact version, it represents that candidate as Freight.

Conceptually:

Freight
  └── AEGIS release @ sha-<commit>

The important property is that a release candidate becomes a named, traceable object instead of only a tag observed inside a transient CI log.

`Stage` — production

The current promotion pipeline contains a production Stage.

kind: Stage
metadata:
  name: production
  namespace: aegis-delivery

Promotion follows the GitOps rule:

Kargo does not deploy directly to the cluster.

Instead, Kargo:

clones the GitOps repository,
updates the production image version,
commits the desired-state change,
pushes that commit,
lets Argo CD detect and reconcile it.

This keeps Argo CD as the only deployment controller and prevents a second system from bypassing Git.

Promotion architecture

flowchart LR
    REG["Docker Hub<br/>signed SHA images"]
    WH["Warehouse<br/>aegis-images"]
    FR["Freight<br/>release candidate"]
    ST["Stage<br/>production"]
    GIT["GitOps repo<br/>production values"]
    ARGO["Argo CD"]
    ROLLOUT["Argo Rollouts"]
    K8S["AEGIS workloads"]

    REG --> WH --> FR --> ST --> GIT --> ARGO --> ROLLOUT --> K8S

Separate credentials for separate responsibilities

Kargo uses distinct credentials rather than reusing the CI or Argo CD identity:

Credential	Purpose
`kargo-api`	Kargo API signing key + admin authentication
`docker-hub`	read-only registry discovery
`gitops-repo`	write access for promotion commits

The Kargo Git writer has its own deploy key. Sharing the CI deploy key would make the two writers indistinguishable in an audit and would couple their revocation.

GitOps-managed Kargo installation

The platform uses two Argo CD Applications:

promotion
    └── installs Kargo

promotion-config
    └── manages Project / Warehouse / Stage

The engine and promotion model are separated so Kargo can be upgraded without treating its controller-generated promotion history as ordinary Git drift.

Argo CD ignores Kargo-owned status fields for resources such as:

Warehouse
Stage
Project

Otherwise Argo CD would continually attempt to revert state that Kargo legitimately owns.

Current promotion posture

The current production policy is deliberately configured with:

autoPromotionEnabled: false

This is intentional while the existing CI promotion writer and Kargo coexist. Allowing two systems to automatically update the same production version would create a race between writers.

The migration path is:

Current
CI promotion ───────────────► Git ─► Argo CD
Kargo        ── observes / models

Target
Kargo Warehouse ─► Freight ─► Stage ─► Git ─► Argo CD

Registry discovery lesson

The Kargo Warehouse is also configured around a real operational constraint: Docker Hub registry discovery can consume significant request quota when NewestBuild must inspect many historical tags.

The repository documents the mitigation explicitly instead of hiding it:

narrow candidate discovery
reduced polling frequency
promotion-time verification of all expected service images
a parked Warehouse state when quota recovery is required

A future production evolution would use a registry/tagging strategy that supports efficient sortable release discovery without per-tag metadata scans.

Why Kargo + Argo CD + Argo Rollouts?

Each tool owns a different concern:

Tool	Responsibility
Kargo	Which release candidate should move forward?
Argo CD	Does the cluster match the approved Git state?
Argo Rollouts	Is the new revision healthy enough to receive traffic?

Together:

Kargo
  │ chooses/promotes release
  ▼
Git
  │ desired state
  ▼
Argo CD
  │ reconciles
  ▼
Argo Rollouts
  │ validates rollout
  ▼
Production

This separation keeps artifact promotion, desired-state reconciliation, and traffic rollout independently auditable.

🔄 Argo CD — App-of-Apps

A single root Application bootstraps the platform.

root-app
   │
   └── apps/
       ├── cert-manager
       ├── admission
       ├── admission-policies
       ├── base
       ├── infrastructure
       ├── runtime-security
       ├── observability
       ├── logs
       ├── routes
       ├── identity
       ├── account
       ├── transaction
       ├── payment
       ├── lending
       ├── platform
       ├── fraud
       ├── gateway
       └── frontend

The complete platform is managed through 23 Argo CD Applications, including the root Application and supporting platform components.

Core reconciliation behaviour

automated synchronization
pruning of removed resources
self-healing drift correction
declarative Helm values
ordered dependency deployment
no routine manual kubectl apply

🌊 Sync Waves

Infrastructure dependencies are ordered declaratively so application services do not race components that are not ready yet.

Example:

Wave -1
  ├── cert-manager
  └── Kyverno engine

Wave 0
  ├── admission policies
  ├── namespace
  ├── ingress
  └── analysis templates

Wave 1
  ├── Vault
  ├── RabbitMQ
  ├── Redis
  ├── observability
  └── runtime security

Later
  └── AEGIS application services

The startup sequence is part of desired state rather than tribal knowledge or timing assumptions.

🤝 Controller-Aware Drift Management

Not every difference from Git is accidental drift.

Some fields are legitimately changed by Kubernetes controllers. Argo CD is configured to ignore selected controller-owned fields where reconciliation would otherwise create a controller conflict.

Argo Rollouts service selectors

Argo Rollouts updates Service selectors with ReplicaSet hashes while steering traffic.

If Argo CD continuously reverted those selectors, GitOps reconciliation and rollout reconciliation would fight each other and could direct traffic to the wrong revision.

Kyverno-generated state

Kyverno may mutate or expand policy state after admission. Selected controller-managed fields are excluded from drift enforcement.

Generated chart secrets

Where charts generate internal values during render or installation, selected generated fields can be ignored to avoid meaningless perpetual drift.

GitOps should correct unwanted drift, not fight legitimate controller ownership.

🚦 Progressive Delivery

AEGIS uses two release strategies based on the failure mode of each component.

🐤 Canary — backend services

Backend services use canary delivery.

A new revision receives only part of traffic while the stable revision remains available.

Stable revision
      │
      ▼
Create canary revision
      │
      ▼
Partial live traffic
      │
      ├── health analysis
      ├── error-rate analysis
      └── latency analysis
      │
      ├── PASS ──► continue / promote
      │
      └── FAIL ──► abort / remain stable

In this k3s implementation, traffic weighting is approximated through replica count because no service mesh is installed. With two replicas, the meaningful stages are approximately half traffic and full traffic.

🔵🟢 Blue-Green — gateway and frontend

Customer entry points use blue-green delivery.

Current version (Blue)
        │
        │ continues serving production
        ▼
New version (Green)
        │
        ▼
Pre-promotion analysis
        │
        ├── FAIL ──► reject Green
        │
        └── PASS
              │
              ▼
         traffic cutover
              │
              ▼
         Green becomes active

The new version is validated beside the active version before production traffic is switched.

🧪 Automated Release Gates

Two analysis patterns protect releases.

`service-health`

Asks:

Is the new revision actually responding?

Configuration:

5 checks
10 seconds apart
zero tolerated failures
expected HTTP response: 200
parameterized service port

This catches workloads that start successfully but immediately become unhealthy.

`canary-metrics`

Asks:

Is the canary hurting customers?

Key signals:

error rate < 5%
p95 latency < 2s
measured against the canary revision

A health endpoint alone is not enough. A service can return 200 on /health while real requests fail.

Useful rollout commands

# Follow a rollout
kubectl argo rollouts get rollout identity -n aegis --watch

# Promote
kubectl argo rollouts promote identity -n aegis

# Abort and hold stable
kubectl argo rollouts abort identity -n aegis

# Roll back
kubectl argo rollouts undo identity -n aegis

📊 Observability

The observability stack combines metrics, logs, alerts, release visibility, and cluster telemetry.

Metrics

kube-prometheus-stack provides:

Prometheus
Alertmanager
Grafana
kube-state-metrics
node-exporter

ServiceMonitors scrape the AEGIS workloads.

Logs

Grafana Alloy collects workload logs and sends them to Loki.

Grafana provides one interface for:

service health
Kubernetes health
request rates
error rates
latency
rollout behaviour
application logs
alerts

AEGIS dashboards

Three purpose-built Grafana dashboards provide 34 panels:

Dashboard	Panels	Focus
Platform Health	11	service health, request rates, error rates, latency, resources
Banking Operations	15	operational workload and transaction-platform signals
Releases	8	rollout revisions, analysis state, release progress

The release dashboard is observational. Argo Rollouts remains responsible for promotion decisions.

🚨 Alerting

Prometheus alert rules cover platform availability and workload health.

Alertmanager receives and groups firing alerts.

Useful diagnostic:

kubectl exec -n observability \
  prometheus-observability-kube-prometh-prometheus-0 \
  -c prometheus -- \
  promtool query instant http://localhost:9090 \
  'ALERTS{alertstate="firing"}'

Watchdog intentionally remains firing as a dead-man's-switch signal proving the alerting pipeline itself is alive.

🚨 Runtime Security with Falco

CI, scanning, signing, and admission policies judge software before or during deployment.

Falco observes actual workload behaviour after deployment.

The platform uses:

Falco
modern eBPF driver
JSON output
syscall-drop monitoring
Falcosidekick
Falcosidekick UI
Prometheus ServiceMonitor

Custom AEGIS detections

Detection	Severity	Purpose
Shell opened in a banking container	WARNING	Interactive shells are not expected in application containers
Reconnaissance tooling	WARNING	Detect unexpected use of tools such as `nc`, `nmap`, `curl`, `wget`, or `ssh`
Credential material read	CRITICAL	Detect suspicious access to service-account or credential material
Vault data touched by non-Vault process	CRITICAL	Protect sensitive Vault storage paths

The goal is to detect suspicious behaviour, not only known malicious files.

🔐 Secrets & Vault

No application secret is committed to the GitOps repository.

Sensitive material is created or injected separately from Git.

HashiCorp Vault provides the application secret-management layer.

Control	Implementation
Seal mechanism	Shamir secret sharing
Threshold	3-of-5 shares
Service authentication	AppRole
Field encryption	AES-256-GCM keys supplied through Vault
Bootstrap	Scripted initialization / secret creation outside Git

The design avoids embedding database credentials, Vault credentials, or cryptographic keys in deployment manifests.

🌐 Ingress & TLS

All externally exposed platform interfaces are routed through Traefik.

TLS is managed by:

cert-manager
Let's Encrypt
Kubernetes Certificate resources
HTTP → HTTPS redirection

Internet
   │
   ▼
Traefik
   │
   ├── Application
   ├── Argo CD
   ├── Grafana
   ├── Prometheus
   ├── Alertmanager
   └── Falcosidekick UI

Certificates are automatically issued and renewed through cert-manager.

🔒 Kubernetes Security Posture

The aegis namespace is configured around a restricted workload posture.

Controls include:

non-root workloads
dropped Linux capabilities
seccomp RuntimeDefault
restricted Pod Security posture
signed-image admission for application workloads
no latest deployment strategy
secrets excluded from Git
HTTPS ingress
runtime detection with Falco

Security is implemented in layers:

Source
  │
  ▼
CI validation
  │
  ▼
Container scanning
  │
  ▼
SBOM
  │
  ▼
Image signing
  │
  ▼
GitOps desired state
  │
  ▼
Kyverno admission
  │
  ▼
Kubernetes hardening
  │
  ▼
Falco runtime detection

🚀 Bootstrap

The platform follows an app-of-apps bootstrap model.

# Apply the single root Application
kubectl apply -f bootstrap/root-app.yaml

After that, Argo CD discovers and reconciles the child Applications.

Secrets and Vault initialization are intentionally separate from Git:

# Example secret bootstrap
./scripts/create-secrets.sh /path/to/application/.env

# Initialize / configure Vault after it is running
./scripts/bootstrap-vault.sh

The exact secret material is never committed.

🔧 Operations

Platform status

kubectl get applications -n argocd
kubectl get rollouts -n aegis
kubectl get pods -A

Investigate an Argo CD Application

kubectl get app <name> -n argocd \
  -o jsonpath='{.status.operationState.phase} {.status.operationState.message}'

Check Vault

kubectl exec -n aegis deploy/vault -c vault -- \
  sh -c 'VAULT_ADDR=http://127.0.0.1:8200 vault status'

Watch a deployment

kubectl argo rollouts get rollout identity -n aegis --watch

✅ What This Platform Demonstrates