fleetctl, CI harnesses, dashboards, external services — talks to the Fleet Manager API through one auth model: OAuth 2.0 client-credentials with short-lived bearer tokens. Identity is proven one of two ways: FM’s own agents and SDK consumers sign a JWT with a private key whose certificate chain is trusted by the API; external services hold a plain client secret instead.
Three kinds of clients
The token endpoint is the same for all of them, but the credential and the setup workflow differ. Pick the row that matches what you’re building:
If your client runs on your laptop, in CI, or in any cluster other than Fleet Manager’s own — you’re in the second or third row. The “agent” pattern in row 1 is a specific FM-internal code shape, not a generic word for “API client.”
Glossary (the words this section uses without defining them)
- Hub cluster — the central Kubernetes cluster that runs the Fleet Manager API and hub-side agents (e.g.
netbox-agent). - Satellite cluster — a per-site Kubernetes cluster that runs site-local agents (
workflow-agent,openstack-agent,slurm-agent). Each site has its own. cert-manager— the in-cluster controller that issues and rotates leaf certificates from a configured CA. In Fleet Manager, every agent pod gets its leaf cert this way.
Environments
The 1Password vaults hold the root CA that signs agent certs. Per-client credentials, where they exist, live as separate items in the same vault (convention:
<client-name>-creds, with cert and key fields) — see Client Authentication → External clients for the canonical pattern.
The two deeper pages
- Client Authentication — which of the two credential mechanisms applies to you, how
ensureagentclientregisters a client, where the cert comes from in each environment, and the concrete recipes for external clients and external services. Ties into the PKI tree at PKI and Certificate Trust. - Scopes and Permissions — the
resource:actiongrammar, how endpoints derive their required scope automatically, and what to update when you add a new model.