Skip to main content
Connect Fastly to Oleria to see who and what can act on your Fastly account: its users and pending invitations, the Fastly roles they hold, the API tokens and keys that act on their behalf, and what they do with that access. Oleria reads this data with a Fastly user API token. You can add a second token to let Oleria change a user’s roles, revoke tokens and keys, invite users, and delete users.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Fastly account:
  • Users - every user in the account, with name, login email, creation date, and last activity. Oleria takes last activity from Fastly’s own last-active time and from the latest use of the user’s personal API tokens and control-panel sessions. Automation tokens the user created don’t count. Users with the superuser or user_admin role, and the account owner, are marked as administrators. Every user has API access, because any Fastly user can create personal API tokens.
  • MFA and SSO - when your account enforces SSO, users other than superusers show SSO as their only sign-in method, SSO as required, and MFA as unavailable, because your identity provider handles MFA. Superusers show SSO as configured, because Fastly still lets them sign in with a password. Every other user shows password sign-in, plus two-factor authentication when they have it turned on. For those users, MFA shows as required when they have two-factor authentication turned on, as awaiting enrollment when your account or the user requires it but the user hasn’t set it up, and as not required otherwise.
  • Pending invitations - each open invitation appears as a disabled account with the invited email address and the role it grants.
  • Roles - Fastly’s IAM roles, such as superuser, engineer, and billing, with each role’s description and permissions, and which users and automation tokens hold each role.
  • Fastly Support - a single synthesized Fastly Support (synthesized) administrator account. Fastly staff have standing access to customer accounts but never appear in the user list. Oleria shows this account so that access is visible.
  • Non-human identities: Each token and key also appears as a credential. A user or automation token whose only scope is global, with access to all services, has the full authority of its user or roles. So does an Object Storage key with the read-write-admin permission and no bucket restrictions. Other tokens and keys are shown with their scopes, services, or buckets as restrictions. Tokens with no scope, keys with no permission, and AI Runtime Control keys, which have no scope model, show their authority as unavailable.
  • Activity - events from the Fastly account event log (audit log):
    • sign-ins, failed sign-ins, and sign-outs;
    • users created, updated, deleted, locked, or unlocked, and role changes;
    • password changes, and two-factor authentication turned on or off;
    • API tokens created and deleted;
    • invitations sent and accepted;
    • SSO configuration and account settings changes.
    Oleria keeps every other event too, such as service and configuration changes, under its Fastly event name. Events made by Fastly staff are attributed to the Fastly Support account. An event made with an automation token or AI Runtime Control key is attributed to that token, and an event made with a user API token is attributed to the token, acting as its user, as long as the token still exists when Oleria syncs. Events from control-panel sessions, and from tokens deleted before the sync, are attributed to the user. Events made with this integration’s own tokens are marked as Oleria activity.
Oleria refreshes this data on its regular sync schedule.
This integration covers identities, roles, and activity. It doesn’t inventory Fastly services, configurations, Next-Gen WAF workspaces, or Object Storage buckets, so Oleria doesn’t populate resource-level Access Graph or Access Inventory data for Fastly.

​
Prerequisites

  • A Fastly user with the Superuser role for Oleria to connect as. Only a superuser can see every user’s tokens and the full audit log.
  • Admin access on the Oleria platform to add a new integration.
Use a dedicated Fastly user invited for Oleria instead of a named person’s account. The tokens belong to the user who creates them, and Fastly requires a user’s tokens to be deleted before that user can be deleted. Fastly tokens can also expire, so note each token’s expiration date and replace it in Oleria before it expires.

​
Create API tokens in Fastly

1

Sign in as the dedicated user

Sign in to the Fastly control panel as the superuser Oleria will connect as.
2

Create the read token

Go to Account > API tokens > Personal tokens, select Create token, re-enter your password if prompted, and create a token with:
  • Type set to User token;
  • the global:read scope;
  • access to all services;
  • an expiration date that suits your rotation policy. Fastly sets new tokens to expire after 90 days by default.
Copy the token. Fastly shows it only once.
3

Create the remediation token (optional)

To let Oleria take remediation actions, create a second user token the same way, with the global scope instead of global:read. Copy the token. Fastly shows it only once.
Both tokens must be user API tokens. Don’t set Type to Automation token: Fastly doesn’t let an automation token hold the Superuser role, so it can’t list every user’s tokens, read the full audit log, or change other users’ roles, and Oleria rejects any token that doesn’t belong to a superuser. Oleria expects global:read to be enough for the read token. If Fastly refuses one of its reads with a permission error, you can use a global token as the read token instead.

