The EIM key that died on a Saturday

It's Saturday at 03:14. PagerDuty wakes you up. Production is fine, but the nightly backup pipeline failed at midnight. You log in, check the logs, and find this:

OperationNotPermitted: invalid access key id

The EIM key your backup automation uses expired at 00:00. Nobody knew. Nobody could have known — Outscale doesn't email a warning, doesn't show a banner, doesn't anything. The key just stops working.

This is the silent-expiration problem, and every Outscale account has it.

How EIM keys actually behave

Every Outscale account has EIM users (formerly IAM), each with one or more access key pairs. Those keys are what your CLI, Terraform, Airflow DAGs, monitoring agents, and anything that isn't a human use to talk to the API.

Outscale ages keys out. The default lifetime depends on account configuration but is typically 90 days. After that the key is rejected — no warning, no email, nothing visible in the Cockpit console unless you go looking. You'll have between five and fifty of these keys depending on how mature your platform is. Each expires on a different day.

What breaks when a key expires

Damage scales with how unattended the thing is:

• Interactive CLI usage — you notice immediately. Five minutes lost.
• CI/CD pipelines — next deploy fails. You notice within hours. A morning lost.
• Scheduled automation (backups, snapshots, scaling) — fails silently. You notice when something downstream breaks. Days.
• Cost data ingestion — dashboards stop updating but still load. You notice on Monday morning. A week.
• Compliance evidence collection — you find out when an auditor asks where the last 30 days of logs are.

The pattern: the more important the automation, the longer it takes to notice it died. Production-critical things tend to be unattended; unattended things break silently; silent breakage compounds.

The 30-day warning rule

The fix is conceptually simple. Every key in your account triggers an alert at T-30 days before expiration, a follow-up at T-7, and a final at T-0 if the key is still in use.

30 days is the right outer bound because rotating a key for non-trivial automation involves: regenerating, getting it into your secrets manager, redeploying anything that consumed it from there, verifying the rollover, and revoking the old key. One-week project on a good week, longer if Bob who owns the airflow DAG is on vacation.

7 days is panic mode. If you haven't started by then, today is mandatory.

T-0 is the "did anyone actually do this" check. The earlier alerts may have been dismissed, lost in Slack, or sent to a channel nobody watches. The day-of alert is your last chance.

Per-key, not per-account

The temptation is to write one alert: "any key on this account expiring soon." This is wrong. You'll get hit with one notification listing five keys, four of which were already replaced last week. You acknowledge, ignore, and miss the one that actually matters.

Per-key alerts are noisier but actionable. Each alert is one item: rotate this specific key by this date. You dismiss the ones already handled and the dashboard reflects truth.

Rotation cadence: don't wait for the alert

The alerting system above protects you from forgetting. If you find yourself getting alerts every week, the cadence is too tight. Two opposing pressures:

• Shorter lifetimes reduce the blast radius if a key leaks. 90 days is default; some teams force 30.
• Longer lifetimes reduce rotation overhead. Some teams stretch to 180 or 365 where their security policy permits.

The right answer depends on what the key has access to. A read-only key for cost data ingestion can live longer than a key with admin rights. A key used by a CI runner can rotate weekly with automation; a key buried in a third-party SaaS integration probably can't rotate at all without coordination.

Pragmatic rule: scope keys narrowly so you can rotate aggressively. A key with one permission used by one service is much safer to rotate (and much less impactful when it expires) than one über-key everything uses.

The audit angle

Beyond keeping things working, key expiration is a compliance signal. SOC 2, ISO 27001, and SecNumCloud all care about credential rotation. "We rotate keys every 90 days because Outscale forces us to" is technically a policy, but a weak one. "We rotate keys every 60 days, alerted at T-30 with documented owners per key" is much stronger.

Vextnd's audit log captures every key creation, rotation, and revocation, with the actor and the reason. When the auditor asks "show me the last six months of credential lifecycle," the answer is one click.

If you only do one thing

Set up T-30 alerts on every EIM key on every account, today. You don't need rotation automation, you don't need a fancy secrets manager, you don't need a policy doc. Just an alert that fires before the thing dies. Everything else flows from that.