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

# Snyk

> Connect a Snyk Group to Oleria to discover its members, Organizations, roles, service accounts, and installed Snyk Apps, and to manage Group and Organization access from Oleria.

Connect Snyk to Oleria to see who can act on your Snyk Group and its Organizations, which roles they hold, and which service accounts and Snyk Apps have access. Oleria reads this from the Snyk API with a Group service account, so you can review developer-security access and take action directly from Oleria.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from one Snyk Group:

* **Accounts** - every member of the Group, with their name, email address, and username. Members with the **Group Admin** role, or the **Org Admin** role in any Organization, are marked as administrators. Members who sign in through your SSO connection are shown as SSO users, and those Snyk reports as inactive are imported as disabled. Pending Organization invitations are imported as disabled accounts.
* **Organizations** - every Organization in the Group, shown as a group, with its direct members and pending invitations.
* **Roles** - each member's Group role, and their role in each Organization. Organization roles are shown per Organization, for example **Org Admin (payments)**.
* **Non-human identities** - Group and Organization service accounts, each with its credential (API key, OAuth client secret, or public key) and the role it holds, and every Snyk App installed in the Group or one of its Organizations. A service account whose access token has expired is imported as disabled.
* **Activity** - administrative changes from the Group and Organization audit logs, such as membership, role, service account, and settings changes. Oleria also uses the audit log to set each account's last activity (see [Known limitations](#known-limitations)).

