What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Sysdig tenant:- Accounts - every Sysdig user, with name, email, whether they’re enabled, and when they were created and last updated. Each user has the Administrator or User account role.
- Single sign-on (SSO) status - for each user, whether SSO is configured or required, and which sign-in methods (SSO or password) the user can use. SSO is shown as required when an SSO configuration is active, password sign-in is turned off, and the user isn’t allowed to bypass SSO.
- Last sign-in - the time of each user’s most recent sign-in, taken from Sysdig’s platform audit log. See Known limitations.
- Teams - every Sysdig Secure and Sysdig Monitor team and its members. Sysdig’s immutable teams are labeled as built-in, all other teams as custom.
- Team roles - the role each member holds in each team. Because a Sysdig role grants access only inside its team, Oleria shows each role per team, for example Advanced User (Production). Standard roles appear under their Sysdig names (Team Manager, Advanced User, Standard User, View-only User, Service Manager, No role). Custom roles appear under their own name. Each team’s default role is shown too, even when no member holds it.
- Administrators - users with Sysdig’s Administrator role hold the Administrator role in Oleria. Sysdig administrators are members of every team automatically, so Oleria doesn’t list them as members of each team.
- IdP group mappings - each identity provider group that Sysdig maps to a team role or to the Administrator role at SSO sign-in, shown as a synced group linked to the teams and roles it grants. Members of these groups are managed in your identity provider, not in Sysdig.
- Non-human identities (NHIs):
- Service accounts - global and team service accounts, each with its API key as a credential. Oleria shows the key’s creation, expiration, and last-used dates, and marks a service account as inactive once its key has expired. Team service accounts are linked to their team and team role, and global service accounts to their system roles.
- Agent access keys - the keys Sysdig agents use to connect and send data, shown as API tokens with their status (active or disabled) and linked to the team that owns them. Oleria never reads or stores the key value.
- Activity - every change recorded in Sysdig’s platform audit log, plus sign-ins, failed sign-ins, and sign-outs. This includes changes to users, teams, team membership, roles, IdP group mappings, service accounts, agent access keys, API tokens, and settings (including SSO settings), and changes to other Sysdig objects. Failed requests are included with their HTTP status. Each event is attributed to the user or service account that made it.
This integration covers identity and access governance only. Oleria doesn’t import Sysdig policies, rules, zones, clusters, alerts, dashboards, scan results, or captures, so it doesn’t populate resource-level Access Graph or Access Inventory data.
Prerequisites
- A Sysdig SaaS tenant in one of the regions listed in Connect Sysdig to Oleria, or a Sysdig On-Prem installation reachable over HTTPS from the internet. IBM Cloud Monitoring and IBM Cloud Security and Compliance Center Workload Protection aren’t supported.
- A Sysdig user with the Administrator role whose API token Oleria will use. Oleria refuses to connect with a token that doesn’t belong to an Administrator, including a service account’s token, because only an Administrator can read every user, team, service account, and agent access key, and run the remediation actions.
- Admin access to the Oleria workspace.
Get your Sysdig API token
1
Sign in as the integration user
Sign in to Sysdig Secure or Sysdig Monitor as the Administrator user that Oleria will use.
2
Copy the API token
Open the user menu and select Settings > User Profile. Copy the Sysdig Secure or Sysdig Monitor API token shown on the page.
Connect Sysdig to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations -> select Sysdig.
2
Complete the connection form
3
Authenticate
Select Authenticate. Before saving anything, Oleria identifies the user the token belongs to, refuses the token unless that user is a Sysdig Administrator, and checks that the token can list users, teams, team members, service accounts, agent access keys, and IdP group mappings. Service-account tokens are refused. If a check fails, Oleria asks you to use an Administrator’s API token.
Verify the integration
Confirm the Sysdig tenant appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, teams, team roles, service accounts, and agent access keys appear in your Oleria workspace, and that Sysdig administrators hold the Administrator role.When you edit the integration, you can replace the API token, for example after you reset it in Sysdig. Leave API token blank to keep the stored token. The new token must belong to the same Sysdig tenant. To connect a different tenant, region, or On-Prem installation, add a new integration.
Remediation actions
Oleria can take the following actions in Sysdig. Every action runs with the connection’s API token, and is available only while that token belongs to a Sysdig Administrator. The Sysdig permissions column lists what each action uses, all of which an Administrator holds.
Oleria reads the target before it changes anything, and confirms the change by reading it back. If the target is already in the requested state, the action succeeds without making a change, and there’s nothing to revert. If Oleria can’t confirm whether Sysdig applied a change, the action fails and reports that the outcome is unknown, so check the target in Sysdig before you retry.
Reverting an action undoes only the change that action made. Oleria reverts only while the target is still in the state the action left it in. If the user, membership, or access key changed after the action, or no longer exists, Oleria doesn’t overwrite it. Restore the access manually in Sysdig instead.
Reverts follow the same rules as actions: Oleria refuses a revert that the note below would refuse as an action, for example re-disabling the last enabled administrator.
Oleria refuses an action when:
- it would disable the Sysdig user the API token belongs to, remove that user’s administrator role, or change that user’s team memberships, because that would break the integration
- it would disable or remove the administrator role from the last enabled Sysdig administrator. Oleria also checks again after the change; if no enabled administrator remains (for example, because another action ran at the same time), it rolls its own change back and the action fails.
- it changes an administrator’s team membership or team role. Administrators are members of every team automatically: change their Administrator role instead.
- it targets an IdP group mapping. Change the mapping in Sysdig, or the group in your identity provider, instead.
- it makes a user who hasn’t accepted their invitation, or a disabled user, an administrator
- it adds a user to a team that has no default role. Add the user to a specific team role instead.
- it grants the Service Manager role in a Sysdig Monitor team. That role exists only in Sysdig Secure teams.
- it assigns a service account system role to a user, or runs a user action on a service account or agent access key
Known limitations
- No MFA status. Sysdig users turn on multi-factor authentication themselves, and Sysdig’s API doesn’t report it, so Oleria shows MFA as unavailable.
- No last password change. Sysdig’s API doesn’t report when a user last changed their password.
- Last sign-in covers up to 90 days. Sysdig keeps platform audit events for 90 days. Oleria derives each user’s last sign-in from the successful sign-in and sign-out events in that window, reading the most recent weeks first. On a tenant with a very large audit log, Oleria may read only the most recent weeks, and users whose last sign-in is older show none. A user who hasn’t signed in for more than 90 days shows no last sign-in. If the token can’t read the audit log, no user shows a last sign-in.
- Activity covers 90 days and skips reads. Oleria imports platform audit events from Sysdig’s 90-day retention window only. Sysdig records every API request, including read-only ones, so Oleria skips read (
GET) requests and imports only sign-ins and changes. - Service accounts can’t be disabled. Sysdig has no way to disable or suspend a service account, and deleting one can’t be undone because its API key can’t be recovered. Disable NHI covers agent access keys only.
- Service account owners aren’t shown. Sysdig’s API doesn’t report who owns a service account.
- Users’ personal API tokens aren’t listed. Every Sysdig user has a personal API token, but Sysdig’s API doesn’t list them, so Oleria marks each user as having API access instead of showing the token.
- Administrators’ team access is implicit. Administrators are members of every team, but Oleria shows this through the Administrator role rather than as membership of each team.
- IdP group mappings can re-create memberships. Team memberships granted through an IdP group mapping may be re-created the next time the user signs in with SSO, even after Oleria removes them. Change the mapping or the group in your identity provider to remove that access for good.
- No AI agents. Sysdig agents are data collectors authenticated by agent access keys, which Oleria shows as non-human identities. Sysdig’s API doesn’t list AI agents.
- Resources aren’t inventoried. Oleria doesn’t import policies, zones, clusters, or other Sysdig resources, or the access to them. Custom roles show their name, but not each permission they grant.