Sentry

Sentry is an application monitoring and error tracking platform. Connect your Sentry organization to Oleria to see every member and pending invitation, the teams and organization roles they hold, which projects they can reach and why, and the internal integrations and tokens that can act on the organization. Oleria reads this data from the Sentry API with an internal integration token or a user auth token, and can take remediation actions directly from Oleria. Oleria reads access to the organization and its projects. It doesn’t read issues, events, or other monitoring data. One Oleria integration covers one Sentry organization. To connect another organization, add another integration.

​

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Sentry organization:

• Accounts - every organization member, including pending invitations (shown as disabled), with name, email, organization role, when they joined, and when Sentry last saw them active. Members with the Owner or Manager role are marked as administrators. Members who haven’t set a name in Sentry show their email address as their name.
  • MFA - a member with two-factor authentication turned on is shown with MFA required. When the organization requires two-factor authentication, members without it are shown as needing to enroll.
  • SSO - required when the organization requires SSO, and configured for members who have linked an SSO identity.
  • Licenses - members that Sentry restricts because of your plan’s member limit are shown with an inactive license.
• Groups - every team appears as a group, with its members and each member’s team role: Team Admin or Team Contributor. Teams that your identity provider provisions through SCIM are shown as synced groups.
• Roles - the organization roles, such as Owner, Manager, Member, and Billing, with who holds each, and the project access each organization-wide role grants. The team roles also appear in the role catalog.
• Resources - every project, and who can reach it:
  • the teams assigned to the project
  • the team admins of those teams, with owner-level access
  • the Owner and Manager roles, which reach every project
  • when Open Membership is on, the Member role, because any member can join any team and reach its projects
  • internal integrations, which reach every project with the permissions they were granted
• Non-human identities (NHIs):
  • Internal integrations - every internal integration and integration-platform app the organization owns, shown as an application, with its permissions and whether it’s disabled. Each internal integration shows its creation date and its last token rotation, from the token list or the audit log.
  • Internal integration tokens and organization auth tokens - shown as API tokens, each paired with a credential that shows its status, scopes, creation date, and expiry or last-used date. Internal integration tokens are linked to the integration they act as.
  • Installed apps - third-party Sentry integration-platform apps installed in the organization.
  Tokens and installed apps are read only with a user auth token. See Choose an authentication method. When the audit log still records who created an internal integration or token, Oleria shows that member as its owner.
• Activity - events from the organization audit log, on Sentry Business and Enterprise plans, such as:
  • member invitations, removals, and organization role changes
  • team membership changes, and teams added to or removed from projects
  • team, project, and organization changes
  • SSO setup changes and SSO identity links
  • token and client key creation, changes, and removal
  • integration and app installs and removals
  Events made with an internal integration token show that integration as the actor. Events on a project link to the project in Sentry. Events Oleria doesn’t recognize are kept as custom events.

Oleria refreshes this data on its regular sync schedule.

​

Prerequisites

• A Sentry user who can create an internal integration with the permissions below. To use a user auth token instead, the user needs the Owner or Manager organization role.
• A Sentry Business or Enterprise plan, if you want audit log activity. Oleria syncs everything else on any plan.
• Your Sentry organization slug.
• Admin access to the Oleria workspace.

​

Choose an authentication method

​

Create the token in Sentry

Grant the token these permissions. Sentry lists them by resource and access level, and each level includes the ones below it. The scope names in parentheses are what Oleria checks. Your organization slug is in Settings > General Settings, and in your organization’s URL. For example, the slug of https://acme.sentry.io is acme.

​

Connect Sentry to Oleria

​

Verify the integration

Confirm the new instance 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 members, teams, roles, projects, and NHIs in your Oleria workspace. On the integration’s Capabilities tab, Read users, Read groups, and Read roles show as available. If one doesn’t, check the token’s permissions: Read users needs member:read, Read groups needs org:read and team:read, and Read roles needs org:read and member:read.

​

Remediation actions

Beyond discovery, Oleria can act on Sentry access to remediate risk. Oleria checks the token’s permissions before an action runs and reports any that are missing. Revoke access to a project is refused, with the reason, when the member reaches the project through the Owner or Manager role, or when Open Membership is on. Change the member’s role, or turn off Open Membership, instead. Oleria won’t remove, or remove a role from, the user the connection runs as, and it won’t revoke a token of the internal integration the connection uses. It won’t remove the organization’s only owner or take away their Owner role. Oleria doesn’t change what your identity provider manages through SCIM. It refuses to add members to or remove them from a SCIM-provisioned team, to remove a SCIM-provisioned member (so Disable account and Delete user are refused for them), to change an organization role your identity provider sets, and to revoke project access granted through a SCIM-provisioned team. Make these changes in your identity provider. Disable NHI isn’t supported for internal integrations or installed apps, because Sentry has no way to disable or suspend them. Deleting or uninstalling them is permanent, so revoke their tokens instead. With an internal integration token, the Capabilities tab shows Disable NHI accounts as unavailable, because Sentry accepts token revocation only from a user auth token. The role actions, Disable account, and Delete user can show as available with an internal integration token that has member:admin, but Sentry refuses them when they run.

​

Known limitations

• Activity depends on your plan. Sentry offers the audit log on Business and Enterprise plans, and Oleria needs org:write to read it. Oleria imports up to the last 90 days of events. Without the audit log, Oleria still syncs members, teams, roles, projects, and internal integrations, but it can’t import activity or show who created an integration or token.
• Some actions need a user auth token. With an internal integration token, Oleria inventories internal integrations, but not their tokens, organization auth tokens, or installed apps. It can’t revoke tokens, remove members or invitations, or change organization roles.
• Personal tokens aren’t inventoried. Sentry lists a user’s personal tokens only to that user, so Oleria can’t list them for the organization.
• Internal integration client secrets aren’t inventoried. Sentry doesn’t return them in the organization’s list of integrations.
• No password change date. Sentry doesn’t expose when a member last changed their password.
• No two-factor method detail. Oleria shows whether a member has two-factor authentication turned on, but not which method they use.
• No session revocation. Sentry has no API to end a member’s sessions. A removed member can’t be re-enabled, because Sentry deletes the membership. Revert the Disable account action to invite them again.
• Self-hosted Sentry must be reachable. Oleria connects to a self-hosted Sentry over HTTPS from Oleria’s cloud. Contact us to allow your host before you connect.

​

Existing SCIM connections

If you connected Sentry earlier with the SCIM setup, that connection moves to the Sentry API without reconnecting. Oleria reads your organization slug and host from the stored SCIM base URL, and members and teams keep the same IDs, so existing access reviews and history carry over. Oleria now reads the organization itself, so the token needs org:read. The SCIM token that Sentry generates for SCIM provisioning may not have it, and then the sync reports an error. To get everything described on this page, create an internal integration token with the permissions above. Then edit the Sentry integration in Oleria, paste the token in Auth token, and select Update. If your identity provider also uses the SCIM token for provisioning, keep it. Oleria no longer uses it once you enter the new token.

​

Contact us

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