Regulate access to Vultr resources
Defining access to shared Vultr cloud resources is straightforward through Vultr IAM’s organization function. Creating an organization produces a separate resource and billing environment that users can be added to for collaboration, with embedded permission policies designed to simplify enforcing least privilege access. Admins can select from managed permission policy options, or configure their own at the service, action, or resource level. With Vultr IAM, enjoy advanced capabilities without added complexity.
Organizations
Organizations create environments with shared Vultr resources that are governed by IAM permission policies. Users can be members of multiple organizations but must manually switch between them, preventing accidental cross-organization actions.
Identities
Organization members are established in a hierarchy: root users that own the organization, organization administrators who can manage users and permission policies, and standard users.
User Permission Policies
IAM permission policies control which actions a user can accomplish with organization resources. Organization administrators can select from preconfigured managed permissions or configure their own custom permissions at the service level (by product), the action level (by action taken, such as creating, reading, or updating), and the resource level (by instance). Permission layers are additive and can be configured to permit a user to perform an action on some resources but not others of the same type.
Roles
Roles are predefined permission sets. Adding users to a role provides them with the associated permissions, and removing them revokes them.
Groups
Groups are a set of users with the same permission policies. Adding or removing a user from a group issues or removes the permissions. Groups can be assigned a role or custom permissions.
Assumable roles
Assumable roles provide temporary permissions granted based on a set of specified conditions, such as time-bound or IP-specific requirements. They are usable with OpenID Connect.
Managed permissions
Managed permissions offer a streamlined way to create user permissions through a simple checkbox menu.
Custom permissions
Custom permissions can be created via JSON, enabling precise permission granularity.
Service account users
Service account users are automation-only users, enabling integration with outside applications.
SSO Integration
Single Sign-On (SSO) integration enables Vultr users to log into the Vultr platform using most common single sign-on providers. Compatible providers using the OpenID Connect protocol include OneLogin, Okta, Auth0, Google Identity Platform, Microsoft Entra ID, and more.
API Key Manager
Create, rotate, list, and delete Vultr API keys for Vultr Account Users easily through the Vultr portal or API. Regularly reviewing API access credentials helps maintain account security and prevent misuse.
Control user access without overcomplicated, difficult-to-use identity and access suites
Vultr Identity and Access Management provides options to regulate access to Vultr services at the level of granularity required for each use case.
No information is required for download
Audit account activity with ease
Vultr Account Logs
Review detailed overviews of account user Vultr product actions conducted within the last 30 days. Search activity such as logins, web portal interactions, and API requests to ensure resources remain properly used, and gain valuable insights into usage, activity, and security.
Learn MoreAdditional resources
Review our FAQ and Users Doc for more information about Vultr Users.
FAQ
Yes. Vultr IAM enforces strict tenant isolation at the organization boundary. Resources, users, and data in one organization are not accessible from another organization, even if the same user is a member of both.
There is no cross-organization resource visibility, and a user who belongs to multiple organizations cannot interact with or view resources from a different organization while operating within one.
Any platform action, including managing users, assigning policies, and deploying resources applies only within the organization the action is complete in. Moving between organizations requires deliberate action.
No. Vultr-managed permission policies are predefined and maintained entirely by Vultr, and their underlying permission definitions are unalterable.
Managed permission policies provide a predictable baseline that works without any configuration, providing simplicity for administrators. Vultr updates managed permission policies automatically when products are added or changed, ensuring they remain up to date.
If managed permission policies don't provide the required permissions, custom policies can be configured within the Vultr Console or API.
When a user is removed from a group, all permissions they were granted through that group are immediately revoked, including any roles and permission policies attached to the group. Only the permissions inherited through that specific group are revoked. The user retains permission policies attached directly to them, roles assigned directly to them, and permissions granted through any other groups they still belong to.
Resource scoping is the ability to assign a permission policy to specific Vultr resources rather than applying it broadly across an entire product or service. For example, a permission policy can be restricted to only specific subscriptions, giving you precise control over exactly which resources a user, group, or role can interact with.
Are resources and data Isolated between organizations?
Yes. Vultr IAM enforces strict tenant isolation at the organization boundary. Resources, users, and data in one organization are not accessible from another organization, even if the same user is a member of both.
There is no cross-organization resource visibility, and a user who belongs to multiple organizations cannot interact with or view resources from a different organization while operating within one.
Any platform action, including managing users, assigning policies, and deploying resources applies only within the organization the action is complete in. Moving between organizations requires deliberate action.