Environments

An environment in IronSled maps to a Kubernetes namespace running inside a Rancher-managed cluster. Each environment is tagged with a type — Development, Staging, QA, UAT, Production, or Other — and can optionally feed metrics into the project dashboard.

A project can have multiple environments. A typical setup might include a development namespace for active work, a staging namespace for pre-release testing, and a production namespace for live traffic.

To link an environment to a project:

1. Navigate to the project's Environments section.
2. Click Add Environment (requires Platform Manager permission).
3. In the dialog, select:
   • Rancher Server — Choose from the platform's configured Rancher instances.
   • Cluster — Select the Kubernetes cluster (loaded from the chosen Rancher server).
   • Namespace — Select the namespace within the cluster.
   • Environment Type — Classify the environment: Development, Staging, QA, UAT, Production, or Other.
4. Optionally set a Display Name (defaults to the namespace name).
5. The Include in Dashboard toggle is enabled by default — this controls whether the environment's metrics contribute to the project dashboard KPIs.
6. Click Save.

The environment is linked to the project and IronSled begins pulling data from Rancher.

Any project member can request a new environment for their project. The request is submitted to the platform team for review and provisioning.

1. Navigate to the project's Environments section.
2. Click Request Environment. A side panel opens with a structured form.
3. Fill out the request:
   • Target Environment — Select the environment type to create: Development, Testing, Staging, Production, or Demo. Environment types that already exist for the project are excluded from the list.
   • Justification — Explain why this environment is needed and how the team will use it. A minimum of 20 characters is required.
   • DNS Subdomain (optional) — If the environment needs a public-facing URL, provide a subdomain name. IronSled shows a preview of the resulting URLs for each level (e.g., my-app.dev.ironsled.com and my-app.gov.ironsled.com).
   • Containers — Define the containers that will be deployed in this environment. For each container, provide:
     • Name — A descriptive name for the container (e.g., api, web-client, worker).
     • Image — The Docker image to deploy (e.g., registry.ironsled.com/project/api:latest).
     • Port — The port the container exposes.
     • Entry Point — Mark one container as the entry point — this is the container that receives external traffic through the ingress.
   • Networking Requirements (optional) — Describe any special networking needs such as subnets, firewall rules, or VPN access.
   • Priority — Set the urgency of the request: Low, Medium, or High.
   • Additional Notes (optional) — Any other context or requirements for the platform team.
4. Click Submit Request.

If the project already has environments with containers configured, the form offers a Use Existing shortcut that pre-fills the container list from the project's current deployments. This saves time when requesting a new environment that mirrors an existing one.

The request is routed to the platform team through the resource request system. The team is notified when the request is submitted, and the requesting team member receives updates as the request progresses through review and provisioning.

For non-development environments, all modifications go through a formal change request process. When a non-development environment is selected, the Request Change button becomes available.

1. Click Request Change. A side panel opens with the change request form.
2. Fill out the request:
   • Change Type — Select the category of change:
     • Deployment — Deploying a new version or updating an existing deployment.
     • Configuration Change — Modifying environment variables, settings, or configuration maps.
     • Infrastructure Change — Changes to the underlying infrastructure such as scaling, networking, or storage.
   • Description — Describe the change in detail. A minimum of 20 characters is required.
   • Risk Level — Assess the risk: Low, Medium, or High.
   • Rollback Plan — Describe how the change will be reverted if something goes wrong. This field is required.
   • Affected Services (optional) — If the environment has multiple containers, select which services will be impacted by the change.
   • Preferred Schedule (optional) — Specify a preferred date and time for the change to be applied.
3. Click Submit Change Request.

The platform team reviews the change request and coordinates the implementation. Development environments are excluded from this process — teams can deploy directly to development without platform team approval.

To remove an environment from the project:

1. Select the environment using the tab pills.
2. Click the Delete button (requires Platform Manager permission).
3. Confirm the removal. The confirmation shows the cluster, namespace, and display name for verification.

This removes the environment from IronSled only. Nothing is changed in Rancher or Kubernetes.

