Skip to main content

Portal Architecture

In Development

This feature is currently in development. Architecture described here is subject to change.

Purpose: For platform engineers and architects, explains the portal's technical architecture — how requests flow from UI to running infrastructure through GitOps.

Architecture Overview

Components

ComponentRoleTechnology
Portal UIWeb interface for developersReact + Headlamp plugin
Portal APIRequest validation and Git operationsGo service
Policy EngineQuota checks, approval routingKyverno + custom admission
Git BackendSource of truth for all provisioned resourcesCustomer GitOps repo
FluxCDReconciles Git state to clusterStandard openCenter FluxCD

Request Lifecycle

  1. Authenticate — User authenticates via Keycloak OIDC
  2. Authorize — Portal checks team membership and RBAC permissions
  3. Validate — Request checked against quotas and policy constraints
  4. Approve (if required) — Elevated requests route to approvers
  5. Commit — Portal writes CRD manifest to team's Git repository
  6. Reconcile — FluxCD detects change and creates Kubernetes resources
  7. Notify — Portal reports provisioning status to the requester

Integration Points

  • Keycloak: SSO, team membership, role-based access
  • Kyverno: Resource validation at admission time
  • FluxCD: GitOps reconciliation (no direct API calls to cluster)
  • Prometheus: Usage metrics for quota enforcement
  • Headlamp: Portal UI embedded as Headlamp plugin