> ## 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. # Astronomer > Connect an Astronomer (Astro) organization to Oleria to discover users, teams, organization, workspace, Deployment and Dag roles, API tokens, and audit log activity, and take remediation actions directly from Oleria. Astronomer (Astro) is a managed Apache Airflow platform. Connect an Astro organization to Oleria to see who belongs to it, which roles they hold on each workspace and Deployment, which teams they're in, and which API tokens can act on the organization. Oleria reads this data from the Astro API with an Organization API token. You can then review over-provisioned access and take action directly from Oleria. One Oleria integration covers one Astro organization. To connect another organization, add another integration. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Astro organization: * **Accounts** - every user in the organization, with name, email, organization role, and when they were added and last updated. Organization Owners are marked as administrators. Users with a pending invitation are shown as disabled until they accept it. * **Teams** - every team appears as a group, with its members. Teams managed by your identity provider are shown as synced groups. * **Roles** - the organization roles, the workspace roles of every workspace, and the Deployment roles of every Deployment, including custom roles. Dag roles appear when someone holds them. Oleria shows who holds each role: users, teams, and API tokens. * **Organization roles** - each account's organization role, such as **Organization Owner** or **Organization Member**. * **Non-human identities (NHIs)**: * **API tokens** - every Organization, Workspace, and Deployment API token, shown as an API token with its scope, roles, creation date, expiry, last-used date, and last rotation. Expired tokens are shown as disabled. A token scoped to a workspace or Deployment is linked to it. Oleria never reads token values. * **Remote Execution agent tokens** - the agent tokens of each Remote Execution Deployment, shown as API tokens linked to their Deployment. Remote Execution needs the Astro Enterprise tier or above. When Astro records who created a token, Oleria links the token to that user or token as its owner. * **Activity** - events from the Astro organization audit log, such as: * users invited, and changes to users' roles * team changes and team membership changes * API token creation, changes, rotation, role changes, and deletion * workspace, Deployment, and organization setting changes Each event shows who made it, user or API token, the IP address, the user agent, and the result. Requests Astro rejected for missing access are shown as denied, and other failed requests are kept as custom events. Events Oleria doesn't recognize are kept as custom events. Oleria refreshes users, teams, roles, and NHIs on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > Oleria doesn't import workspaces, Deployments, Dags, or clusters as resources. Oleria reads workspaces and Deployments only to name the roles that apply to them. ## Prerequisites * An Astro organization on Astro Hosted or Astro Hybrid. Astro Private Cloud and Astronomer Software aren't supported. * An Astro **Organization Owner** to create the Organization API token. * Admin access to the Oleria workspace. ### Permissions Oleria uses one Organization API token for both discovery and remediation actions. The token's organization role decides what Oleria can read and change. Use **Organization Owner** for full coverage. An **Organization Member** token can discover users, teams, roles, and API tokens, but not activity or remediation actions. | Capability | Astro permissions | | :- | :- | | Read users | `organization.users.get`, `organization.deployments.get`, `organization.apiTokens.get` | | Read groups | `organization.teams.get` | | Read roles | `organization.customRoles.get`, `organization.workspaces.get`, `organization.deployments.get`, `organization.users.get`, `organization.apiTokens.get`, `organization.teams.get` | | Activity | `organization.auditLogs.get`, which only **Organization Owner** has among the default roles | Remote Execution agent tokens also need `deployment.agentTokens.get`. If the token can't read them, Oleria skips them and syncs the rest. The integration's **Capabilities** tab checks these permissions on each refresh. When the token can't read an object, the matching row shows that it needs permission. ## Set up access in Astro **1. Find the Organization ID** In the Astro UI, select **Settings**. The **Organization Settings** page shows the **Organization ID**. Copy it. **2. Create the Organization API token** On the same page, under **Access Management**, select **API Tokens** -> **+ New Organization API Token**. Then fill in the form: * **Name** - enter `Oleria`. * **Organization Role** - select **Organization Owner**. * **Expiration** - choose an expiry that fits your rotation policy. Discovery stops when the token expires. **3. Copy the token** Create the token and copy its value. Astro shows it only once. > [!NOTE] > > The Astro interface changes over time. If these steps don't match what you see, refer to Astronomer's [Organization API tokens](https://www.astronomer.io/docs/astro/organization-api-tokens) documentation. ## Connect Astronomer to Oleria **1. Open the integration** Sign in to your Oleria workspace, navigate to **Integrations**, and select **Astronomer**. **2. Complete the connection form** Fill in the connection form: | Field | Notes | | :- | :- | | Organization ID | Required. The Organization ID from Astro's organization settings. | | Organization API token | Required. The Organization API token you created. | **3. Authenticate** Select **Authenticate**. Oleria checks that the token is valid and can read the organization before it saves the integration. The integration is named after your Astro organization. ### Edit the connection You can replace the **Organization API token** of an existing integration, for example when you rotate it. To connect a different organization, add a new integration. ## Verify the integration Confirm the Astronomer 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, and API tokens appear in your Oleria workspace, and that Organization Owners are marked as administrators. ## Remediation actions Oleria runs actions with the integration's Organization API token. Before an action runs, Oleria checks that the token's organization role grants the permissions the action needs. | Action | What it does | Revert | | :- | :- | :- | | Add user to role | Gives the user a workspace, Deployment, or Dag role. | Supported - removes the role, unless it changed after the action. | | Remove user from role | Removes the user's workspace, Deployment, or Dag role. | Supported - gives the role back, unless the user got a different role there after the action. | | Add user to group | Adds the user to a team. | Supported - removes the user from the team. | | Remove user from group | Removes the user from a team. | Supported - adds the user back to the team. | | Create user | Invites the email address to the organization as an **Organization Member**. | Supported while the invitation is pending - deletes the invitation. Not supported after the user accepts it. | | Create group | Creates an empty team. If a team with that name already exists, nothing changes. | Supported - deletes the team, but only while it has no members. | | Disable NHI accounts | Deletes the API token, including a Remote Execution agent token. Astro has no way to disable a token. | Not supported - Astro can't restore a deleted token. Create a new token in Astro. | Each action needs these permissions: | Action | Required permissions | | :- | :- | | Add user to role, Remove user from role | `organization.users.get`, `organization.users.update`, `organization.apiTokens.get`, `organization.customRoles.get` | | Add user to group, Remove user from group | `organization.teams.get`, `organization.teams.update`, `organization.apiTokens.get`, `organization.customRoles.get` | | Create user | `organization.users.get`, `organization.users.create`, `organization.users.delete`, `organization.apiTokens.get`, `organization.customRoles.get` | | Create group | `organization.teams.get`, `organization.teams.create`, `organization.teams.delete`, `organization.apiTokens.get`, `organization.customRoles.get` | | Disable NHI accounts | `organization.apiTokens.get`, `organization.apiTokens.delete`, `workspace.apiTokens.delete`, `deployment.apiTokens.delete`, `deployment.agentTokens.delete`, `organization.customRoles.get` | Oleria refuses these actions and sends no change to Astro: * Adding or removing an organization role. Every Astro user holds exactly one organization role. Change it in Astro instead. * Adding a role on a workspace, Deployment, or Dag where the user already holds a different role. Astro allows one role there, so the action would replace it. Remove the current role first. * Adding or removing a role of an API token. Change token roles in Astro, or delete the token with **Disable NHI accounts**. * Changing the members of a team that your identity provider manages. Change them in the identity provider instead. * Deleting the API token the integration connects with. Oleria also refuses to delete tokens when it can't tell which token the integration uses. Astro refuses two actions on some plans, and nothing changes. **Create user** fails with a message that the Astro plan doesn't allow inviting Organization Members. **Create group** fails with a message that the Astro plan doesn't include Teams. 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. * **Create user** sends an invitation. The user gets access only after accepting it. If the email already belongs to a user in the organization, nothing changes. ## Known limitations * **Activity needs the audit log permission.** The token's organization role needs `organization.auditLogs.get`; of the default roles, only **Organization Owner** has it. Without it, Oleria syncs no activity, and the rest of the organization still syncs. Activity from that period isn't imported later, even after you grant the permission. Astro's audit log records changes, not reads or sign-ins, and keeps 90 days of history. * **No MFA, SSO, or sign-in details per user.** Astro's API doesn't report a user's MFA or SSO status, how they sign in, or when they last signed in. * **Users can't be disabled or removed.** Astro's API has no way to deactivate a user or remove them from the organization, so Oleria offers no **Disable user accounts** action. Remove access with the role and team actions, or remove the user in Astro. * **Plan-dependent features.** Teams need the Astro Team tier or above, and the Team tier allows two teams. Custom roles and organization roles other than **Organization Owner** also depend on your Astro plan. On plans without them, there's nothing for Oleria to discover, **Create group** fails because Astro won't create a team, and **Create user** fails because Astro won't invite an **Organization Member**. * **Dag roles appear only when held.** Oleria doesn't read Dags, so a Dag role appears only after someone is given it. * **No OAuth.** Astro doesn't offer OAuth to third-party apps. Its API accepts only the API tokens you create and the session tokens of its own UI and CLI, so Oleria connects with an Organization API token. ## 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.