38 KiB
38 KiB
Pack 11 — Release Control (root) + Governance + Admin (IAM/Notifications/Usage) + System + Trust & Signing
This pack converts the remaining “Settings” pages into the release-first Stella Ops IA, adds the missing region-first environment model, and makes governance + determinism explicit (aligned with Stella’s stated focus on digest-first release identity, evidence, reachability/hybrid reachability, and audit exports). (Stella Ops Suite)
11.1 Menu graph (Mermaid) — the menus touched in this pack
NOTE: This is a partial root graph (only the menus we’re redesigning here). It preserves your “main reorg” (release-first), keeps Release Control as a root menu, and moves “Settings” items into Admin / System / Evidence Trust where they belong.
flowchart TD
ROOT[Stella Ops Console] --> RC[Release Control (ROOT)]
ROOT --> ADM[Administration]
ROOT --> SYS[System (Platform)]
ROOT --> EVID[Evidence]
ROOT --> INT[Integrations]
%% RELEASE CONTROL
RC --> RC_HOME[Release Control Home]
RC --> RC_REG[Regions & Environments]
RC --> RC_TARGETS[Deployment Targets]
RC --> RC_AGENTS[Agents]
RC --> RC_WF[Workflows]
RC --> RC_GOV[Governance\n(Policy, Gates, Simulation, Exception Workflow)]
RC_REG --> RC_ENV[Environment Detail]
%% ADMIN
ADM --> IAM[Identity & Access]
ADM --> NOTIF[Notifications]
ADM --> LIMITS[Usage & Limits]
ADM --> BRAND[Tenants & Branding]
%% SYSTEM
SYS --> SYS_HOME[System Console\n(Health, Doctor, SLO, Jobs)]
SYS_HOME --> JOBS[Background Jobs]
SYS_HOME --> HEALTH[Health Check Detail]
%% EVIDENCE / TRUST
EVID --> TRUST[Trust & Signing]
TRUST --> KEYS[Signing Keys]
TRUST --> ISSUERS[Issuers]
TRUST --> CERTS[Certificates]
TRUST --> REKOR[Transparency Log]
TRUST --> SCORE[Trust Scoring]
TRUST --> AUDIT[Audit Log]
%% CROSS LINKS (2nd-class, not buried)
RC_ENV -. "Vault/Consul inputs" .-> INT
JOBS -. "Feed sync failures" .-> INT
RC_GOV -. "Exception workflow uses Security Exceptions" .-> ROOT
11.2 Screen — Release Control Home
Formerly
- Settings → Release Control (
/settings/release-control) (cards: Environments, Targets, Agents, Workflows)
Why moved / reshaped
- Stella is explicitly release-governance centric (promotion graphs, digest-first identity, deterministic decision records). (Gitea: Git with a cup of tea)
- So “Release Control” must be ROOT (operator-facing), not buried under Settings.
Screen graph (Mermaid)
flowchart LR
A[Release Control Home] --> B[Regions & Environments]
A --> C[Deployment Targets]
A --> D[Agents]
A --> E[Workflows]
A --> F[Governance Hub]
A --> G[Integrations Hub]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Release Control (ROOT) │
│ Legacy: Settings ▸ Release Control (/settings/release-control) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Purpose: configure how releases are promoted + executed across regions/envs (digest-first). │
│ Region scope: [All] US-East EU-West APAC Env types: Dev/QA/Staging/Prod │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Quick Links │
│ [Regions & Environments] [Targets] [Agents] [Workflows] [Governance] │
│ │
│ Attention (release-impacting drift) │
│ • EU-West Prod: env variables source missing (Consul mapping not configured) │
│ • US-East Stage: agent offline → promotions will stall │
│ • Policy baseline “Prod” updated yesterday → 2 approvals will replay under new baseline │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.3 Screen — Regions & Environments
Formerly
- Accessed via Settings → Release Control → Manage Environments (button from the card)
Why moved / reshaped
- You called out a missing core: environments must be organized per region.
- Stella’s model is “what is deployed where” must be unambiguous; region-first is required for that clarity. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD
A[Regions & Environments] --> B[Region Detail]
B --> C[Environment Detail]
A --> D[Create Region]
B --> E[Create Environment]
C --> F[Promotion Graph]
C --> G[Env Inputs (Vault/Consul)]
C --> H[Env SBOM & Findings Summary]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Regions & Environments │
│ Legacy: Settings ▸ Release Control ▸ Environments (Manage Environments) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Regions: [ + Create Region ] │
│ │
│ ┌───────────────────────┬───────────────┬───────────┬──────────────────────────────────────┐ │
│ │ Region │ Environments │ Agents OK │ Release Health Summary │ │
│ ├───────────────────────┼───────────────┼───────────┼──────────────────────────────────────┤ │
│ │ US-East │ 6 (2 prod) │ 5/6 │ 1 env w/ critical reachable findings │ │
│ │ EU-West │ 4 (1 prod) │ 4/4 │ clean │ │
│ │ APAC │ 3 (1 prod) │ 3/3 │ feeds stale → gating risk medium │ │
│ └───────────────────────┴───────────────┴───────────┴──────────────────────────────────────┘ │
│ Click a region → Region Detail │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.4 Screen — Region Detail
Formerly
- Not present as a first-class concept (regions missing; envs likely flat)
Why moved / reshaped
-
Region is the natural unit for:
- feed freshness / mirror selection,
- deployment agents & targets,
- environment variables sources (Vault/Consul partitioning).
Screen graph (Mermaid)
flowchart LR
A[Region Detail] --> B[Environment Detail]
A --> C[Region Agents]
A --> D[Region Feeds Freshness]
A --> E[Region Targets]
A --> F[Region Defaults\n(policy baseline, locks, inputs)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Region: US-East │
│ Legacy: (new) — previously environments were not region-first │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Defaults: Policy Baseline = Prod-US-East Feed Lock = lock-2026-02-18 Vars = Vault+Consul │
│ │
│ Environments │
│ ┌───────────────┬──────────────┬───────────────┬─────────────────────┬──────────────────────┐│
│ │ Env │ Type │ Promotion Path │ SBOM/Security Status │ Agent/Target ││
│ ├───────────────┼──────────────┼───────────────┼─────────────────────┼──────────────────────┤│
│ │ us-dev │ Dev │ — │ informational only │ agent-01 / docker-01 ││
│ │ us-stage │ Staging │ dev→stage │ 2 high (not reachable)│ agent-02 / docker-02 ││
│ │ us-prod │ Production │ stage→prod │ 1 critical reachable │ agent-03 / docker-03 ││
│ └───────────────┴──────────────┴───────────────┴─────────────────────┴──────────────────────┘│
│ Links: [Feeds Freshness] [Agents] [Targets] [Region Defaults] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.5 Screen — Environment Detail (Config + Status summary)
Formerly
- “Environment” concept appeared on Control Plane / Releases / Approvals pages, but
- no dedicated region-first “env detail” with SBOM + reachability + runtime proof surfaced.
Why moved / reshaped
-
Stella’s promise includes reachability and hybrid reachability evidence. (Gitea: Git with a cup of tea)
-
Environment is where hybrid reachability becomes meaningful:
- Image reachability (static),
- Build reachability (build-time evidence),
- Runtime reachability (environment traces).
-
This must be second-class (tabs/sections), not buried.
Screen graph (Mermaid)
flowchart TD
A[Environment Detail] --> B[Overview]
A --> C[Promotion Rules]
A --> D[Inputs\n(Vault/Consul mappings)]
A --> E[SBOM & Findings Summary]
A --> F[Reachability Coverage\n(image/build/runtime)]
A --> G[Targets & Agents]
A --> H[Audit Trail\n(decisions affecting env)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Environment: us-prod (Region: US-East) │
│ Legacy: part of Settings ▸ Release Control ▸ Environments / scattered across Control Plane │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Promotion] [Inputs] [SBOM & Findings] [Reachability] [Targets/Agents] [Audit]│
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Current deployed bundle: bundle-us-prod-2026.02.18-01 │
│ Current deployed digests: 14 images (13 known scanned / 1 pending scan) │
│ │
│ Security summary (last 24h) │
│ Critical reachable: 1 | High reachable: 0 | High not reachable: 3 | VEX coverage: 62% │
│ “Why?” links → open Finding set filtered to env + reachability class │
│ │
│ Hybrid reachability coverage (2nd-class, but visible here) │
│ Image evidence: 100% | Build evidence: 78% | Runtime evidence: 35% │
│ Gap: runtime traces missing on 9 services → enable agent trace hook / importer │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.6 Screen — Deployment Targets
Formerly
- Settings → Release Control → Manage Targets
Why moved / reshaped
- Targets are release execution primitives (where things get deployed).
- Putting them under Release Control keeps “release execution” in the same domain as “release governance”.
Screen graph (Mermaid)
flowchart LR
A[Targets] --> B[Target Detail]
A --> C[Create Target]
B --> D[Test Connection]
B --> E[Assigned Environments]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Deployment Targets │
│ Legacy: Settings ▸ Release Control ▸ Targets (Manage Targets) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: [All] US-East EU-West APAC Type: [Docker Hosts] [VM Groups] [Baremetal] │
│ Actions: [+ Create Target] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────┬───────────┬─────────────┬──────────────┬─────────────────────────────────┐│
│ │ Target │ Region │ Status │ Last Check │ Used by Environments ││
│ ├───────────────┼───────────┼─────────────┼──────────────┼─────────────────────────────────┤│
│ │ docker-us-03 │ US-East │ HEALTHY │ 2m ago │ us-prod, us-stage ││
│ │ docker-eu-01 │ EU-West │ HEALTHY │ 3m ago │ eu-prod ││
│ │ docker-apac-02 │ APAC │ DEGRADED │ 12m ago │ apac-uat ││
│ └───────────────┴───────────┴─────────────┴──────────────┴─────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.7 Screen — Agents
Formerly
- Settings → Release Control → Manage Agents
Why moved / reshaped
-
Agents are needed for:
- deployment execution,
- optional runtime evidence collection (hybrid reachability),
- replay/verify hooks.
-
Keeping them here keeps the “control plane” coherent with Stella’s evidence and reachability focus. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD
A[Agents] --> B[Agent Detail]
B --> C[Capabilities\n(deploy, trace, attest)]
B --> D[Assigned Targets/Envs]
B --> E[Health Logs]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agents │
│ Legacy: Settings ▸ Release Control ▸ Agents (Manage Agents) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────┬───────────┬─────────────┬─────────────────────┬──────────────────────────┐│
│ │ Agent │ Region │ Status │ Capabilities │ Assigned ││
│ ├───────────────┼───────────┼─────────────┼─────────────────────┼──────────────────────────┤│
│ │ agent-03 │ US-East │ HEALTHY │ deploy, attest, trace│ us-prod ││
│ │ agent-02 │ US-East │ HEALTHY │ deploy, attest │ us-stage ││
│ │ agent-apac-01 │ APAC │ DEGRADED │ deploy │ apac-uat ││
│ └───────────────┴───────────┴─────────────┴─────────────────────┴──────────────────────────┘│
│ Note: Trace capability drives “runtime reachability coverage” on env detail. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.8 Screen — Workflows
Formerly
- Settings → Release Control → Edit Workflows
Why moved / reshaped
- Workflows are the standardized release execution templates (canary, A/B, rollback) that Stella highlights as part of release governance and controlled rollout. (Stella Ops Suite)
- This becomes the canonical place to manage them.
Screen graph (Mermaid)
flowchart LR
A[Workflows] --> B[Workflow Editor]
B --> C[Validate Workflow]
B --> D[Publish Version]
B --> E[Used by Releases/Policies]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Workflows │
│ Legacy: Settings ▸ Release Control ▸ Workflows (Edit Workflows) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌──────────────────────┬───────────────┬──────────┬────────────────────────────────────────┐ │
│ │ Workflow │ Version │ Status │ Used by │ │
│ ├──────────────────────┼───────────────┼──────────┼────────────────────────────────────────┤ │
│ │ Rolling Update │ v3 │ ACTIVE │ default │ │
│ │ Canary 10% → 50% → 100│ v2 │ ACTIVE │ prod baselines │ │
│ │ Fast Rollback │ v1 │ ACTIVE │ incident response │ │
│ └──────────────────────┴───────────────┴──────────┴────────────────────────────────────────┘ │
│ Actions: [Create] [Edit] [Validate] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.9 Screen — Governance Hub (Policy baselines, gate rules, simulation, exception workflow)
Formerly
-
Settings → Policy Governance (
/settings/policy)- Policy Baselines
- Governance Rules
- Policy Simulation
- Exception Workflow
Why moved / reshaped
-
Governance is not “settings”; it is core Release Control:
- policy-as-code evaluation with traceable outcomes (“why blocked?”) and replayability is a stated Stella deliverable. (Gitea: Git with a cup of tea)
-
So it becomes: Release Control → Governance (still admin-controlled, but release-centric).
Screen graph (Mermaid)
flowchart TD
A[Governance Hub] --> B[Policy Baselines]
A --> C[Gate Rules]
A --> D[Policy Simulation]
A --> E[Exception Workflow Config]
C --> F[Gate Detail\n(why blocked trace model)]
E --> G[Security Exceptions\n(request/approve)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Release Control ▸ Governance │
│ Legacy: Settings ▸ Policy Governance (/settings/policy) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Cards │
│ [Policy Baselines] [Gate Rules] [Policy Simulation] [Exception Workflow] │
│ │
│ Recent governance changes (audit-relevant) │
│ • Prod baseline updated: CVE freshness gate now “hard block” │
│ • Exception workflow: requires 2 approvers for critical reachable │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.10 Screen — Identity & Access
Formerly
- Settings → Identity & Access (
/settings/admin)
Why moved / reshaped
- This is classic administrative scope: users, roles, API keys, OAuth clients, tenants.
- Move under Administration, not in release/security menus.
Screen graph (Mermaid)
flowchart LR
A[Identity & Access] --> B[Users]
A --> C[Roles]
A --> D[OAuth Clients]
A --> E[API Tokens]
A --> F[Tenants]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Identity & Access │
│ Legacy: Settings ▸ Identity & Access (/settings/admin) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] │
│ Banner: failures here can block approvals + evidence signing (auth). │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.11 Screen — Notifications
Formerly
- Settings → Notifications (
/settings/notifications)
Why moved / reshaped
- Also admin scope.
- But must support release-centric alerting: approvals waiting, feed stale, scan failed, evidence export ready.
Screen graph (Mermaid)
flowchart TD
A[Notifications] --> B[Rules]
A --> C[Channels]
A --> D[Templates]
A --> E[Delivery Log]
B --> F[Rule Detail\n(event→recipients)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Notifications │
│ Legacy: Settings ▸ Notifications (/settings/notifications) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Rules (event triggers) Channels Templates │
│ - approval.pending → #release-approvals - Email: Active - Approval request │
│ - feed.stale → #sec-ops - Slack: Active - Feed stale alert │
│ - scan.failed → #build-cops - Webhook: Not configured - Scan failure │
│ - evidence.ready → email auditors │
│ [View Delivery Log] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.12 Screen — Usage & Limits
Formerly
- Settings → Usage & Limits (
/settings/usage)
Why moved / reshaped
- This is tenant/admin entitlement + limit configuration.
- Keep operational usage charts accessible, but do quota enforcement config here; operational throttles remain in Platform Ops → Quotas.
Screen graph (Mermaid)
flowchart LR
A[Usage & Limits] --> B[Entitlements Summary]
A --> C[Quota Configuration]
A --> D[Usage Reports]
A --> E[Throttle Events Link\n(to Ops Quotas)]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Administration ▸ Usage & Limits │
│ Legacy: Settings ▸ Usage & Limits (/settings/usage) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ This month: Scans 6,500/10,000 Storage 42/100 GB Evidence Packets 2,800/10,000 │
│ API Requests 15,000/100,000 │
│ │
│ [Configure Quotas] [Export Usage Report] Link: [View Operational Throttles (Ops ▸ Quotas)]│
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.13 Screen — System Console (Health / Doctor / SLO / Background Jobs)
Formerly
- Settings → System (
/settings/system)
Why moved / reshaped
-
System health + background jobs directly explain:
- “why are feeds stale?”
- “why are rescans failing?”
- “why are evidence exports missing?”
-
That’s operational, not “settings”. It becomes System (Platform), reachable as root and also second-class from the Dashboard “Nightly Ops Signals”.
Screen graph (Mermaid)
flowchart TD
A[System Console] --> B[Health Check Detail]
A --> C[Doctor]
A --> D[SLO Monitoring]
A --> E[Background Jobs]
E --> F[Nightly Ops Report\n(job failures → impacts)]
E --> G[Dead Letter Queue]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ System (Platform) │
│ Legacy: Settings ▸ System (/settings/system) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Health Check: ● All systems operational [View Details] │
│ Doctor: [Run Doctor] SLO Monitoring: [View SLOs] │
│ Background Jobs: [View Jobs] │
│ │
│ Operator note: job failures here must surface on Dashboard + block/reduce confidence in gates. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
11.14 Screen — Trust & Signing
Formerly
- Settings → Trust & Signing (
/settings/trust)
Why moved / reshaped
-
This is the cryptographic and issuer-trust foundation for:
- DSSE evidence, attestations,
- issuer trust/conflict resolution for VEX,
- transparency logs.
-
Those belong under Evidence → Trust & Signing, consistent with Stella’s emphasis on verifiability and audit export. (Gitea: Git with a cup of tea)
Screen graph (Mermaid)
flowchart TD
A[Trust & Signing] --> B[Signing Keys]
A --> C[Issuers]
A --> D[Certificates]
A --> E[Transparency Log]
A --> F[Trust Scoring]
A --> G[Audit Log]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Evidence ▸ Trust & Signing │
│ Legacy: Settings ▸ Trust & Signing (/settings/trust) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Modules │
│ [Signing Keys] [Issuers] [Certificates] [Transparency Log] [Trust Scoring] [Audit Log] │
│ │
│ Why here: this config affects evidence packets, attestations, issuer trust, and audits. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
What I did NOT include yet (next pack)
You explicitly flagged Release Bundle Organizer as crucial. It needs its own pack because it’s not a single screen—it’s a workflow:
- Bundle catalog (per repo / per product line),
- Bundle compose (digests → service versions),
- Env-var resolution (Vault + Consul mappings per env/region),
- Bundle changelog (per repository),
- Bundle → Release promotion linkage.
If you say “continue”, Pack 12 will be only the Bundle Organizer: full Mermaid graphs + ASCII mocks + “formerly/why” (it’s mostly net-new).