Worker Enrollment and Short-lived Identity

1. The real problem: bootstrap possession is not worker identity

Possessing a bootstrap token, hostname, or initial secret only shows that a process obtained some material. It does not prove that the current process is the authorized worker on the intended node or that it should retain authority indefinitely. This lesson produces Worker Enrollment Credential & Rotation Ledger v1: a record that converts bounded bootstrap evidence into one-time enrollment, traceable attestation, a distinct worker identity, an explicit generation, and a short-lived credential. A past success never makes bootstrap authority permanent.

2. LOC-009 owns the enrollment boundary

This lesson owns enrollment, bootstrap replay, node/workload attestation, selector evidence, worker ID, credential generation, not_before/not_after, trust material, rotation, and re-enrollment. Heartbeat and health belong to LOC-010; lease and work authority belong to LOC-011. A valid identity credential can authenticate a worker without proving that the node is healthy or that the worker currently owns a lease.

3. Enrollment is a transition, not secret copying

The bounded path is: bootstrap evidence → enrollment gate → node/workload attestation → identity assignment → short-lived credential → rotation or expiry. A bootstrap token must not become a permanent worker credential. The ledger records which bootstrap ID was used by which attempt, whether it was replayed, and which worker ID and credential generation were ultimately issued.

4. What the Workload API contributes as a reference

The SPIFFE Workload API is an official reference pattern for runtime workload identity delivery. It can deliver X.509-SVIDs and trust bundles and stream later updates when identity information changes. That supports the idea that identity material can be runtime-delivered and refreshed, but it does not define MAKNOW enrollment policy or concrete TTL values.

5. Registration entries and selector evidence

In SPIRE, a registration entry contains a SPIFFE ID, one or more selectors, and a parent ID. During workload attestation, observed selectors are compared with authorized registration entries. For MAKNOW, the key lesson is that identity assignment must bind to observable evidence and its provenance; a hostname or display name alone is not sufficient unless an explicit local policy says it is.

6. Node binding must be explicit

An enrollment attempt records claimed node identity, expected node identity, and the attestation source. If bootstrap evidence was issued for node A but replayed from node B, the outcome cannot be “success because the secret matched.” The attempt is denied and the audit record names replay or wrong-node binding as the reason.

7. Worker identity is separate from human identity

A human login token, session cookie, or refresh token must not become the worker credential. Human and workload identities have different lifetimes, privileges, and revocation paths. Enrollment creates an independent worker ID and credential generation so reinstall, ownership change, compromise, and re-enrollment can be handled without borrowing a human session.

8. Short-lived credentials require an explicit validity window

At minimum retain issued_at, not_before, and not_after. Before not_before, the credential is not yet valid; after not_after, it remains expired. Clock policy and skew allowance are deployment choices; this lesson invents no universal number. Extending an expiry timestamp locally without valid issuance or rotation would fabricate evidence.

9. Rotation advances the credential generation

A successful rotation should create a new credential generation. An older connection presenting the previous generation is acceptable only under an explicit, bounded overlap policy that is still in force. Without such a policy, the old generation is STALE_GENERATION. The ledger records which generation authorized the request.

10. Selector mismatch requires re-enrollment

If a decisive selector changes—for example process identity, executable digest, container namespace/service account, or equivalent evidence—the system must not preserve the claimed worker binding by ignoring the mismatch. The bounded result is RE_ENROLL or DENIED until policy establishes a new binding. This is an identity-binding issue, not a health issue.

11. Replay detection is part of the contract

One-time bootstrap evidence needs consumption and replay semantics. If the same bootstrap ID is presented again, even from the same node, the system should not silently enroll again. The result stays typed and names the trigger for issuing new bootstrap evidence or reviewing a possible incident. Replay resistance is a lifecycle property, not merely a long random secret.

12. Trust material and source provenance remain visible

The ledger records which trust bundle/version or trust-domain context was used and which attestation source produced the selector evidence. Trust material can rotate as well. Possessing a certificate without provenance is insufficient; a reviewer should be able to reconstruct under which material and policy the identity was considered valid.

13. Decisions fail closed and remain proportional to evidence

ENROLLED or ACCEPT_BOUNDED is allowed only when bootstrap evidence is acceptable, node/selector binding matches, the credential is inside its validity window, and the generation is allowed by current policy. Replay, wrong-node, expiry, not-yet-valid, selector mismatch, and stale generation keep their own non-success states. A score or “it worked before” cannot average these failures away.

14. Decisive failure probes

Break four shortcuts: (1) replay the same bootstrap token on a different node; (2) advance time beyond not_after without successful rotation; (3) change an attested selector while keeping the claimed worker ID; (4) issue a new generation while an old connection still presents the prior one. Each probe must produce a reproducible Decision, Reason, and Re-enrollment Trigger; the learner lab does not expose final labels.

15. Transfer from Unix selectors to container attestation

The transfer materially changes the evidence topology: instead of a Unix process selector, a containerized worker is evaluated through namespace/service-account or image-related evidence. Worker identity, generation, validity window, rotation, replay rules, and fail-closed behavior remain stable. Because the evidence mechanism changed, the decision must be recomputed rather than copied from the baseline.