Skip to main content
GitGuardian detects leaked secrets in code and other sources. Connect your GitGuardian workspace to Oleria to see every person and token that can reach your secret incidents, through which access level and team, and what they did.

​
What Oleria discovers

Oleria reads your GitGuardian workspace through the GitGuardian public API on its regular sync schedule:
  • Users - workspace members, with their access level, active or deactivated state, creation date and last login. Pending invitations appear as disabled users, because an invitee can already be added to teams before joining.
  • Groups - teams, including the built-in All incidents team, with their members and invitees. Each membership shows the team’s incident permission (can view, can edit or full access) and whether the person is a team leader. Team leaders are shown as the team’s managers.
  • Roles - the four workspace access levels (Owner, Manager, Member and Restricted) and who holds each.
  • Non-human identities - service accounts and personal access tokens, as credentials with their scopes, status (active, expired or revoked), expiry and last-used date. Each personal access token is linked to the member who owns it and acts on that member’s behalf, limited to the token’s scopes. Each service account is linked to the member who created it.
  • Activity - the workspace audit log: sign-ins, member, invitation and team changes, token creation and revocation, and other workspace events, with the source IP address.
Oleria doesn’t read secret incidents, sources or honeytokens.

​
Prerequisites

  • A GitGuardian workspace and a GitGuardian user with the Manager or Owner access level, to create the credential below.
  • For the recommended service account, a GitGuardian Growth or Enterprise plan. GitGuardian offers service accounts only on those plans. On other plans, use a personal access token of a Manager or Owner, or OAuth.
  • For OAuth, a Manager or Owner to approve Oleria, in a workspace that hasn’t turned off OAuth client registration in its preferences.
  • Admin access on the Oleria platform to add a new integration.

​
Choose an authentication method

  • API token (recommended, and the default) - a service account token, or a personal access token of a Manager or Owner.
  • OAuth - a Manager or Owner signs in to GitGuardian and approves Oleria when you connect. GitGuardian then issues a personal access token for that user, so the connection sees what that user’s access level allows. You don’t create anything in GitGuardian beforehand.

​
Create the credential in GitGuardian

Skip this section if you use OAuth.
1

Open the API settings

In GitGuardian, go to Settings -> API -> Service accounts and select Create service account. To use a personal access token instead, go to Settings -> API -> Personal access tokens.
2

Choose the scopes

Name the service account (for example, oleria), choose an expiry, and select these scopes:
3

Copy the token

Select Create service account and copy the token. GitGuardian shows it only once. Update the integration in Oleria before the token expires.

​
Connect GitGuardian to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the GitGuardian tile.
2

Complete the connection form

When you edit the integration, leave API token blank to keep the stored token.
3

Save the integration

Select Authenticate. With an API token, Oleria checks the token with GitGuardian and pins the connection to that workspace. A token from any other workspace is refused, both when you edit the integration and on every sync.With OAuth, you’re redirected to GitGuardian. Sign in as a Manager or Owner and approve Oleria. Oleria asks for the seven scopes listed above, and the approval must include at least members:read. GitGuardian issues a personal access token named Oleria that doesn’t expire, unless a workspace policy limits token lifetime. In that case, reconnect the integration before the token expires.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Integrations page with a status of Healthy. The integration’s Capabilities tab shows Needs permission when the token can’t read members or teams. Without api_tokens:read, Oleria syncs no service accounts or personal access tokens. Without audit_logs:read, or on a plan without API audit logs, it syncs no activity. In both cases the rest still syncs.

​
Remediation actions

Each action needs these scopes: Oleria never changes or deletes the workspace Owner or the member who owns the connection’s personal access token (with OAuth, the member who approved the connection), and never revokes the token the connection uses. If GitGuardian reports that the user or team already exists, Create user or Create group fails without a change.

​
Known limitations

  • GitGuardian’s API doesn’t expose two-factor authentication, single sign-on status or password changes per member, so Oleria shows them as unavailable.
  • Without the api_tokens:read scope, Oleria syncs users, teams and activity but no service accounts or personal access tokens.
  • The audit log needs the audit_logs:read scope and a Manager or Owner credential. If GitGuardian refuses it, for example on a plan without API audit logs, Oleria syncs everything else without activity.
  • Audit events don’t include the browser or device.
  • Pending invitations can’t be disabled or have their access level changed through the API. Delete them with Delete user, or edit them in GitGuardian.
  • Every member holds exactly one access level, so Remove user from role isn’t available. Use Add user to role with a lower level instead.
  • Each OAuth connection attempt registers an OAuth client named Oleria in your workspace. GitGuardian’s API can’t delete these clients.
  • Self-hosted GitGuardian instances aren’t supported.

​
Contact us

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