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

# env0

> Connect an env0 organization to Oleria to discover users, teams, roles, projects and environments, organization API keys, self-hosted agents and their secrets, deployment credentials, and audit log activity, and take remediation actions directly from Oleria.

env0 (env zero) is an infrastructure-as-code automation platform. Connect an env0 organization to Oleria to see who belongs to it, which teams they're in, which roles they hold on the organization, its projects, and its environments, and which API keys and agents can act on it. Oleria reads this data from the env0 REST API with an organization API key. You can then review over-provisioned access and take action directly from Oleria.

One Oleria integration covers one env0 organization. To connect another organization, add another integration.

## What Oleria discovers

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

* **Accounts** - every user in the organization, with name, email, organization role, when they joined, and when they last signed in. Organization admins are marked as administrators. Oleria also shows how each user signs in, from the login provider env0 records for them: GitHub, Google, Microsoft, GitLab, Bitbucket, SAML SSO, or an env0 password.
  * **SSO** - users who sign in through a social login or SAML SSO are shown with SSO configured. Users with an env0 password are shown without SSO. env0 has no setting that requires SSO, so no user is shown with SSO required.
  * **MFA** - env0 leaves MFA to the login provider and doesn't report it, so MFA is shown as unavailable.
  * **Pending invitations** - invited users who haven't accepted yet are shown as disabled accounts, with the organization role they'll get when they accept.
  * **Machine accounts** - organization API keys and self-hosted agents are shown as machine accounts. See **Non-human identities**.
* **Teams** - every team appears as a group, with its description and members. The built-in **Everyone** team is shown as a built-in group.
* **Roles** - the built-in organization, project, and environment roles, such as **Organization Admin**, **Project Deployer**, and **Environment Viewer**, and every custom role, with their permissions. Oleria shows who holds each role, users, API keys, or teams, and where: on the organization, a project, or an environment.
* **Organization, projects, and environments** - the organization, its projects and sub-projects, and their environments, with the users, API keys, and teams that have access to each, and the role that grants it. Archived projects aren't shown. Inactive environments are shown and marked as inactive, because their role assignments still exist. The built-in **Organization Admin** role is shown as owning the organization and every project and environment, because env0 gives it full control of all of them.
* **Non-human identities (NHIs)**:
  * **Organization API keys** - each key is shown as a machine account that holds the key's role, team memberships, and project and environment access, and as an API token linked to that account. Each key shows its creation date, who created it, when it was last used, and whether it's read-only.
  * **Self-hosted agents** - each agent is shown as a service account, with who created it and its connection status.
  * **Agent secrets** - each agent's secrets are shown as API tokens linked to the agent, with their description, creation date, creator, and when they were last used.
* **Secrets** - shown as credentials. Oleria never reads secret values.
  * **Deployment and cost credentials** - each credential's name, its type, such as AWS assumed role or GCP OIDC, and who created it.
  * **Git tokens and SSH keys** - the tokens and keys env0 uses to reach your version control system.
  * **SCIM token** - the bearer token your identity provider uses for SCIM provisioning, with its creation date, when SCIM is configured.
* **Activity** - events from the env0 audit log, such as:

  * users invited, and organization role changes
  * teams created, changed, or deleted
  * custom roles created
  * role assignments created, changed, or removed on projects and environments
  * API keys, agents, agent secrets, and credentials created, and API keys and agent secrets deleted
  * projects and environments created
  * policy and SCIM configuration changes

  Each event shows who made it, the IP address, and whether it came from the env0 UI, CLI, or API. Events made with an API key are shown with the key's machine account as the actor. Events Oleria doesn't recognize, such as deployments, are kept as custom events.