Each environment displays a summary panel with:

• Environment type — Shown as a colored badge (Production in red, Staging in orange, QA/UAT in blue, Development and Other in neutral tones).
• Cluster and namespace — The Rancher cluster and Kubernetes namespace the environment points to.
• Deployment count — How many workloads (Deployments, StatefulSets, DaemonSets) are running.
• Pod count — Total number of pods across all workloads.
• Security summary — Runtime vulnerability status for the environment.

Dashboard Inclusion

The Include in Dashboard toggle controls whether an environment's metrics feed into the project dashboard. When enabled, the environment's pod health, runtime vulnerabilities, and uptime contribute to the project's overall KPIs. When disabled, the environment is still visible in the Environments section but does not affect the dashboard scores.

This is useful for excluding development or experimental environments that would skew the project's health metrics.

The Deployments section lists every workload running in the namespace. This includes Kubernetes Deployments, StatefulSets, and DaemonSets.

For each workload, the view shows:

Workload States

Kubernetes batch Jobs in the namespace are listed separately from long-running workloads.

For each job, the view shows:

The Ingresses section shows the network routing rules configured for the namespace.

For each ingress:

• Ingress name — Clickable to open in Rancher.
• Ingress class — The ingress controller handling the rules (e.g., nginx).
• Load balancer — The IP address or hostname assigned by the cloud provider.
• TLS status — Whether TLS is configured for the ingress.

Each ingress lists its routing rules:

IronSled integrates with the Trivy Operator, which runs inside each Kubernetes cluster and continuously scans running container images for known vulnerabilities. Unlike pipeline scanning (which checks images at build time), runtime scanning checks what is actually deployed and running.

Security Summary

Each environment shows a security summary with:

• Overall status — A shield icon indicating the highest severity found:
  • Critical — Red shield. Vulnerabilities requiring immediate attention.
  • High — Orange shield. Serious vulnerabilities that should be prioritized.
  • Medium — Yellow shield.
  • Low — Gray shield.
  • Passed — Green shield. No vulnerabilities detected across all scanned resources.
  • Not Scanned — The Trivy Operator has not produced reports for this namespace.
• Vulnerability counts — Total count for each severity level (Critical, High, Medium, Low).
• Resources scanned — How many workloads the Trivy Operator has scanned.
• Last scanned — When the most recent scan completed.

Project-Level Security Rollup

At the top of the Environments section, a project security summary aggregates vulnerability data across all environments. This gives project owners a single view of their runtime security posture.

The rollup shows the same severity breakdown but across every environment, with a note showing how many environments and resources were included.

Viewing the Full Report

Click View Details on the security summary to open the full vulnerability report. The report dialog shows:

• Summary header — Total counts by severity across all environments.
• Per-environment breakdown — An accordion section for each environment with its own vulnerability table.

The vulnerability table includes:

Downloading a Security Report

Click Download Report to export the vulnerability data as a CSV file. The export includes all vulnerability details across all environments — useful for compliance reporting and security review meetings.

Vulnerability Tracking

IronSled tracks the lifecycle of each vulnerability over time:

This tracking is maintained in the database, recording when each vulnerability was first detected, last seen, and how many times it has been reintroduced.

When an environment has Include in Dashboard enabled, its data contributes to three project dashboard KPIs:

• Pod Health — The ratio of healthy pods to total pods across all dashboard-included environments.
• Runtime Vulnerabilities — Aggregated vulnerability counts from the Trivy Operator across all dashboard-included environments, with a breakdown by severity.
• Uptime — The minimum uptime percentage across production environments over a rolling 30-day window.

Environments excluded from the dashboard are still fully functional — they just do not affect the project's overall health score.

Several elements link directly to Rancher for deeper investigation:

• Workload names — Open the deployment, statefulset, or daemonset in the Rancher dashboard.
• Job names — Open the job in Rancher.
• Ingress names — Open the ingress configuration in Rancher.
• Ingress URLs — Open the URL in a new browser tab.
• Vulnerability reports — Open the Trivy report in Rancher.

All external links open in a new browser tab.