​
Connect Fastly to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Fastly.
2

Complete the connection form

Provide the following:
3

Confirm the connection

Select Authenticate. Before it saves anything, Oleria checks that:
  • each token has the right scope and access to all services;
  • each token belongs to a superuser;
  • both tokens belong to the same Fastly account;
  • the read token can list users, API tokens, automation tokens, and audit events.
Find the newly connected Fastly account on the Connected tab of your Oleria Integrations page.
If Authenticate, or Update when you edit the integration, fails, the message says what’s wrong. Most messages name the token by its field key: apiToken is API token, and writeApiToken is API token for remediation actions.
  • Fastly rejected the token - Fastly didn’t accept the token, or couldn’t be reached. Check that the token isn’t mistyped, revoked, or expired, and create a new one if it is. If the message shows a rate-limit or server error, try again later.
  • Must be the Fastly API token itself - paste the token value into the field.
  • Wrong scope - create a token with global:read for the read token, or global for the remediation token.
  • Limited to specific services - create the token with access to all services.
  • Reading the user behind the token, or checking the role behind the token - Fastly returned an error when Oleria read the token’s user or Fastly’s IAM roles. The message includes Fastly’s error. Try again.
  • Not a superuser - create the token as a user with the Superuser role.
  • Different Fastly account - create both tokens in the same Fastly account, or, when you edit the integration, in the account it’s connected to.
  • The read token cannot read an endpoint - the message names the endpoint and Fastly’s error. If Fastly returned a permission error, see the note on the read token’s scope under Create API tokens in Fastly. Otherwise, try again.
When you edit the integration, leave a token field blank to keep the stored token. To remove the stored remediation token, select Remove the stored API token for remediation actions and leave API token for remediation actions blank. Remediation actions are then unavailable. New tokens must belong to the same Fastly account the integration is connected to. To connect a different Fastly account, add a new integration.

​
Verify the integration

Confirm the Fastly account appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, review the discovered users, invitations, roles, tokens, keys, and activity in your Oleria workspace.

​
Remediation actions

When you add the API token for remediation actions, Oleria can take these actions in Fastly: Every action needs the remediation token to belong to a user with the Superuser role, to have the global scope, and to have access to all services. Before it offers an action, Oleria checks all three. Without the remediation token, Oleria reports that the token isn’t configured. Actions also need a valid read token, because Oleria uses it to check that an action doesn’t target this integration’s own user or tokens.
Disable NHI, Revoke user sessions, and Delete user can’t be undone. Fastly can’t restore a revoked token or deleted key, so anything that uses it stops working immediately. A deleted user can only be invited again, and gets a new Fastly user ID. Before you run one of these actions, confirm the credentials are unused or plan their replacement.
Keep these limits in mind when you use these actions:
  • Oleria reads the user before it changes roles. If the user already has, or doesn’t have, the role, Oleria makes no change, and reverting the action makes no change either.
  • After a change, Oleria reads the user, token, or key again to confirm it, even if the action ran out of time. If Fastly accepted the change but the user’s roles don’t match, or the token or key is still listed, Oleria reports the action as failed. If Fastly returned an error, or the action ran out of time, but the change shows when Oleria reads it again, the action succeeds, and a role action can be reverted.
  • If Oleria can’t confirm a role action’s outcome, the action fails. Oleria keeps the user’s previous and requested roles, but a failed action can’t be reverted on its own, so check the user’s roles in Fastly and restore them there if needed. If other users in the same workflow succeeded, reverting the workflow also restores this user, but only if their roles match what the action requested.
  • Reverting a role action restores the roles the user had before the action, but only if the user’s roles still match what the action set. If the user still has their previous roles, the revert makes no change. If someone changed them in between, Oleria restores nothing and reports that the roles changed.
  • Oleria refuses to add roles to or remove roles from the Fastly users behind this integration’s tokens, to remove the Superuser role from the account owner, or to remove a user’s last role. If Fastly refuses a combination of roles, the action fails and nothing changes.
  • Role actions apply to Fastly users and Fastly’s IAM roles only. Pending invitations, tokens, keys, and the Fastly Support account can’t be changed, so an automation token’s roles appear in Oleria but can’t be changed from it.
  • Disable NHI refuses to revoke this integration’s own read or remediation token, and refuses to revoke control-panel sessions. To end a user’s control-panel sessions, use Revoke user sessions.
  • If the token or key is already revoked or gone, Disable NHI fails with an already-revoked or not-found error instead of reporting success.
  • Revoke user sessions and Delete user refuse the Fastly users behind this integration’s tokens and the account owner. Transfer ownership in Fastly first if you need to remove the owner. A user that belongs to another Fastly account is reported as not found. Delete user also refuses to delete the last active user with the Superuser role, not counting the users behind this integration’s tokens or the legacy Global API Token user.
  • Revoke user sessions revokes each token separately and reads it again to confirm. If some tokens are revoked and others aren’t, the action fails and lists both. If the user has no tokens, it succeeds without a change. If the action runs out of time, or Fastly rate-limits it, a token Fastly already revoked is still reported as revoked, and the tokens Oleria didn’t reach are reported as not revoked. Run the action again to revoke the rest.
  • If Fastly refuses Delete user because the user still has API tokens, run Revoke user sessions first, then delete the user. If the user is already deleted, Delete user fails with a not-found error instead of reporting success.
  • Create user needs at least one Fastly IAM role ID in groups, and Oleria never picks one for you. The Superuser and User admin roles are granted only when they’re listed, and Oleria flags the action as a privilege escalation. Oleria still requires a first name, last name, and username, but doesn’t send them or the password to Fastly, because the person sets them when they accept the invitation. Oleria refuses to invite an email address that already belongs to a user or has a pending invitation.
  • If Fastly’s reply to Create user is lost, or is an error that doesn’t rule out the invitation being sent, Oleria looks for the one new pending invitation for that email address. If it finds it, the action succeeds and can be reverted. Otherwise the action fails and Oleria won’t revert it. Check pending invitations in Fastly before you retry.
  • Reverting Create user deletes only the invitation that action sent. If the person already accepted it, the revert fails and the user stays. Use Delete user to remove them. If the invitation expired or was deleted, the revert makes no change.

