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.
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.
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.
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 for the list. Without them, Vultr rejects the key with “Unauthorized IP address”.
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:
Connect Vultr to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations -> select Vultr.
2
Complete the connection form
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.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.
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.