Managing Secrets
How to manage secrets for your application on IronSled. The Portal has no secrets-management screen — secrets are handled in GitLab CI/CD variables for pipelines and with Kubernetes Secrets and the External Secrets Operator for runtime. Includes where each type of secret belongs and links to the how-tos.
Applications on IronSled need secrets — database passwords, API keys, registry credentials, and the like. This page explains where those secrets live and how you manage them.
The IronSled Portal does not have a secrets-management screen. You cannot create, view, or rotate secret values in the Portal. Secrets are managed in GitLab and in your Kubernetes cluster, as described below.
The only place the Portal touches secrets is during project onboarding: when you declare a container's environment variables, you can mark a variable as a secret. The Portal masks that value (it shows [Secret] instead of the value) in the onboarding review, and the value is provisioned into the appropriate secret store — it is never displayed back in the Portal afterward.
Two kinds of secrets
| Where the secret is needed | Manage it in | Guide |
|---|---|---|
Build / CI pipelines (tokens and credentials your .gitlab-ci.yml needs) | GitLab CI/CD variables (masked and/or protected) | GitLab → Settings → CI/CD → Variables |
| Runtime (values your running pods read) | Kubernetes Secrets, ideally synced by the External Secrets Operator (ESO) | Kubernetes Secrets & ESO |
Pipeline secrets — GitLab CI/CD variables
Secrets that only your pipeline needs (for example, a registry token or a deploy credential) belong in GitLab CI/CD variables at the project or group level. Mark them masked so they don't print in job logs, and protected if they should only be available on protected branches and tags.
Runtime secrets — Kubernetes Secrets and the External Secrets Operator
Secrets that your running application consumes belong in the Kubernetes namespace where it runs. Rather than committing secret values into Git, IronSled uses the External Secrets Operator to pull values from an external secret store (such as AWS Secrets Manager) and materialize them as Kubernetes Secrets in your namespace. Your workloads then reference those Secrets as environment variables or mounted files.
- For Kubernetes Secret basics and safe handling, see Kubernetes Secrets.
- To wire up an
ExternalSecretand consume it, see the External Secrets Operator.
Rotating a secret
Because the Portal doesn't store secret values, rotation happens where the secret lives: update the GitLab CI/CD variable, or update the value in the external secret store and let the External Secrets Operator resync it into the namespace. After a runtime secret changes, restart the affected workloads so they pick up the new value — you can confirm they come back healthy in the project's Environments section.
Settings
Managing project identity — name, cost center, description, light and dark mode logos, and the danger zone for decommissioning and permanently deleting a project.
Deploy & Troubleshoot
How to deploy your application on IronSled and keep it healthy — how deployment works for code/build projects (GitOps with Fleet and Helm through CI/CD) and for upload projects (bring your own Helm chart, request an environment, and roll out in Rancher), how to watch running workloads, pods, ingress, and runtime security in the project Environments section, and how to troubleshoot by jumping into Rancher or debugging pods directly.