Identity, Security & Operations
Identity, Security & Operations
This domain tests account and permission hygiene plus day-to-day operations: who can do what, how access is proven, and how incidents and changes are tracked.
Account and authentication
The OVHcloud account (NIC handle) is the billing and ownership root. Enable two-factor authentication - app-based TOTP, SMS or a hardware security key - because it protects the control panel and API. Sub-users, groups and API/OAuth2 credentials should be created rather than sharing the root credentials.
IAM
OVHcloud IAM works with identities (local users and groups), resource groups that select resources by tags, and policies that grant actions on those groups within a scope. A policy is the combination of who, what and which actions. For Public Cloud, project-level roles and OpenStack users still apply; for Hosted Private Cloud, vCenter permissions are separate from OVHcloud account roles.
Operations
Use monitoring and alerts on services, budget alerts on projects, the status page and support tickets with an accurate severity. Audit and activity logs record administrative actions and should be exported where retention matters.
Worked example
A contractor needs read-only visibility of one Public Cloud project, with no billing access. Create a local IAM identity, add it to a group, define a resource group matching that project's tag, attach a policy granting read actions only, and require 2FA. Reasoning: least privilege → read-only policy; blast-radius control → resource group scoped to one project; billing isolation → no policy on billing resources.
Traps
API keys and tokens can carry broad rights and outlive staff changes, so rotate them. Creating a user without a policy grants nothing, which is often mistaken for a fault. IAM roles do not replace vCenter permissions. 2FA reset is an account-recovery procedure, not a support shortcut.