checkId: check.environment.secrets plugin: stellaops.doctor.environment severity: warn tags: [environment, secrets, security, rotation, expiry]

Environment Secret Health

This stella doctor check surfaces secrets that are expired, expiring soon, or overdue for rotation across every managed environment, so operators can rotate credentials before they cause authentication outages or violate rotation policy.

What It Checks

Queries the Release Orchestrator secrets status API (/api/v1/environments/secrets/status) for metadata about all configured secrets (no actual secret values are retrieved). Each secret is evaluated for:

Severity is assigned by the first matching rule, in order:

Why It Matters

Expired secrets cause immediate authentication and authorization failures. Services that depend on expired credentials will fail to connect to databases, registries, external APIs, and other integrations. In production, this means outages. Secrets expiring within 7 days require urgent rotation to prevent imminent failures. Overdue rotation violates security policies and increases the blast radius of a credential compromise.

Common Causes

How to Fix

Neither stella env secrets … nor stella secrets provider status exists. Verified 2026-07-28 against the built CLI:

  • stella env secrets list --expiring exits 2 — Unrecognized command or argument 'env'. No env/environment command is registered at any depth. Tracked as CLI-2 in docs/implplan/SPRINT_20260727_003_Cli_release_environment_command_surface.md.
  • stella secrets … parses, which makes it more dangerous than a plain typo: cli-routes.json maps secrets → scan secrets as a hidden deprecated alias (“Secret detection consolidated under scan (not secret management)”). That is secret detection scanning. It has no provider status subcommand, and it is not the secret-management surface this article meant.

Earlier revisions published stella env secrets list|rotate|rotate-scheduled and stella secrets provider status as remediation steps. All were fabricated. There is no CLI surface for secret lifecycle management — rotation and expiry are driven from the Console and from your secret provider (Vault, Key Vault) directly. stella kms export|import moves file-backed signing key material and is unrelated; stella key rotate <anchorId> <oldKeyId> <newKeyId> rotates trust-anchor keys, also unrelated to environment secrets.

Docker Compose

# Report expiring/expired secrets (evidence block lists them)
stella doctor run --check check.environment.secrets --format json

# Update secret in .env file for compose deployments
# Edit devops/compose/.env with the new secret value
# Then restart affected services
docker compose -f docker-compose.stella-ops.yml restart <service>

Bare Metal / systemd

# Report expiring/expired secrets
stella doctor run --check check.environment.secrets --format json

# If using file-based secrets, update the file
sudo vi /etc/stellaops/secrets/<secret-name>
sudo chmod 600 /etc/stellaops/secrets/<secret-name>
sudo systemctl restart stellaops-<service>

Scheduled rotation is configured in your secret provider, not in the Stella Ops CLI.

Kubernetes / Helm

# Report expiring/expired secrets
stella doctor run --check check.environment.secrets --format json

# Rotate the secret in your provider, then update the Kubernetes secret
kubectl create secret generic <secret-name> \
  --from-literal=value=<new-value> \
  -n stellaops-<env> --dry-run=client -o yaml | kubectl apply -f -

# Restart pods to pick up new secret
kubectl rollout restart deployment/<service> -n stellaops-<env>

# For external-secrets-operator, trigger a refresh
kubectl annotate externalsecret <name> -n stellaops force-sync=$(date +%s)

Verification

stella doctor run --check check.environment.secrets