Lesson 22.1322.13 Keys that expire, and no keys at all

Part D. Safe to sell: keys, refresh, schedules and loops. Half 2, Milestone 2. Read this half before you sell a worker to a client. First 22.13 and Sitting 3b, which proves the isolation and deploys with no stored key. Then 22.14 to 22.16 and Sitting 4.

In everyday life. An office gives its owner a permanent key, which works until the lock is changed. A delivery driver gets no key at all. Each morning he shows his company badge at reception and gets a visitor pass that stops working at 6 p.m. If he loses the pass, it is useless by evening. If the owner loses the key, someone must notice and change the lock. In this concept, the permanent key is a stored API key, and the visitor pass is a short-lived token from workload identity.

What you will learn. The three ways a program can prove who it is to the platform, why a key that never ends is a risk, and how a program can avoid storing a key at all.

Why it matters. A stored key that leaks keeps working for whoever holds it. Each key you give an end date, or remove altogether, is one less secret to lose.

One request, start to finish. Two programs need to talk to the hosted platform. The deploy workflow in CI applies the agent files on every merge (22.4). The portal's server starts sessions all day. The builder works out how each should prove who it is.

1. CI already has an identity. Each run of a CI job can ask its own CI system for a short-lived signed token that says "this is the agents.yml workflow, in this repository, on the main branch".
2. CI sends that token to the platform and gets back a platform token that lasts one hour. It applies the files, and the token expires.
3. No key is stored in CI at all.
4. The portal's server has no such identity on the host the lab uses for it. So it holds a stored key, kept as a secret on the server, limited to one workspace, with a spending limit, and set to expire after 90 days.

Two programs, two answers, each the safest one available.

How can a program prove who it is?

There are three ways for a program to prove who it is:

• A static key is a long secret string, made once and stored by the program, like the API keys you made in Lab 20 (20.13). It works until someone deletes it, or until it expires. Because it lasts, it must be stored safely, changed on a schedule (key rotation), and given an end date where the platform allows one (key expiry). A leaked key without an end date works for the attacker until someone notices.

• A service account is an identity for a program, not a person. Keys and tokens can belong to it, so they do not stop working when a person leaves, and its rights can be narrower than any person's.

• Workload identity replaces the stored key altogether. It works in three steps, the same three as in the CI story above:

  1. The program asks the system it runs on, such as a CI system, for a short-lived signed token that names the program.
  2. It sends that token to the platform. The platform checks it against a rule set up in advance: "tokens for this repository's main branch may act as this service account".
  3. The platform returns its own short-lived token. The program uses it, and it expires.

  Nothing is stored. For reference: the system that issues the first token is an identity provider, the token is a JWT (Chapter 18), which follows OpenID Connect, and swapping it uses the JWT bearer grant of RFC 7523.

Why do CI and the portal differ?

Workload identity needs an identity provider the platform trusts. CI has one. The portal's server, on the host the lab uses, has none that the platform's documents describe. So the portal uses the next safest thing: a key linked to a service account, that works in one workspace only, has a spending limit, expires on a date, and is rotated by a written step before it does. F6 has that step.

At work. In Lab 22, Task 13, Claude Code sets up workload identity for the CI workflow, with a rule that accepts only the main branch of this repository. It removes the platform key from the repository's secrets, opens a pull request, and shows the builder its checks passing with no key and no platform token. After the merge, the merge job plans and applies, and the platform's record of the token exchange names the service account, not a person.

The operating rule: use workload identity wherever you can. Where a key remains, give it to a service account, one workspace, a spending cap and an end date.

Figure 22.19. A stored key against an exchanged token. Where a program can prove what it is, store nothing.

22.13 in one minute

A stored key works until someone changes it, so give the portal's key an owner, a cap and an end date. Where a system can prove who it is, as CI can, use a short-lived token instead, and store no key at all.

Now do Lab 22, Sitting 3b on the lab page: Tasks 12, 12b and 13 (about 2 hours 15 minutes). Then come back for 22.14.