Identity & Access Management (IAM)

OVHcloud IAM lets you define exactly who can perform which actions on which resources within your account. Instead of sharing your root account credentials, you create identities (users, service accounts, or federated users) and grant them access through policies.

IAM policies

Create and manage policies in the OVHcloud Control Panel.

IAM API

Manage policies programmatically using the v2 API.

User management

Create and configure local users and user groups.

Core concepts

OVHcloud IAM is built around four concepts: identities, resources, actions, and policies.

Identities

An identity is any entity that can interact with OVHcloud products:

Identity type	Description	Best used for
OVHcloud account	The root account (NIC handle, e.g. `xx1111-ovh`). Cannot have its rights restricted.	Account owner only
Local users	Human users created under your account, authenticated by login/password.	Team members
Service accounts	Machine identities authenticated via OAuth2 client credentials.	Automation and CI/CD
Federated users	Users from an external identity provider (Active Directory, Google Workspace, Azure AD, Okta). Managed through user groups.	Large teams with a central IdP

We recommend using local users or federated users as soon as more than one person accesses your OVHcloud account. This ensures traceability of all actions performed.

Resources

A resource is any OVHcloud product associated with your account — a VPS, a domain name, a Public Cloud project, a Load Balancer, and so on. Each resource has a unique URN in this format:

urn:v1:<plate>:resource:<type>:<identifier>

For example:

urn:v1:eu:resource:vps:vps-5b48d78b.vps.ovh.net
urn:v1:eu:resource:publicCloudProject:abc123def456

You can retrieve all resources linked to your account using GET /iam/resource.

Actions

An action is a specific operation on a resource. Action names follow the format <resourceType>:apiovh:<operation>. For example:

vps:apiovh:reboot — reboot a VPS
vps:apiovh:snapshot/create — create a VPS snapshot
vps:apiovh:* — all VPS actions (wildcard)
* — all actions on all resources

You can list all available actions using GET /iam/reference/action (optionally filtered by resourceType).

Policies

A policy ties identities to resources and specifies which actions are allowed or denied. Policies are additive by default — all actions are denied unless explicitly allowed. A policy contains:

identities — one or more URNs for users, groups, service accounts, or accounts
resources — one or more resource URNs or resource groups
permissions — allow, deny, and except lists of actions

{
  "name": "vps-reboot-snapshot",
  "description": "Allow user1 to reboot VPS and create snapshots",
  "identities": [
    "urn:v1:eu:identity:user:xx1111-ovh/user1"
  ],
  "resources": [
    { "urn": "urn:v1:eu:resource:vps:vps-5b48d78b.vps.ovh.net" }
  ],
  "permissions": {
    "allow": [
      { "action": "vps:apiovh:reboot" },
      { "action": "vps:apiovh:snapshot/create" }
    ]
  }
}

Creating and managing local users

Local users are human identities linked to your OVHcloud account. They log in with a username and password and are subject to the IAM policies you create. To create a local user via the Control Panel:

Go to Identity, Security & Operations > Identities in the OVHcloud Control Panel.
Click Create user.
Fill in the login, email address, and password.

To create a user via the API:

POST /me/identity/user

{
  "login": "john.doe",
  "email": "[email protected]",
  "password": "<secure-password>",
  "description": "DevOps engineer"
}

The user’s URN for use in policies takes the form:

urn:v1:eu:identity:user:xx1111-ovh/john.doe

You can also organise users into user groups to simplify policy management:

POST /me/identity/group

{
  "name": "devops-team",
  "description": "DevOps engineers",
  "role": "REGULAR"
}

A group’s URN: urn:v1:eu:identity:group:xx1111-ovh/devops-team

Creating your first IAM policy

Open the IAM section

Go to IAM Policies in the OVHcloud Control Panel. Click Create a policy.

Name the policy

Enter a unique name for the policy (no spaces allowed). Add an optional description to explain its purpose.

Select identities

Choose the users, groups, or service accounts this policy applies to. You can mix identity types in a single policy.

Select product types and resources

Choose the product type (e.g. VPS) and then select the specific resources to target. You can also use resource groups to target multiple resources at once.

Define actions

Choose how to define permissions. You have four options:

