Buddy uses a Datadog service access token owned by a service account. This is preferable to an application key for this non-interactive use case: it is scoped by default, can expire, does not belong to an employee, and does not require a separate API key.
The shared token is stored in the Rust Foundation 1Password Infrastructure
vault as an item named datadog-read-only, in a field named
credential. Buddy reads it using the fixed secret reference
op://Infrastructure/datadog-read-only/credential.
Sign in to the 1Password CLI on the host, then configure and verify the guest:
just login-datadogLogin verifies that the token matches the documented snapshot.
Datadog permissions are documented in the permissions snapshot.
Login performs this assertion automatically. To repeat it without reinstalling the token, run:
just assert-datadog-credentialsTo refresh the snapshot, run:
just dump-datadog-permissionsDo not create a token during normal setup because the token already exists. Create a new token from scratch only when the old one has expired:
- Open Datadog Organization Settings > Service Accounts.
- Open the existing
Read onlyservice account. It uses thesafe-readonlyrole, which is the permission boundary for its tokens. - Under Access Tokens, if a token name
buddyexists, delete it. - Select New Token.
- Name the token
buddy, choose an expiration date, and select Select Scopes. Select Select all Read, save the scopes, and create the token. Selecting every read-only token scope is safe here because the service account'ssafe-readonlyrole has already limited the effective permissions. - Copy the token immediately. Datadog shows the secret only once.
- Replace
credentialin the 1Passworddatadog-read-onlyitem with the new token, which begins withddsat_. - Run
just login-datadog. This copies the replacement into the VM and verifies that its permissions match the checked-in snapshot. The snapshot should not change when the token is rotated.
Buddy uses a Fastly automation token. Unlike a user token, an automation token is
not tied to an employee's account lifecycle. The token has the User role,
the global:read scope, no TLS management access, and an expiration date.
The shared token is stored in the Rust Foundation 1Password Infrastructure
vault as an item named fastly-read-only, in a field named credential.
Buddy reads it using the fixed secret reference
op://Infrastructure/fastly-read-only/credential.
Sign in to the 1Password CLI on the host, then configure and verify the guest:
just login-fastlyThis exports the token through the Fastly CLI's supported
FASTLY_API_TOKEN environment variable. It also sets
FASTLY_DISABLE_AUTH_COMMAND=1 because Fastly authentication is managed
externally by Buddy rather than by a stored CLI profile.
Before copying the token into the VM, Buddy inspects its metadata through
Fastly's current-token API. Login fails unless the token has exactly the
global:read scope and an expiration date in the future. Buddy then verifies
the installed token with a read-only Fastly request.
Fastly global:read can't read Fastly Secret Store values.
However, it can read various things, such as VCL snippets, so only store secrets in the Secret Store.
Do not create a token during normal setup because the token already exists. Create a new token from scratch only when the old one has expired:
- Open Account > API tokens > Account tokens. If an automation token named
buddy-read-onlyexists, revoke it. - Open Account > API tokens > Personal tokens.
- Select Create token, name it
buddy-read-only, and choose the settings of the screenshot below. - Create and immediately copy the token. Fastly shows the secret only once.
- Replace
credentialin the 1Passwordfastly-read-onlyitem with the new token. - Run
just login-fastly. This copies the replacement into the VM and verifies it with a read-only Fastly request.
