Users, roles and groups
Principals, and the permissions granted to them.
How authorization works
This is the authorization half of Project IAM. Users, service accounts and groups are the principals; roles, with the conditions attached to them, are what gets granted.
A role is a set of permissions on resources or data. Roles are the only thing that grants access, and they are granted to principals, never attached to resources.
Users are the principals with a person behind them. They come in two kinds that share one mechanism: team members who need access to project resources, and end users who reach a deployed dashboard or app with a specific data access level.
Service accounts are principals without a person: servers, scripts, API consumers, and every Data Processing Engine job. They exist only in Project IAM, not at organization level.
Groups collect users and service accounts so a set of roles is granted once instead of per principal. A group usually maps to a team.
Roles can carry conditions, evaluated in CEL against the request, which is how access is narrowed to one bucket, one dataset or one attribute rather than a whole service.
Roles and conditions→
Permission sets, and the CEL conditions that narrow them.
Users→
Team members and application end users.
Service accounts→
Non-human principals, including every DPE job.
Groups→
Grant a set of roles once, to a whole team.
Go further
If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for a custom analysis of your project.
Ask questions, give your feedback and interact directly with the team building the Data Platform on the dedicated Discord channel.
If you need support with your OVHcloud services, create a request in our Help Centre.
Join our community of users.