Browse OpenForge documentation
Narwhal Portal · OSS Project

Narwhal Portal

Operations and developer workbench for the Narwhal Kubernetes Internal Developer Platform

KubernetesIDPNext.jsReactTypeScriptKeycloakGitOpsPlatform Engineering
RepositoryGitHub ↗
Documentation5 sections
Updated2026-08-27T00:00:00.000Z
ECOSYSTEM ROLE
Platform Experience Layer

The day-0 to day-2 experience layer that brings Narwhal GitOps, SSO, observability, security, cost and governance signals into one developer/operator workbench.

Operational surfaceAuthoritative-source integrationDeveloper & operator UX
PROJECT CONFORMANCE

Repository evidence checklist

3 present · 6 missing

Present means an explicit repository or site artifact was observed. Missing means this audit did not observe that artifact; it does not prove the underlying practice does not exist. Tracked links point to the closest existing backlog owner and do not create issues automatically.

CONTRIBUTING
Missing
CODE_OF_CONDUCT
Missing
SECURITY.md
Missing
SBOM evidence
Missing
Provenance / attestation
Missing
GitHub Release
Present
Evidence observed
Project detail docs
Present
5 sections
Evidence observed
Community contributor signal
Present
2 contributors
Evidence observed
repository audit not indexed
Problem

A Kubernetes IDP can expose dozens of independent dashboards while leaving platform-wide state, relationships, and operator workflows fragmented

Approach

A unified Next.js portal that presents cluster, application, catalog, security, cost, governance, and onboarding workflows as one operational surface

ENGINEERING EVIDENCE

Show reviewable engineering evidence instead of relying on headline numbers.

Experience
Day-0 → Day-2

Combines onboarding, catalog, platform operations, security, governance, and tools in one workbench.

Platform views
10+ areas

Dashboard, onboarding, catalog/apps, nodes, cost, security/compliance, governance, architecture, tools, and settings.

Delivery
Kaniko + Skaffold

Supports in-cluster image builds and live development without requiring a local Docker daemon for the normal cluster workflow.

State boundary
Authoritative sources

Reads platform state from Kubernetes, Argo CD, Keycloak, and other source systems instead of replacing them.

START HERE

You do not need to read the README from top to bottom.

ENGINEERING PRINCIPLES
Source-driven

Keep project explanations grounded in repository source, architecture, tests, releases, and operating records.

Independently useful

Even inside one ecosystem, keep boundaries independently installable, verifiable, and releasable whenever possible.

Evidence over claims

Prefer reproducible verification, incident knowledge, upgrade gates, and operating evidence over feature-count claims.

Project Overview

Narwhal Portal is the management portal and developer workbench for the Narwhal Kubernetes Internal Developer Platform.

Narwhal provides the underlying GitOps, SSO, observability, storage, security, and platform services. The Portal provides the day-2 operational surface that makes those services understandable and usable as one platform.

The portal does not try to replace every upstream UI. Kubernetes, Argo CD, Keycloak, and other systems remain authoritative; the Portal aggregates platform signals and exposes them through platform-level concepts.

Core Areas

AreaPurpose
DashboardCluster health, Argo CD applications, alerts, and overall platform status
OnboardingGetting-started workflow and kubeconfig issuance
Catalog / My AppsService catalog and per-user application view
NodesNode inventory and status
CostNamespace/workload cost visibility
Security / ComplianceSecurity posture, policies, RBAC, and audit-related information
GovernanceScorecards, DORA-related information, and platform maturity signals
ArchitecturePlatform and service relationships
Templates / ToolsDeveloper-oriented platform utilities
SettingsUsers, routes, certificates, and policy settings

Position in Narwhal

Technology Stack

  • Next.js ^16.3.1 / React 19.2.8 — App Router application
  • TypeScript ^6.0.3 — typed frontend/API boundaries
  • Tailwind CSS 4.3.3 / shadcn/ui — reusable admin UI
  • TanStack Query / Zustand — server/client state
  • NextAuth 5.0.0-beta.30 + Keycloak OIDC — authentication and sessions
  • Valkey — application cache (a dedicated pub/sub client keeps long-lived subscriptions apart from the fail-fast cache client's short timeout/retry limits)
  • OpenBao Agent Injector — runtime secrets injection
  • Skaffold / Kaniko — Kubernetes inner-loop development and in-cluster image builds
  • Vitest — unit/regression suite wired into CI. Playwright-based browser-level e2e coverage is still planned, not claimed as implemented on main (docs/IMPLEMENTATION-STATUS.md, last verified 2026-09-14)
  • pnpm 10.27.0 (pinned via packageManager)

Current Status

The latest tagged release is v1.0.17 (2026-08-09). It made the platform-tool tile base domain configurable via CLUSTER_BASE_DOMAIN, derived node roles correctly from the Prometheus kube_node_role metric and K8s labels (both control-plane and the legacy master key), fixed compliance framework pass-rate scaling (0-1 ratios were rendering as 1%), and queried cluster-scoped clusterinfraassessmentreports alongside namespaced reports so trivy-operator node security findings are reflected. This release also introduced an automated GitHub Release workflow that publishes notes from CHANGELOG.md on tag push.

Since v1.0.17, main has accumulated substantial security hardening without a new tag yet (as of 2026-09-23, the repository has 300 commits total):

  • Centralized role-string checks on requireRole/requireAdmin and enforced resource-scoping on the cost/security detail and trend APIs
  • Switched OpenBao authentication from a static token to Kubernetes auth login, and replaced the long-lived K8s service-account token with a projected short-lived token
  • Anchored the federated-logout redirect allowlist to close an open-redirect bypass
  • Enforced production TLS for Keycloak/Gitea integrations and restricted the health endpoint to cluster-admin
  • Applied an Agent Execution Security Contract to the privileged node-tuning path, with exact-invocation approval, server-side recomputation, and replay protection (PR #90)

This work is under verification on main for a future release and is not yet part of a published tag.

Deployment Model

The production portal is served inside the Narwhal cluster at https://portal.local.narwhal.internal through the APISIX gateway.

A local development loop is available with:

git clone https://github.com/dasomel/narwhal-portal.git
cd narwhal-portal
pnpm install
pnpm dev

For cluster-based development, the project also supports Skaffold HMR. Production image workflows can use the in-cluster Gitea → Kaniko → Harbor path, avoiding a local Docker daemon for the normal deployment flow.

Design Principles

Preserve authoritative sources

Argo CD, Kubernetes, Keycloak, and other platform services keep ownership of their resources. The Portal is a user-facing integration layer, not a competing source of truth.

Use platform domains

Users should not need to understand every upstream product to answer platform questions. Concepts such as Application, Service, Catalog, Security, and Governance create a consistent IDP vocabulary.

Expose operational boundaries

GitOps ownership, policy violations, authentication state, certificate state, and failure conditions should be visible in the UI rather than hidden behind an upstream product boundary.

Connect Day-0 and Day-2

Onboarding, Catalog, Templates, Tools, and operational dashboards are part of the same workbench so the portal spans from initial access to ongoing operations.

Documentation Index

TopicDocumentPurpose
OverviewPortal OverviewRole and user scenarios
ArchitecturePortal ArchitectureApplication/data flow
Getting StartedDevelopment Setuppnpm, environment, Skaffold
OperationsDeployment & OperationsBuild, deployment, health
ADRArchitecture Decision RecordsTechnical decisions and trade-offs

Project Relationship