Oleria refreshes users, teams, roles, resources, and NHIs on its [regular sync schedule](/integrations/overview.md#sync-model).

> [!NOTE]
>
> Oleria doesn't import templates, modules, deployments, variables, policies, VCS connections, or cost data. Personal API keys aren't shown, because env0 lists them only to the user who owns them.

## Prerequisites

* An env0 organization. Every env0 plan, including Free, includes the users, teams, and roles Oleria reads. env0 documents audit logs as an Enterprise feature. If your plan doesn't include them, Oleria syncs everything else and shows no activity.
* An env0 **Organization Admin** to create the API key.
* Admin access to the Oleria workspace.

### Permissions

Oleria uses one organization API key for both discovery and remediation actions. Give the key the **Admin** organization role, and don't make it read-only.

| What Oleria reads or changes | env0 permission |
| :- | :- |
| Users, teams, roles, projects, environments, role assignments, credentials, git tokens, and SSH keys | **View Organization**, **View Project**, and **View Environment** |
| Organization API keys, self-hosted agents and their secrets, and the SCIM token | **Edit Organization Settings** |
| Activity | **View Audit Logs** |
| Remediation actions | **Organization Admin**. See [Remediation actions](#remediation-actions). |

A key with a custom role or the read-only setting can't read API keys, agents, or the SCIM configuration. Oleria still syncs the rest of the organization.

## Set up access in env0

**1. Create the API key**

Sign in to env0 as an Organization Admin. Select your organization icon in the bottom-left corner -> **Settings** -> **API Keys** -> **Add API Key**. Then fill in the form:

* **Name** - enter `Oleria`.
* **Role** - select **Admin**. Don't make the key read-only, because a read-only key can't read API keys, agents, or the SCIM configuration, or run remediation actions.

**2. Copy the key ID and secret**

Copy the **API Key ID** and the **API Key Secret**. env0 shows the secret only once.

**3. Find the organization ID**

Optional. In **Settings**, open the **General** tab and copy the organization **ID**. You need it only if the key can access more than one organization.

> [!NOTE]
>
> If your organization has an IP allowlist, add Oleria's IP addresses to it. Contact [support@oleria.com](mailto:support@oleria.com) for the current list. The env0 interface changes over time. If these steps don't match what you see, refer to env0's [API keys](https://docs.envzero.com/guides/admin-guide/user-role-and-team-management/api-keys) documentation.

## Connect env0 to Oleria

**1. Open the integration**

Sign in to your Oleria workspace, navigate to **Integrations**, and select **env0**.

**2. Complete the connection form**

Fill in the connection form:

| Field | Notes |
| :- | :- |
| API Key ID | Required. The ID of the API key you created. |
| API Key Secret | Required. The secret of the API key you created. |
| Organization ID | Optional. The organization's ID, from **Settings** -> **General**. Leave it empty when the key can access only one organization. |

**3. Authenticate**

Select **Authenticate**. Oleria checks that the key is valid and can reach the organization before it saves the integration. The integration is named after your env0 organization.

### Edit the connection

You can replace the **API Key ID** and **API Key Secret** of an existing integration, for example when you rotate the key. A new API Key ID needs its secret. You can't move the integration to a different organization. To connect a different organization, add a new integration.

## Verify the integration

Confirm the env0 integration appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, teams, roles, projects, environments, and NHIs appear in your Oleria workspace, and that organization admins are marked as administrators.

## Remediation actions

Oleria runs actions with the integration's API key. Before an action runs, Oleria checks that the key can perform it.

| Action | What it does | Revert |
| :- | :- | :- |
| Add user to group | Adds the user or API key to a team. | Supported - removes them from the team again. |
| Remove user from group | Removes the user or API key from a team. | Supported - adds them back to the team. |
| Add user to role | Gives the user or API key an organization role: **Organization Admin**, **Organization User**, **Organization TerraformDeployer**, or a custom role. env0 gives everyone exactly one organization role, so the new role replaces the current one. | Supported - restores the previous organization role. |
| Remove user from role | Changes the user's or API key's organization role to **Organization User**. | Supported - restores the previous organization role. |
| Revoke permission to resource | Removes the role a user or API key holds directly on a project or an environment. | Supported - assigns the same role again. |
| Disable user accounts | Removes the user from the organization, because env0 has no disabled state for users. For a pending invitation, Oleria revokes the invitation. | Supported - invites the user again by email. A removed user gets their previous organization role and project roles back after accepting the invitation. Team memberships and environment roles aren't restored. A revoked invitation is sent again with its organization role only. |
| Enable user accounts | Invites the user to the organization by email as an **Organization User**. If the user is still a member or already has a pending invitation, nothing changes. | Not supported - run **Disable user accounts** to revoke the invitation. |
| Create user | Invites the email address to the organization as an **Organization User**, because env0 has no way to create a user directly. The account appears in Oleria as a pending invitation until the user accepts. env0 doesn't take the first name, last name, or groups from the request. If the email is already a member or has a pending invitation, nothing changes. | Supported - revokes the invitation while it's still pending. Once the user has accepted, use **Delete user** instead. |
| Create group | Creates a team with the requested name, up to 100 characters, and no members. If a team with that name already exists, ignoring case, nothing changes. | Supported - deletes the team, but only while it still has no members. |
| Delete user | Removes the user from the organization, because env0 has no way to delete a user. For a pending invitation, Oleria revokes the invitation. This is the same change as **Disable user accounts**. | Supported - invites the user again by email, as for **Disable user accounts**. |
| Disable NHI accounts | Deletes an organization API key, or deletes a self-hosted agent's secret. | Not supported - env0 can't restore a deleted key or secret. Create a new one in env0. |

Each action needs the API key to have these permissions. The built-in **Organization Admin** role has all of them:

| Action | env0 role or permission |
| :- | :- |
| Add user to group, Remove user from group | **Organization Admin** |
| Add user to role, Remove user from role | **Organization Admin** |
| Revoke permission to resource | **Edit Project Settings** for a project, **Assign roles on environment** for an environment, and **Edit Organization Settings** |
| Disable user accounts, Enable user accounts, Delete user, Create user | **Organization Admin** |
| Create group | **Organization Admin** |
| Disable NHI accounts | **Edit Organization Settings** |

Oleria refuses these actions and sends no change to env0:

* Any action on the integration's own API key, such as changing its role, removing it from a team, or deleting it. Oleria also refuses when it can't confirm which key the integration uses.
* Removing or demoting the last **Organization Admin**.
* Changing the members of the built-in **Everyone** team.
* Team or role changes for a pending invitation. The invited user gets their role when they accept. Use **Disable user accounts** to revoke the invitation.
* Removing **Organization User** with **Remove user from role**. It's env0's base role, so remove the user from the organization instead.
* Granting or removing a project or environment role with **Add user to role** or **Remove user from role**, including a custom role the user holds only on a project or environment. Use **Revoke permission to resource** to remove a role from one project or environment.
* Revoking a resource role when the account would keep the same access: the account is an **Organization Admin**, or one of its teams holds a role on the same project or environment. Change the organization role or the team membership first.
* Running **Disable user accounts**, **Delete user**, or **Enable user accounts** on an API key. Use **Disable NHI accounts** instead.
* Running **Create user** with the email address env0 gives an API key (an `@env0.com` address that contains `api-key`). Create user invites people; to add an API key, create it in env0.
* Reverting **Create group** after someone has added members to the team. Remove the members first, or delete the team in env0.
* Disabling a self-hosted agent. Deleting an agent stops every deployment that runs on it, so revoke its secrets with **Disable NHI accounts** instead.

Keep these points in mind:

* If the target is already in the requested state, the action succeeds without making a change, and there's nothing to revert.
* **Revoke permission to resource** removes only the role held directly on that project or environment. Access the account inherits from a parent project or from its organization role stays in place.
* **Create user**, **Enable user accounts**, and reverting **Disable user accounts** or **Delete user** send an invitation. The user gets access only after accepting it.
* env0 caches API key authentication for up to 1 hour, so a deleted API key or agent secret can keep working for up to an hour.
* If a team is synced from your identity provider through SCIM, your identity provider can overwrite a team membership change at its next sync.

## Known limitations

* **No MFA or password data.** env0 leaves sign-in, MFA, and passwords to the login provider, so Oleria can't show MFA status or when a user last changed their password.
* **Users can't be disabled, created, or deleted directly.** env0 users are active, invited, or removed. **Disable user accounts** and **Delete user** remove the user, and **Create user** sends an invitation.
* **Accepted invitations appear as new accounts.** When an invited user accepts, the disabled invitation account disappears and a new account appears for the user.
* **Invitation project roles aren't shown.** env0 reports an invitation's organization role, but not the project roles it will grant.
* **No invitation dates.** env0 doesn't report when a user was invited.
* **Personal API keys aren't shown.** env0 lists personal API keys only to the user who owns them.
* **Nothing expires.** env0 API keys, agent secrets, credentials, git tokens, and SSH keys have no expiry date.
* **Last-used dates are approximate.** env0 reports when an API key or agent secret was last used only after its first use, and the date can lag by up to 1 hour.
* **Credentials have no creation date.** env0 reports only when a deployment or cost credential was last updated.
* **Team project and environment roles can't be removed from Oleria.** Oleria shows them, but you change them in env0.
* **Last sign-in only.** Oleria shows when a user last signed in to env0. Continued use of an existing session doesn't update it.
* **Credentials are inventory only.** Oleria can't disable or rotate deployment credentials, git tokens, SSH keys, or the SCIM token.
* **No sign-in events.** env0's audit log doesn't record sign-ins, because sign-in happens at the login provider.
* **Large organizations sync more slowly.** env0 limits API requests per IP address, and Oleria reads environment role assignments one environment at a time.
* **Some behavior isn't confirmed on a live organization yet.** SAML SSO users, SSO-synced teams, git tokens, SSH keys, and removing a user who has already joined (**Disable user accounts** and **Delete user**, and reverting them) have been tested against env0's API documentation, not a live organization. If something doesn't match what this page describes, contact us.

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