> ## 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. # Vultr > Connect your Vultr organization to Oleria to discover users, service users, API keys and other non-human identities, IAM groups, roles and policies, your cloud resources, and account activity. Connect Vultr to Oleria to see who can act on your Vultr organization and what they can reach: every user and service user, the API keys, OAuth apps, and other credentials that authenticate to Vultr, the IAM groups, roles, and permission policies that grant access, the resources those policies reach, and the activity log. Oleria connects with a Vultr API key. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your Vultr organization: * **Accounts** - every user in the organization, with status, last activity, and API access. Suspended users and pending invitations show as disabled. The organization's root user is marked as the root and as an administrator. * **Non-human identities** - service users, user API keys (with their expiry), OAuth apps, trusted OIDC issuers, container registry robot accounts and root users, SSH keys, Object Storage access keys, Serverless Inference API keys, and the organization's SCIM token. Each secret is paired with a credential that shows its status, expiry, and the identity it authenticates. Oleria never reads the secret values. * **Groups** - IAM groups and their members. * **Roles** - IAM roles, managed and custom permission policies, and legacy user permissions, with each user's and group's assignments. Roles a user or group can assume through a role trust are shown as assumable, with the trust's expiry. * **Resources** - instances, bare metal, Kubernetes clusters, managed databases, Object Storage, block storage, file systems, load balancers, DNS domains, firewall groups, VPCs, reserved IPs, container registries, and Serverless Inference subscriptions, with the policies that grant access to them. Kubernetes worker nodes appear inside their cluster, and instances, bare-metal servers, and managed databases inside their VPC. A public container registry shows as accessible to anyone, and each registry shows the access of its root user and robot accounts. * **Activity** - user logins, console activity, and API requests from the Vultr activity log, for the last 30 days. Oleria refreshes this data on its [regular sync schedule](/integrations/overview.md#sync-model). ## Prerequisites * A Vultr user who can create a service user and grant it permissions: the organization's root user, or a user with IAM management permissions. * Admin access to the Oleria workspace. Each Oleria integration covers one Vultr organization. If you have several organizations, add one integration for each. ## Create a service user and API key We recommend a dedicated service user, so the connection doesn't depend on a person's account. **1. Create the service user** In the Vultr console, select your organization name, then **Manage Organization** -> **Users**, and add a service user for Oleria. **2. Grant the permissions** Create a permission policy with the read permissions in the table below, and attach it to the service user. Add the write permissions only if you want Oleria to take [remediation actions](#remediation-actions). **3. Create the API key** Open the service user and select **Create API Key** under **API Access**. Copy the key before you leave the page. Vultr shows it only once. **4. Allow Oleria's IP addresses** Vultr accepts a service user's API key only from the addresses on its **Access Control List**, under **API Access**. Select **Add IP to Allowlist** and add Oleria's IP addresses. Contact [support@oleria.com](mailto:support@oleria.com) for the list. Without them, Vultr rejects the key with "Unauthorized IP address". Read permissions, for discovery: | Permission | What it adds | | :- | :- | | `account.user.List` (required) | Users, service users, and users' API keys. | | `iam.organization.List` (required) | The organization the connection belongs to. | | `iam.organization.Read` | Suspended users and the SCIM token. | | `account.billing.Read` | The root user's name and email. | | `iam.group.List`, `iam.group.Read`, `iam.user.ListGroups` | IAM groups and their members. | | `iam.invitation.List` | Pending invitations. | | `iam.role.List`, `iam.role.ListUsers`, `iam.role.ListGroups`, `iam.role.ListPolicies` | IAM roles and their assignments. | | `iam.policy.List`, `iam.policy.ListUsers`, `iam.policy.ListGroups` | Permission policies and their attachments. | | `iam.roletrust.List` | Assumable roles. | | `oidc.issuer.List` | Trusted OIDC issuers. | | `container.registry.List`, `container.registry.Read` | Container registries and their robot accounts. | | `compute.sshkey.List` | SSH keys. | | `..List` | Each resource type you want inventoried, for example `compute.instance.List`, `kubernetes.cluster.List`, or `storage.object.List`. | | `network.vpc.Read` | Which instances and bare-metal servers are attached to each VPC. | | `account.log.List` | The activity log. | If you leave out an optional permission, Oleria skips that inventory and still syncs the rest. Only the root user, or a user with permission to manage users, can read other users' API keys. Write permissions, only for remediation actions: | Permission | What it allows | | :- | :- | | `iam.organization.Update` | Suspending, unsuspending, and removing users. | | `account.user.Read` | Reading a user before suspending, unsuspending, or turning off a service user's API access. | | `iam.invitation.Create`, `iam.invitation.List` | Inviting users. | | `iam.group.Create`, `iam.group.Delete` | Creating IAM groups, and deleting one Oleria created when you undo the action. | | `iam.group.AddMember`, `iam.group.RemoveMember` | Changing IAM group membership. | | `iam.role.AttachUser`, `iam.role.DetachUser`, `iam.policy.Update` | Granting and removing IAM roles and policies. | | `iam.policy.Read` | Revoking a user's access to a single resource. | | `account.user.Update` | Turning off a service user's API access and revoking API keys. | | `container.registry.Update` | Disabling registry robot accounts and making a public registry private. | ## Connect Vultr to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations** -> select **Vultr**. **2. Complete the connection form** | Field | Notes | | :- | :- | | API key | The service user's API key. | | Organization ID | Only needed if the service user belongs to more than one Vultr organization. | **3. Authenticate** Select **Authenticate**. Oleria checks that the key can read your organization and its users, then saves the integration. If the key's user belongs to several organizations, Oleria lists them so you can enter the right Organization ID. ## Verify the integration Confirm Vultr appears on the **Connected** tab of your Oleria **Integrations** page. After the first sync completes, you can review the discovered users, service users, API keys, roles, and resources in your Oleria workspace. > [!NOTE] > > If you replace the API key in Vultr, update it in Oleria by editing the integration. The organization stays the same. ## Remediation actions Beyond discovery, Oleria can act on Vultr access to remediate risk. Remediation needs the write permissions described above. Oleria checks that the connection's user holds the permission before an action runs and reports it if it's missing. | Action | What it does | Reversible? | | :- | :- | :- | | Suspend user | Suspends the user in the organization, which blocks console and API access. | Yes - unsuspends a user that Oleria suspended. | | Unsuspend user | Lifts a suspension. | Yes - suspends the user again. | | Add to or remove from an IAM group | Changes a user's group membership. | Yes - applies the opposite change. | | Grant or remove an IAM role or policy | Attaches or detaches an IAM role or permission policy directly on the user. | Yes - applies the opposite change. | | Disable a service user | Turns off the service user's API access. Vultr deletes all of the service user's API keys when its API access is turned off. | Partly - turns API access back on, but the deleted API keys must be created again. Oleria lists them in the action result. | | Disable a registry robot | Disables the container registry robot account. | Yes - re-enables a robot that Oleria disabled. | | Revoke an API key | Deletes the user API key. | No - a deleted key can't be restored. Create a new key for the user. | | Revoke access to a resource | Removes the resource from the permission policy that grants it, when that policy is a custom policy attached to this user only. If nothing else is left in the policy, Oleria detaches it from the user instead. | Yes - puts the policy back as it was, unless someone changed it since. | | Make a registry private | Turns off public access on a container registry. | Yes - makes the registry public again. | | Invite a user | Invites the email address to the organization with no permissions. | Only after the person accepts: Oleria removes them. Vultr can't withdraw a pending invitation; it expires. | | Create a group | Creates an empty IAM group. | Yes - deletes the group while it's still empty. | | Remove a user | Removes the user from the organization, which ends all of their roles, policies, group memberships, and API keys there. | No - invite the person again. | Oleria won't act on the user or the API keys your connection runs as, and it won't suspend or remove the root user. A role or policy that a user holds only through a group is removed by taking the user out of the group. Revoking access to a resource never edits a Vultr managed policy or a policy that another user, a group, a role, or an OAuth app also holds; Oleria reports the action as not possible and changes nothing. Access a policy grants to every resource of a type is left as it is. OAuth apps, OIDC issuers, SSH keys, Object Storage keys, Serverless Inference keys, the SCIM token, and registry root users can't be disabled from Oleria, because Vultr can only delete or regenerate them. ## Known limitations * **Two-factor authentication and single sign-on status aren't available.** Vultr doesn't expose a user's two-factor setup, single sign-on configuration, or login method through its API, so these report as unavailable. * **Last password change and API key last use aren't available.** Vultr doesn't record them in its API. * **Activity covers 30 days.** Vultr keeps account activity for 30 days. The longer Audit Logs archive is delivered to Object Storage, which Oleria doesn't read. * **Sub-accounts aren't included.** Each Vultr sub-account is a separate account with its own API keys. Add it as its own integration. * **Empty IAM groups may not appear.** Vultr lists IAM groups only to a key with the **Manage Users** permission, and doesn't return a group's members to any key. Oleria reads each user's groups instead, so a group with no members appears only when the service user also holds **Manage Users**. * **Policy resource identifiers.** When a policy names a specific resource, Oleria links it to that resource if the resource is in the inventory. Other policies are shown at the resource-type level. * **Sessions can't be revoked.** Vultr has no API to end a user's console sessions. ## 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.