app.pulumi.com) and self-hosted Pulumi Cloud.
What Oleria discovers
Oleria reads your organization through the Pulumi Cloud REST API on its regular sync schedule:- Accounts - organization members, with their organization role, admin status, email, and the date they joined. Suspended members, and members of the backing GitHub or GitLab organization who haven’t joined Pulumi yet, appear as disabled. Stack collaborators, who can access only some stacks, appear as external users. Pending invitations appear as disabled accounts. Single sign-on status comes from how the organization signs in: Required for SAML organizations and Configured for organizations backed by GitHub, GitLab, or Bitbucket, and Not configured for organizations that sign in with Pulumi accounts.
- Non-human identities - the organization’s service principal and each team’s service principal (the identities that organization and team access tokens act as), organization and team access tokens, and OIDC issuers that let external workloads exchange their identity tokens for Pulumi tokens. Each token and issuer is paired with a credential that shows its status, scope, creation date, last use, and expiry where Pulumi sets one. Tokens are linked to the member or service principal that created them, as their owner, and to the service principal they act as. Issuers are linked to each principal their policy issues tokens for.
- Groups - teams and their members, including teams synced from GitHub or SCIM, with each team’s creation date from the audit log. Team admins are shown as owners of their team.
- Roles - built-in and custom organization roles, who holds each one (members, service principals, organization access tokens, and teams), and the access each role gives to all stacks and all environments, at the matching Pulumi permission set. For a custom role, Oleria uses the highest permission set the role fully holds, and skips grants that depend on a condition.
- Resources - the organization, its stacks, and its ESC environments, with who can reach each one: direct collaborators and assignments, teams, the organization’s default stack and environment permissions, and the Admin role. Stack and environment owners are shown as owners of their stack or environment, and holders of the Admin role as owners of the organization and of every stack and environment. Each stack shows its creation date from the audit log. Access levels use Pulumi’s permission names, such as Stack Write or Environment Open.
- Activity - events from the Pulumi audit log, such as sign-ins, member, role, and team changes, token and OIDC issuer changes, secret and environment opens, stack updates, and setting changes. Actions taken with an organization or team access token are attributed to its service principal, with the token recorded as the credential used. Events on a stack or environment link to it in Pulumi Cloud, and other events link to the organization. The audit log needs a Pulumi Pro or Enterprise plan.
Prerequisites
- An organization admin in Pulumi Cloud, to create the access token below.
- Your organization’s name as it appears in Pulumi Cloud URLs - for example,
acmeinhttps://app.pulumi.com/acme. - For audit log activity, a Pulumi Pro or Enterprise plan.
- Admin access to the Oleria workspace.
Self-hosted Pulumi Cloud must be reachable from Oleria over HTTPS. Before you connect, contact support@oleria.com to have your API hostname allowed.
Choose an access token
Required permissions
The Admin role grants every scope Oleria uses. For a read-only connection, give an organization access token a custom organization role with these scopes. Oleria then syncs everything, and remediation actions show that they need permission.
When you select Authenticate, Oleria refuses a token that’s missing any of these read scopes other than
auth_policies:read and audit_logs:read, and names the missing scopes. Without audit_logs:read, the activity sync reports an error on plans that include audit logs. The write scopes for each action are listed under Remediation actions.
Create the access token in Pulumi
1
Create the token
Organization access token (recommended): In Pulumi Cloud, open your organization and go to Settings -> Access Tokens. Create an organization access token and assign it the Admin role, or a custom role with the scopes above.Personal access token: Signed in as an organization admin, create a personal access token for your user.
2
Copy the token
Copy the token before you leave the page. Pulumi shows it only once. If you set an expiry, update the integration in Oleria before the token expires.
Connect Pulumi to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations, then select the Pulumi tile.
2
Complete the connection form
3
Authenticate
Select Authenticate. Oleria checks that the token works, can read the organization, and holds the required read scopes before saving the integration.
Verify the integration
Confirm Pulumi 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, tokens, stacks, and environments in your Oleria workspace. The integration’s Capabilities tab shows Read users (org_member:read, invites:read), Read groups (team:list, team:read), and Read roles (role:read, org_member:read, team:list), and checks them against your token.
If you replace the token in Pulumi, update it in Oleria by editing the integration. Editing the integration always asks for the access token, so enter the current or new token.
Remediation actions
Beyond discovery, Oleria can act on Pulumi access to remediate risk. The Admin role grants every scope below. Oleria checks the token’s scopes with Pulumi before an action runs and reports any that are missing.
Disable NHI works per type:
- Organization and team access tokens - Oleria revokes the token. Revocation is permanent; create a new token in Pulumi if you need one again. Pulumi lets only a personal access token revoke organization access tokens, so with an organization access token connection Oleria reports that it can’t revoke them. An expired token is left as is.
- OIDC issuers - Oleria removes every allow rule from the issuer’s policy, so it stops issuing Pulumi tokens. Pulumi doesn’t accept an empty policy, so when no other rule remains, Oleria leaves one deny rule with the subject
oleria-disabled-issuer. Reverting restores the recorded rules, unless an allow rule was added since. The empty placeholder rule Pulumi adds when an issuer is registered isn’t restored, because Pulumi doesn’t accept it on update. It matches no workload. - Service principals - not supported. Pulumi creates and manages them. Revoke their access tokens instead.
Known limitations
- No MFA status. Pulumi exposes multi-factor authentication status only for the calling identity, so members’ MFA shows as unavailable.
- Last activity comes from the audit log. Pulumi has no last sign-in date for members. Oleria derives last activity from audit log events, so on plans without the audit log, members have no last-activity date. Tokens and OIDC issuers show when they were last used.
- The audit log needs Pulumi Pro or Enterprise. On other plans, Oleria syncs everything else without activity.
- Revoking organization access tokens needs a personal access token. Pulumi refuses that revocation from organization and team tokens. With an organization access token connection, Disable NHI works for team access tokens and OIDC issuers.
- Some tokens aren’t inventoried. Pulumi lists personal access tokens only to their owner, so other users’ personal access tokens aren’t inventoried. Their use still appears in activity. Deployment runner pool tokens aren’t listed either.
- Not inventoried. Insights accounts, deployment runner pools, and the resources inside stacks. Projects appear as part of each stack’s name rather than as separate resources.
- Role content is summarized. Oleria shows each role’s holders and its access to all stacks and all environments, but not every scope it grants. Grants inside custom roles that depend on a condition aren’t shown.
- Some fields aren’t available. Pulumi doesn’t expose per-member licenses, password change dates, service principal creation dates, or who registered an OIDC issuer. Issuer registration still appears as activity.
- Team and stack creation dates come from the audit log. They’re blank on plans without the audit log or when the token lacks
audit_logs:read, for teams and stacks created more than a year ago, for stacks that were renamed, and, on organizations with very large audit logs, for objects whose creation event is beyond the most recent events Oleria reads. - Renamed logins. Oleria identifies members by their Pulumi login. A user who changes their login appears as a new account.
- One organization per integration. Add one integration for each Pulumi organization.
Existing SCIM connections
If you connected Pulumi earlier with the SCIM setup, Oleria moves that connection to the Pulumi Cloud API, so you don’t need to add a new integration. Oleria takes the organization name and API host from the stored SCIM base URL (https://api.pulumi.com/scim/v2/<organization>) and uses the stored token with the Pulumi Cloud API. If the URL doesn’t name an organization, Oleria asks Pulumi which organization the token belongs to. If the token belongs to more than one, edit the integration and enter the Organization name.
If you followed the earlier SCIM setup, the stored token is a Pulumi SCIM token. The Pulumi Cloud API rejects it, so syncs fail until you edit the integration and enter an organization access token. If you stored an organization access token instead, the connection keeps syncing. If the token doesn’t have the Admin role, give it the scopes in Required permissions so Oleria can read tokens, stacks, environments, and activity.
To update a SCIM connection, edit the existing integration rather than deleting it and adding a new one. In Organization name, enter the organization from the stored SCIM base URL (https://api.pulumi.com/scim/v2/<organization>), as it appears in your Pulumi Cloud URLs. Enter the token in Access token, then select Update. Leave API URL blank to keep the API host from the stored SCIM base URL.
After the switch, Oleria identifies accounts by Pulumi login and teams by team name. Pulumi’s API doesn’t return the IDs the SCIM connection used, so the accounts and groups from the SCIM connection drop out after the first sync with the Pulumi Cloud API. Update any access reviews or workflows that used them.
What changes for remediation:
- Disable user now removes the member from the organization, because the Pulumi Cloud API can’t suspend a member. Reverting it adds the member back with their previous role, Pulumi-managed teams, and team admin role, and with their direct stack and environment permissions when Pulumi’s user assignments feature is on.
- Enable user now adds an existing Pulumi user to the organization with the Member role.
- Create user is no longer available for Pulumi. Update any workflows that use it. Create group now creates a Pulumi team.
- Role changes, resource permission revocation, access token revocation, and OIDC issuer disabling are new.