Authorise all actions — grant all current and future actions for the selected products
Permission groups — use OVHcloud-managed groups like globalAdmin or product-specific read/write groups
Add actions manually — type action names with optional wildcards (e.g. vps:apiovh:ips/*)
Select from list — browse available actions by category (Read, Create, Edit, Delete, Operate)

Save the policy

Click Create to activate the policy immediately.

Be careful not to remove all policies that grant access to IAM itself. If you lose the ability to modify policies, you cannot restore access without contacting OVHcloud support. Always test restrictive policies on non-production users before applying them broadly.

Creating IAM policies via the API

You can also create policies programmatically using the v2 IAM API:

POST /iam/policy

{
  "name": "vps-all-but-delete-snapshot",
  "description": "Full VPS access except snapshot deletion",
  "identities": [
    "urn:v1:eu:identity:user:xx1111-ovh/user2"
  ],
  "resources": [
    { "urn": "urn:v1:eu:resource:vps:vps-5b48d78b.vps.ovh.net" }
  ],
  "permissions": {
    "allow": [
      { "action": "vps:apiovh:*" }
    ],
    "except": [
      { "action": "vps:apiovh:snapshot/delete" }
    ]
  }
}

The except list narrows down a wildcard allow without creating a hard deny. A hard deny takes precedence over any allow, even in other policies. To list all existing policies:

GET /iam/policy

To update or delete a policy:

PUT  /iam/policy/{policyId}
DELETE /iam/policy/{policyId}

Policy conditions

You can add conditions to make a policy valid only when specific criteria are met — for example, restricting access to business hours or a specific IP range:

{
  "conditions": {
    "operator": "AND",
    "conditions": [
      {
        "operator": "MATCH",
        "values": {
          "request.IP.IN_RANGE": "10.23.0.0/16"
        }
      },
      {
        "operator": "NOT",
        "conditions": [
          {
            "operator": "MATCH",
            "values": {
              "date(Europe/Paris).WeekDay.IN": "Saturday,Sunday"
            }
          }
        ]
      }
    ]
  }
}

This example allows access only from a specific IP range and only on weekdays (Paris time).

OVHcloud-managed permission groups

OVHcloud provides predefined permission groups that you can use in policies instead of listing individual actions. These groups are maintained by OVHcloud and automatically include new actions as products evolve. Common permission groups:

Group URN	Description
`urn:v1:eu:permissionsGroup:ovh:globalAdmin`	Full access to all OVHcloud products
`urn:v1:eu:permissionsGroup:ovh:globalReadOnly`	Read-only access to all products

To list all available permission groups:

GET /iam/permissionsGroup

To use a permission group in a policy:

{
  "name": "readonly-all",
  "identities": ["urn:v1:eu:identity:user:xx1111-ovh/auditor"],
  "resources": [{ "urn": "urn:v1:eu:resource:account:xx1111-ovh" }],
  "permissions": { "allow": [] },
  "permissionsGroups": [
    { "urn": "urn:v1:eu:permissionsGroup:ovh:globalReadOnly" }
  ]
}

Service accounts

Service accounts are machine identities for automated processes. They authenticate via OAuth2 client credentials and have no time-limited tokens tied to a user session.

Creating a service account

POST /me/api/oauth2/client

{
  "callbackUrls": [],
  "flow": "CLIENT_CREDENTIALS",
  "name": "terraform-provisioner",
  "description": "Used in CI/CD pipeline to provision infrastructure"
}

The response contains a clientId and clientSecret. Save the clientSecret immediately — it cannot be retrieved again. Retrieve the service account’s IAM URN:

GET /me/api/oauth2/client/{clientId}

The identity field returns a URN like:

urn:v1:eu:identity:credential:xx11111-ovh/oauth2-0f0f0f0f0f0f0f0f

Use this URN as an identity in an IAM policy to grant the service account specific rights. See OVHcloud API — Service accounts and OAuth2 for the full authentication flow.

Example: attach a policy to a service account

{
  "name": "service-account-vps-mgmt",
  "description": "Allow automation script to manage VPS",
  "identities": [
    "urn:v1:eu:identity:credential:xx11111-ovh/oauth2-0f0f0f0f0f0f0f0f"
  ],
  "resources": [
    { "urn": "urn:v1:eu:resource:vps:*" }
  ],
  "permissions": {
    "allow": [
      { "action": "vps:apiovh:*" }
    ]
  }
}

SSO federation

If your organisation uses a central identity provider (IdP), you can federate it with OVHcloud so that your team logs in with their existing corporate credentials. Federated users are managed as user groups in OVHcloud IAM.

Microsoft Active Directory (ADFS)

OVHcloud supports SAML 2.0 federation with Active Directory Federation Services (ADFS).To configure federation:

In the OVHcloud Control Panel, go to Identity, Security & Operations > Identities > SSO.
Download the OVHcloud service provider metadata XML.
In ADFS, create a Relying Party Trust using the OVHcloud metadata.
Configure claim rules to pass the user’s group membership in the SAML assertion.
In OVHcloud, upload the ADFS IdP metadata and map ADFS group names to OVHcloud user groups.

Refer to the ADFS federation guide for step-by-step instructions.

Azure Active Directory

OVHcloud supports SAML 2.0 federation with Azure AD (now Microsoft Entra ID).To configure federation:

In the Azure portal, create an Enterprise Application.
Configure the SAML single sign-on settings using OVHcloud’s entity ID and reply URL.
Add group claims to the SAML token.
In OVHcloud, add the Azure AD IdP metadata and map Azure AD groups to OVHcloud user groups.

Refer to the Azure AD federation guide for step-by-step instructions.

Google Workspace

OVHcloud supports SAML 2.0 federation with Google Workspace.To configure federation:

In the Google Admin console, create a custom SAML application for OVHcloud.
Configure the ACS URL and Entity ID with OVHcloud values.
Map user attributes (including groups) to SAML attributes.
In OVHcloud, upload the Google IdP metadata and map Google groups to OVHcloud user groups.

Refer to the Google Workspace federation guide for step-by-step instructions.

Okta

OVHcloud supports SAML 2.0 federation with Okta.To configure federation:

In Okta, create a new SAML 2.0 application.
Set the Single Sign-On URL and Audience URI using OVHcloud values.
Configure group attribute statements to pass Okta group membership.
In OVHcloud, upload the Okta IdP metadata and map Okta groups to OVHcloud user groups.

Refer to the Okta federation guide for step-by-step instructions.

When federation is active, IAM policies that target groups apply to federated users automatically as long as the group names match. You do not need to manage individual federated users in OVHcloud.

Enabling IAM logs forwarding

You can forward IAM-related events to Logs Data Platform for auditing, security monitoring, and compliance. There are three categories of account logs available:

Log type	API endpoint	Content
Audit logs	`POST /me/logs/audit/log/subscription`	Login events, password changes, MFA activity
Activity logs	`POST /me/api/log/subscription`	All API calls and Control Panel actions
Access policy logs	`POST /iam/log/subscription`	IAM policy evaluations — which actions were allowed or denied

To enable access policy log forwarding to a Logs Data Platform stream:

POST /iam/log/subscription

{
  "streamId": "ab51887e-0b98-4752-a514-f2513523a5cd",
  "kind": "default"
}

Replace streamId with the ID of your target LDP data stream. You can find this in the OVHcloud Control Panel under Logs Data Platform > Data streams > Copy stream ID. Once enabled, you can query IAM access policy logs in Graylog. To find all denied actions for a specific user:

identities_array:*john.doe* AND unauthorized_actions_array:*

See Observability & Monitoring for how to set up your first log stream.

Troubleshooting IAM policies

A user gets a 403 Forbidden error

When an API call is denied by IAM, the HTTP 403 response includes the name of the missing action:

{
  "class": "Client::Forbidden",
  "message": "User not granted for this request",
  "details": {
    "unauthorizedActionsByAuthentication": "",
    "unauthorizedActionsByIAM": "vps:apiovh:reboot"
  }
}

Copy the action name from unauthorizedActionsByIAM and add it to the relevant IAM policy. If you are troubleshooting a 403 that occurs in the Control Panel rather than via API, open your browser’s developer tools, go to the Network tab, and look for requests returning a 403 status. Inspect the response body to find unauthorizedActionsByIAM.

Finding missing actions via logs

If you have enabled IAM log forwarding, you can search Graylog for all unauthorized action attempts by a user:

identities_array:*<username>* AND unauthorized_actions_array:*

The results show exactly which actions the user attempted and which were denied, making it straightforward to update the policy.

Common mistakes

Problem	Cause	Fix
Policy exists but user is still denied	Policy targets a different resource URN or identity URN	Verify URNs in `GET /iam/policy/{id}`
Wildcard `*` action does not cover a new API call	New product API introduced after policy creation	Use `permissionsGroups` instead of manual wildcards
Service account token rejected	Service account’s IAM policy was deleted or modified	Check `GET /iam/policy` and re-attach the policy
Federated user cannot log in	Group mapping not configured	Verify group attribute is included in the SAML assertion and mapped in OVHcloud

Do not delete the default OVHcloud policy (ovh-default). This read-only policy grants your root account full access and is required for account management. If you accidentally create a policy that blocks your own access, contact OVHcloud support.

Get Started

Bare Metal & VPS

Public Cloud

Web Cloud

Storage & Network

Manage & Operate

Identity & Access Management (IAM)

IAM policies

IAM API

User management

Core concepts

Identities

Resources

Actions

Policies

Creating and managing local users

Creating your first IAM policy

Creating IAM policies via the API

Policy conditions

OVHcloud-managed permission groups

Service accounts

Creating a service account

Example: attach a policy to a service account

SSO federation

Enabling IAM logs forwarding

Troubleshooting IAM policies

A user gets a 403 Forbidden error

Finding missing actions via logs

Common mistakes

Next steps

OVHcloud API

Observability & Monitoring

Build docs developers (and LLMs) love

Get Started

Bare Metal & VPS

Public Cloud

Web Cloud

Storage & Network

Manage & Operate

IAM policies

IAM API

User management

​Core concepts

​Identities

​Resources

​Actions

​Policies

​Creating and managing local users

​Creating your first IAM policy

​Creating IAM policies via the API

​Policy conditions

​OVHcloud-managed permission groups

​Service accounts

​Creating a service account

​Example: attach a policy to a service account

​SSO federation

​Enabling IAM logs forwarding

​Troubleshooting IAM policies

​A user gets a 403 Forbidden error

​Finding missing actions via logs

​Common mistakes

​Next steps

OVHcloud API

Observability & Monitoring

Build docs developers (and LLMs) love

Core concepts

Identities

Resources

Actions

Policies

Creating and managing local users

Creating your first IAM policy

Creating IAM policies via the API

Policy conditions

OVHcloud-managed permission groups

Service accounts

Creating a service account

Example: attach a policy to a service account

SSO federation

Enabling IAM logs forwarding

Troubleshooting IAM policies

A user gets a 403 Forbidden error

Finding missing actions via logs

Common mistakes

Next steps