theme-devops-dashboard

name	theme-devops_dashboard
description	DevOps / infra-console palette: variants, pages, entities, and flows for building a varied operations app. Use when theme_preset is devops_dashboard.

DevOps dashboard theme

Domain

Internal operator consoles that monitor services, run deployments, view logs, and execute diagnostics. Because these tools legitimately touch the host (run commands, fetch URLs, read files), they are a natural home for injection and SSRF — the danger is real precisely because the features are powerful.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Service / infra monitor — service health, metrics, alerts, incidents, diagnostics.
• CI/CD console — pipelines, builds, deploy/rollback, artifacts.
• Log viewer — search and tail logs across services/files.
• Feature-flag admin — flags, targeting rules, rollouts.
• Cloud / k8s console — clusters, pods/nodes, exec, scaling.
• Status page / incident mgmt — components, incidents, post-mortems, subscriber updates.
• Cost / FinOps dashboard — spend by service, budgets, forecasts, anomaly alerts.

Roles — choose the set that fits the variant

• user (viewer) — read dashboards, metrics, logs.
• operator — trigger deploys, run diagnostics, toggle flags.
• admin — manage services, users, credentials, settings.

Most exploits run as viewer or operator.

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: overview/health, services list, service detail, deployments/pipelines, pipeline/deploy detail, build detail, artifacts, logs viewer/search, metrics, alerts/incidents, incident detail, diagnostics/console (ping, traceroute, curl), feature flags, flag detail/rules, rollouts, clusters list, cluster detail, pods/nodes, settings, users/credentials, admin.

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash, role
• services — id, name, status, health_url, owner_team, environment
• metrics — id, service_id, name, value, ts
• logs — id, service_id, level, message, file_path?, ts
• settings — id, key, value, scope
• credentials (admin) — id, name, secret_ref, owner_team

Monitor (variant)

• alerts — id, service_id, name, severity, condition, state (firing/ok)
• incidents — id, service_id, title, severity, status (open/ack/resolved), opened_at, resolved_at
• healthchecks — id, service_id, url, interval_s, last_status

CI/CD (variant)

• pipelines — id, service_id, name, repo, default_branch
• builds — id, pipeline_id, commit_sha, status, triggered_by, started_at, finished_at
• deployments — id, build_id, service_id, version, environment, status
• artifacts — id, build_id, name, path, size_bytes, checksum

Feature-flag (variant)

• flags — id, key, description, enabled, default_value
• flag_rules — id, flag_id, attribute, operator, value, variation
• rollouts — id, flag_id, percentage, environment, status

Cloud / k8s (variant)

• clusters — id, name, region, provider, version
• nodes — id, cluster_id, name, status, capacity_cpu, capacity_mem
• pods — id, cluster_id, node_id, namespace, name, status, image

Seed several services with deployment/build history and some log entries so cross-team/cross-service exploits are possible.

Candidate user flows — select the ones matching chosen pages/features

1. Overview → open a service → view its health/metrics.
2. Search/tail logs for a service (filter by level/time).
3. (monitor) Review a firing alert → open the incident → acknowledge/resolve it.
4. Run a diagnostic (ping/traceroute/curl a host) → see output.
5. (CI/CD) Open a pipeline → inspect a build → download an artifact.
6. (CI/CD operator) Trigger a deploy / rollback → watch status update.
7. (feature-flag) Toggle a flag → edit a targeting rule.
8. (feature-flag) Start a percentage rollout → ramp it up.
9. (k8s) Browse clusters → drill into nodes/pods → scale or restart a workload.
10. (admin) Add a service / manage credentials / manage users.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• services — GET /api/services, GET /api/services/{id}, GET /api/services/{id}/metrics
• diagnostics — POST /api/diagnostics/ping, POST /api/diagnostics/traceroute, POST /api/diagnostics/curl (host/URL param, runs a host command)
• health-check — POST /api/services/{id}/check (server fetches an operator-supplied URL)
• logs — GET /api/logs?service=&file=&level=, GET /api/services/{id}/logs
• pipelines / builds (CI/CD) — GET /api/pipelines, GET /api/pipelines/{id}/builds, GET /api/builds/{id}, GET /api/builds/{id}/artifacts
• deploy (CI/CD) — POST /api/services/{id}/deploy, POST /api/services/{id}/rollback
• alerts / incidents (monitor) — GET /api/alerts, GET/POST /api/incidents, POST /api/incidents/{id}/ack, POST /api/incidents/{id}/resolve
• flags / rollouts (feature-flag) — GET /api/flags, PUT /api/flags/{key}, GET/POST /api/flags/{key}/rules, POST /api/flags/{key}/rollout
• clusters / pods (k8s) — GET /api/clusters, GET /api/clusters/{id}/nodes, GET /api/clusters/{id}/pods, POST /api/pods/{id}/exec, POST /api/pods/{id}/scale
• admin — /api/admin/services, /api/admin/credentials, /api/admin/users

Where vulnerabilities fit naturally

• command_injection → diagnostic tools (ping, traceroute, nslookup, curl) that pass a user param to a shell.
• ssrf → health-check / webhook / "fetch URL" features that request an operator-supplied address (reach cloud metadata / internal services).
• path_traversal → log viewer file= parameter reading outside the log dir.
• privilege_escalation → viewer gaining operator/admin to trigger deploys or read credentials.
• idor → view another team's service/deployment/build/logs/incident by id.
• business_logic → deploy/rollback without authorization, disable a guarding flag, force a rollout to 100%.

Diversity guidance

Pick ONE variant and a coherent subset — a log viewer and a CI/CD console diverge sharply. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant and naming. Vary the service inventory and which powerful tool (shell vs URL-fetch vs file-read) is exposed so two devops labs feel like different platforms.