​
Known limitations

  • No user groups. Fastly’s user groups API is undocumented, so Oleria doesn’t read user groups or their members.
  • No service-level access. Because services aren’t inventoried, per-service permissions and users limited to specific services aren’t shown as access to individual services. A token’s service restrictions appear in its scope, and a role held by a user limited to specific services is marked as limited.
  • No user disable. Fastly has no deactivated state, so Fastly users show as enabled unless Fastly reports them as deleted. A locked user also stays enabled, and locks and unlocks appear in activity as account updates. Oleria can’t disable or re-enable users. To remove a user’s access, run Revoke user sessions and then Delete user. Neither can be undone.
  • No last password change or license level. Fastly doesn’t report when a user last changed their password, and licensing is per account. Password changes appear as activity.
  • SSO and MFA exemptions aren’t visible. Fastly’s per-user Bypass SSO and two-factor exemptions are set only in the control panel. When your account doesn’t enforce SSO, Oleria can’t read your SSO configuration, so SSO shows as unavailable.
  • Optional sources. Pending invitations, Object Storage access keys, and AI Runtime Control keys appear only when Fastly lets the read token list them, and the keys only when those products are enabled. Otherwise, Oleria skips them and the rest of the sync continues. Fastly doesn’t report who created an Object Storage access key or when it was last used.
  • Control-panel sessions aren’t non-human identities. Fastly lists control-panel sessions alongside API tokens. Oleria doesn’t show them as tokens.
  • No Next-Gen WAF agent keys or AI agents. Next-Gen WAF agent keys belong to workspaces, which aren’t inventoried. Fastly has no API that lists AI agents. AI Runtime Control keys appear as non-human identities.
  • Legacy roles when IAM roles are unreadable. If Fastly’s IAM roles API refuses the read, Oleria shows each user’s legacy Fastly role, such as engineer, as a role instead. Add user to role, Remove user from role, and Create user need the IAM roles API, and fail with a missing-permission error without it.
  • Affected objects for some events. Sign-ins, failed sign-ins, sign-outs, SSO configuration, and account settings events are linked to the Fastly account. Password changes are linked to the user who made them, and two-factor events to the user the details name, or else to the user who made the change. Other user, token, and invitation events are linked to what they changed only when the event’s details name a user, token, or invitation that Oleria discovered. Events about services and their configuration have no affected object, and Oleria drops their details. Oleria keeps the details of identity, SSO, and account settings events, with secret-like fields removed, unless they’re larger than 4 KB.
  • Fastly API addresses only. Oleria connects only to api.fastly.com.

​
Contact us

For questions about this integration, contact us at support@oleria.com.