> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Fastly

> Connect Fastly to Oleria to discover the users, pending invitations, IAM roles, API tokens, and keys in your Fastly account, and the account audit log.

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:**

  | Identity | Shown as |
  | :- | :- |
  | Automation tokens | API token, with its roles, scope, service restrictions, expiry, last use, and the user who created it |
  | User API tokens | Personal access token, linked to the user it belongs to and acts as, with its scope, service restrictions, expiry, and last use |
  | The legacy **Global API Token** user, from Fastly's pre-2017 API keys | Service account. Its tokens appear as API tokens. |
  | Object Storage access keys | Access key, with its permission and bucket restrictions |
  | AI Runtime Control virtual keys | API token, with its provider, model, expiry, last use, and the user who created it |

  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](/integrations/overview#sync-model).

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

## Create API tokens in Fastly

<Steps>
  <Step title="Sign in as the dedicated user">
    Sign in to the Fastly control panel as the superuser Oleria will connect as.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Create the remediation token (optional)">
    To let Oleria take [remediation actions](#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.
  </Step>
</Steps>

| Token | Required | Scope | Used for |
| :- | :- | :- | :- |
| API token | Yes | `global:read` | Syncing users, invitations, roles, tokens, keys, and the audit log. Remediation actions also use it to check that they don't target this integration's own user or tokens. |
| API token for remediation actions | No | `global` | Remediation actions. The activity sync also reads this token's ID, so that events made with it are marked as Oleria activity. |

<Note>
  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.
</Note>

## Connect Fastly to Oleria

<Steps>
  <Step title="Open the integration">
    Go to your Oleria workspace, select **Integrations** -> select **Fastly**.
  </Step>

  <Step title="Complete the connection form">
    Provide the following:

    | Field | Notes |
    | :- | :- |
    | API token | Required. The read token you created above. |
    | API token for remediation actions | Optional. The remediation token you created above. |
  </Step>

  <Step title="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.
  </Step>
</Steps>

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](#create-api-tokens-in-fastly). Otherwise, try again.

<Note>
  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.
</Note>

## 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:

| Action | What it does | Revert |
| :- | :- | :- |
| Add user to role | Adds a Fastly IAM role to the user's roles. | Supported - restores the user's previous roles. |
| Remove user from role | Removes a Fastly IAM role from the user's roles. | Supported - restores the user's previous roles. |
| Disable NHI | Revokes a user API token or automation token, or deletes an Object Storage access key or AI Runtime Control key. | Not supported. |
| Revoke user sessions | Revokes every API token and control-panel session the user holds. Automation tokens the user created aren't revoked. | Not supported. |
| Delete user | Deletes the user from the Fastly account. | Not supported. |
| Create user | Sends a Fastly invitation to the email address, granting the Fastly IAM roles listed by ID in the request's `groups` field. The person becomes a user when they accept it. | Supported - deletes the invitation while it's still pending. |

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.

| Identity | Disable NHI supported |
| :- | :- |
| User API token (personal access token) | Yes |
| Automation token | Yes |
| AI Runtime Control virtual key | Yes |
| Object Storage access key | Yes |
| Tokens of the legacy **Global API Token** user | Yes |
| The legacy **Global API Token** user | No. Use **Revoke user sessions** on the user, or **Disable NHI** on each of its tokens, instead. |

<Warning>
  **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.
</Warning>

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](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.