Oleria refreshes this data on its [regular sync schedule](/integrations/overview#sync-model).

<Note>
  Oleria doesn't import projects, targets, issues, scan results, or any other Snyk content. This integration covers identity and access governance for the Group and its Organizations only, so Oleria doesn't populate Access Inventory or resource-level Access Graph data for Snyk.
</Note>

## Prerequisites

* A Snyk **Enterprise** plan. Service accounts, Group-level APIs, and audit logs are Enterprise features.
* A Snyk **Group Admin**, to create the service account Oleria uses.
* Admin access to the Oleria workspace.

<Note>
  Use a Group service account rather than a personal token. Personal tokens expire and stop working when their owner leaves. Oleria accepts a personal token, but logs a warning.
</Note>

## Create a service account in Snyk

<Steps>
  <Step title="Find your Group ID and region">
    Sign in to Snyk, open your Group, and go to **Group settings**. Copy the **Group ID** shown under **General**. It's a UUID such as `0a1b2c3d-...`. Note your Snyk region from the address you sign in at: `app.snyk.io` is **SNYK-US-01**, `app.us.snyk.io` is **SNYK-US-02**, `app.eu.snyk.io` is **SNYK-EU-01**, and `app.au.snyk.io` is **SNYK-AU-01**.
  </Step>

  <Step title="Create the service account">
    In **Group settings** > **Service accounts**, create a service account for Oleria and give it the **Group Admin** role. Oleria's [remediation actions](#remediation-actions) need Group Admin. For read-only discovery you can instead use a custom Group role; see [Read-only permissions](#read-only-permissions).
  </Step>

  <Step title="Choose how the service account authenticates">
    Choose one:

    * **Service account token**: choose the API key or access token type, and copy the value Snyk shows once. An access token expires on the date you set, so plan to rotate it; Snyk recommends access tokens over API keys.
    * **OAuth client credentials**: choose the OAuth 2.0 client secret type, then copy the **client ID** and **client secret** Snyk shows.

    The OAuth 2.0 private key JWT type isn't supported.

    Store the values securely until you've connected Oleria.
  </Step>
</Steps>

<Note>
  The exact location of these settings can change over time. If the steps above don't match what you see, refer to Snyk's own documentation.
</Note>

### Read-only permissions

If you don't plan to use remediation actions, you can give the service account a custom Group role with these permissions:

* **Group**: View Groups, View Organizations, View Group Memberships, View users, Read Roles, View audit logs, View service accounts, View Apps, and View SSO settings.
* **Organization**: View Organization, View users, View Organization Memberships, View audit logs, View service accounts, and View Apps.

The **Group Viewer** role alone gives a partial sync. Oleria logs each permission it's missing and leaves the matching data out, rather than showing it as empty.

## Connect Snyk to Oleria

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

  <Step title="Complete the connection form">
    Select **Continue** and provide the following:

    | Field | Notes |
    | :- | :- |
    | Authentication method | **Service account token (recommended)** or **OAuth client credentials**. |
    | Region | Required. Your Snyk region, shown with the address you sign in at, for example **SNYK-EU-01 (app.eu.snyk.io)**. |
    | Group ID | Required. The Group ID from **Group settings**. |
    | API token | Required for **Service account token**. The service account's API key or access token. |
    | Client ID | Required for **OAuth client credentials**. |
    | Client secret | Required for **OAuth client credentials**. |
    | I authorize Oleria to perform write actions in Snyk | Optional. Select it to allow [remediation actions](#remediation-actions). Actions need the built-in **Group Admin** role; a custom role is refused even if it grants write permissions, so leave this unchecked when you use a read-only custom role. |
  </Step>

  <Step title="Confirm the connection">
    Select **Authenticate**. Oleria checks that the credential can read its own identity, the Group's Organizations, and the Group memberships. Find the newly connected Group on the **Connected** tab of your Oleria **Integrations** page.
  </Step>
</Steps>

If **Authenticate** fails, Oleria shows the reason. The most common causes:

* Snyk rejects the credential. It may be invalid, revoked, or expired, or it may belong to a different region than the one you selected. Snyk credentials only work in their own region.
* The Group isn't found. Check the Group ID and the region.
* The credential can't read the Organizations or the Group memberships. Give the service account the **Group Admin** role, or add the missing permission that Oleria names.

<Note>
  You can connect each Snyk Group to Oleria once. If you have several Groups, connect each one separately.
</Note>

## Verify the integration

Confirm the Snyk Group appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered accounts, Organizations, roles, and service accounts in your Oleria workspace.

<Note>
  If you rotate the credential, update the integration in Oleria with the new value. To keep the stored secret when you edit the integration, leave the secret field empty. If you switch the authentication method, or change the client ID, enter the new secret. You can't change the Group ID of an integration: to connect a different Group, add a new integration.
</Note>

## Remediation actions

Oleria can take these actions in Snyk. Each one uses the integration's service account, which needs the **Group Admin** role:

* **Invite a user**. Snyk has no API to create a user, so Oleria invites the email address to the Organizations you choose, with the **Org Collaborator** role. Reverting the action cancels the invitations that are still pending.
* **Remove a user**. Oleria removes the user from the Group, which also removes every Organization membership. For a pending invitation, Oleria cancels it. Reverting the action restores the user's Group role and each Organization role. A cancelled invitation isn't restored.
* **Re-enable a user**. Oleria adds an existing Snyk user back to the Group with the **Group Member** role. Reverting the action removes that membership.
* **Add a user to, or remove a user from, an Organization**. Oleria adds the user to the Organization with the **Org Collaborator** role, or removes their direct membership. Reverting the action undoes the change and restores the previous role.
* **Add a user to, or remove a user from, a role**. For a Group role, Oleria changes the user's Group role, and removing a Group role downgrades the user to **Group Member**. For an Organization role, Oleria changes the user's role in that Organization, and removing it removes the user from the Organization. Reverting the action restores the previous role or membership.
* **Disable a non-human identity**. Oleria deletes the service account, or uninstalls the Snyk App. **This can't be reverted.** Create a new service account, or reinstall the app, to restore access.

If the user is already in the requested state, for example already a member of the Organization, the action succeeds without changing anything.

Keep these limits in mind:

* Oleria won't change or delete the service account the integration uses, so the integration doesn't lose its own access.
* Oleria won't remove or downgrade the last user with **Group Admin**. Service accounts, including the integration's own, don't count as remaining admins.
* **Group Member** is the lowest Group role, so removing it fails. To take away a user's access, remove the user instead.
* Adding a user to an Organization or a role, and changing their Group role, only works for existing Group members. Use **Invite a user** for someone new.
* A **Group Admin** has access to every Organization through their Group role. Removing their direct Organization membership doesn't remove that access. Change their Group role instead.
* Service accounts can't be added to, or removed from, Organizations or roles with these actions. Use **Disable a non-human identity** instead.
* Reverting a user removal re-adds the Group and Organization memberships Oleria recorded when it removed the user. If Snyk accepts only some of them, the revert fails with a message saying it stopped partway. Check the user in Snyk before you revert again.
* If the Organization or role was deleted from Snyk after the action ran, reverting the action can't restore it.

## Known limitations

* **90 days of activity.** Snyk keeps 90 days of audit-log events, so Oleria can't import older activity, and an account with no audited change in that window has no last-activity date.
* **Last activity is the last audited change.** Snyk doesn't record sign-ins or UI views in its audit log. It does record API calls, but Oleria doesn't import them. An account's last activity is the last change it made in the past 90 days, so active users who only view results may look dormant. So may service accounts and Snyk Apps that only make API calls, such as CI tokens that run scans. Check how a non-human identity is used before you disable it, because disabling it can't be reverted.
* **No MFA data.** Snyk delegates sign-in to your SSO provider or to a social login provider such as GitHub or Google, so Oleria shows MFA status for Snyk accounts as unavailable. If you enforce MFA through an identity provider, Oleria shows that through the identity provider's integration.
* **Administrators are identified by built-in role.** Users and service accounts are marked as administrators only when they hold **Group Admin** or **Org Admin**. Snyk doesn't expose the permissions of custom roles, so a custom role that grants admin permissions isn't flagged. Snyk Apps are marked as administrators when they're installed with a write or management scope.
* **No personal tokens.** Snyk doesn't let an admin list other users' personal access tokens or API keys, so Oleria can't show them.
* **No credentials for Snyk Apps.** Installed Snyk Apps are imported without a credential, because Snyk doesn't expose one for an installation.
* **Roles in use only.** Oleria imports the roles that are assigned to at least one member or service account. Unassigned custom roles aren't shown.
* **One Group per integration.** Tenant-level roles and other Groups in your Snyk tenant aren't imported. SNYK-GOV-01 and single-tenant Snyk deployments aren't supported.

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