Create a role trust in Vultr IAM to define who can assume a specific role. Configure trust relationships for users, groups, organizations, or OIDC issuers.
A role trust defines who is allowed to assume a specific role and under what conditions. Before creating a role trust, you must first create an assumable role. The trust relationship links the role to a trusted entity — a user, a group, or an OIDC issuer — and can include conditions such as IP restrictions, time-of-day limits, and an expiration date.
There are three trust types:
This guide explains how to create a role trust using the Vultr Console and the Vultr API.
A role trust is created as part of the assumable role creation flow.
Log in to the Vultr Console.
Click the organization name in the top navigation bar.
Click Manage Organization.
Click the Roles tab.
Click the + button to add a new role.
Select Assumable Role.
Enter a Name and optional Description for the role.
Under Trusted Entity, select the entity type (User, Group, or OIDC Issuer) and choose the specific entity from the dropdown.
Configure the assumption schedule:
(Optional) Under IP Access Restrictions, enter one or more allowed IP addresses (IPv4 or IPv6) to restrict role assumption to specific source IPs.
In the Permission Policies section, search for and select the policies to attach.
Click Add Role.
The assumable role is created with the trust relationship configured. To view the trust details, click the role name and expand the Role Trust section.
Send a GET request to the List Roles endpoint to retrieve all roles in your organization.
$ curl "https://api.vultr.com/v2/roles" \
-X GET \
-H "Authorization: Bearer ${VULTR_API_KEY}"
Note the id of the assumable role for which you want to create a trust.
Identify the trusted entity. You need either a user_id, group_id, or oidc_issuer_id depending on who should be allowed to assume the role.
Send a POST request to the Create Role Trust endpoint to create the trust relationship. Replace ROLE-ID with the assumable role id and USER-ID with the trusted user id. Use trusted_group_id or trusted_oidc_issuer_id instead of trusted_user_id if trusting a group or OIDC issuer. Adjust the conditions and valid_until fields as needed. Add allowed source IPs to the ip_address array to restrict role assumption to specific IPv4 or IPv6 addresses. Leave the array empty to allow all IPs.
$ curl "https://api.vultr.com/v2/role-trusts" \
-X POST \
-H "Authorization: Bearer ${VULTR_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"role_id": "ROLE-ID",
"trust_type": "IAMAssumption",
"trusted_user_id": "USER-ID",
"conditions": {
"time_of_day": {
"timezone": "utc",
"days_of_week": ["monday", "tuesday", "wednesday", "thursday", "friday"]
},
"ip_address": ["203.0.113.10", "2001:db8::1"]
},
"valid_until": "2026-06-20T03:59:59+00:00"
}'
A successful request returns an HTTP 201 Created response.
Note the id of the role trust for future operations.
Send a GET request to the Read Role Trust endpoint to retrieve the trust details. Replace {role-trust-id} with the id returned from the creation request.
$ curl "https://api.vultr.com/v2/role-trusts/{role-trust-id}" \
-X GET \
-H "Authorization: Bearer ${VULTR_API_KEY}"
The response contains the resource details.