10 min read

Learning Objectives

By the end of this module, you will be able to:

  • Distinguish the three account types and separate capability rights (what a group may do) from resource grants (which resources it may touch).
  • Apply least privilege on a platform whose access model is implicit-read and has no deny rule, where least privilege means simply not granting.
  • Explain why federation is authentication only, with no just-in-time provisioning and no identity-provider-to-group mapping, and design the manual joiner/mover/leaver runbook this forces.
  • Create a group, scope a resource grant, and add a member in the Data Center Designer, and issue and scope an API token that keeps personal credentials out of automation.

Unit 2.2: Identity, RBAC, and Federation

Introduction

Access control on IONOS does not look like the policy-language IAM of the US hyperscalers. There is no JSON policy document, no explicit deny, and no fine-grained per-action conditions. Access is group-based, with capability rights assigned to a group and resources granted to that same group, and read access is implicit the moment a resource is granted. That model is simpler, but it forces a particular discipline: least privilege is achieved by not granting, not by writing a restrictive rule. This unit establishes that discipline, sets out where federation genuinely stops, and ends by building a scoped group and a scoped API token in the Data Center Designer for FinCorp.

1. Account Types, Capability Rights, and Resource Grants

Three account types exist within a contract. The contract owner is created automatically for whoever first registered, has full access to all resources, can create and delete users and assign the Administrator role, and is the only account that can change the contract payment method; there is exactly one and it cannot be revoked. An Administrator (unlimited per contract) has the same reach as the owner except for the payment method, can assign the Administrator role to others, and accesses all contracted resources without belonging to any group. A User is the basic account type: it has no access at all except through group membership and the privileges assigned to those groups, and it can be upgraded to Administrator.

For Users, access is built from two independent layers, and keeping them distinct is the core of the model:

  • Capability rights are contract-wide abilities assigned to a group, governing what kind of action its members may perform. The assignable group rights include Create Data Center, Create Snapshots, Reserve IP Blocks, Create Internet Access, Use Object Storage, Create Backup Units, Create Kubernetes Clusters, and Access Activity Log.
  • Resource grants scope which specific resources a group may touch, drawn from the controllable resource types: Virtual Data Centers, Snapshots, Images, IP Blocks, Backup Units, and Kubernetes Clusters. Each grant carries an authorization level: Read (implicit the moment a group is assigned a resource), Edit, and Sharing.

A group with the Create Data Center right but no VDC granted to it can create new data centers yet cannot see or touch existing ones; a group granted a specific VDC at Edit level but lacking the Create Data Center right can modify that one VDC but cannot make new ones. The capability and the grant are orthogonal, and a user gets the intersection of both across all groups they belong to. Administrators sit outside this entirely: because they reach all resources directly, they do not need group membership, which makes the Administrator role a deliberately scarce assignment rather than a convenience.

2. Implicit-Read, No Deny, and Least Privilege by Not Granting

The platform has no deny rule. You cannot write a policy that subtracts access; you can only add capability rights and resource grants. Combined with implicit-read (assigning a resource to a group grants read on it automatically), this means least privilege is a function of restraint at grant time, not of a corrective rule afterward. The least-privilege posture is therefore: create narrowly-scoped groups, grant each only the resources it genuinely needs at the lowest level that works (prefer Read over Edit, and reserve Sharing deliberately), and never lean on the Administrator role as a shortcut.

Because there is no deny, an over-broad grant cannot be patched with an exception; it must be removed and re-scoped. The operational discipline that follows is to model groups around roles (a database-operations group, a network group, a read-only auditor group) and to keep the set of resources granted to each as tight as the role allows. For FinCorp under BSI scrutiny, an auditor group is granted the Access Activity Log right and read-level grants on the relevant VDCs and nothing more, so the auditor can review without any ability to change infrastructure.

3. Federation Is Authentication Only

FinCorp already runs a corporate identity provider, so the instinct is to federate and let the IdP drive everything. The platform supports federation with SAML 2.0 and OpenID Connect (OIDC) identity providers, but its scope today is authentication only. That phrase carries three hard consequences that must be designed around:

  • No just-in-time provisioning. A federated login does not create an IONOS account on the fly. The user must already exist as an IONOS Cloud user before they can authenticate through the IdP; account linking requires an existing user.
  • No identity-provider-to-group mapping. The IdP does not drive IONOS group membership. Federation authenticates the person; it does not assign their capability rights or resource grants. Access-mapping from IdP claims to IONOS groups is on the roadmap, not available today.
  • Authentication, not authorization. Federation answers "is this the right person"; the group-and-grant model still answers "what may they do", and that model is administered inside IONOS regardless of the IdP.

The pattern this forces is an explicit, manual joiner/mover/leaver runbook. When someone joins, an administrator creates the IONOS user and assigns the correct groups before federated login is useful. When someone changes role (mover), an administrator adjusts their group membership by hand. When someone leaves (leaver), disabling them in the IdP stops new logins, but the IONOS user and its grants must be removed separately, because the IdP never owned the IONOS-side access. Treating federation as if it provisioned and deprovisioned accounts is the dangerous misreading; it does neither. The native pattern is to keep a documented runbook and to audit the IONOS user list against the HR system on a schedule, since nothing reconciles them automatically.

DCD Implementation Walkthrough

You will create a scoped FinCorp group, grant it a single resource, add a member, and then issue a narrowly scoped API token. Only contract owners and administrators can manage users. The architecture goal is a least-privilege group whose access is exactly its granted resources, plus an automation credential that is not anyone's personal login.

Build goal: Create a group, scope a resource grant, add a member; issue and scope an API token.

Steps (in the Data Center Designer):

  1. Open the User Manager (Users & Groups). In the Groups tab, select Create, enter a Group Name (for example fincorp-db-ops), and select Create to confirm. The group now appears in the Groups list with no rights and no resources yet.
  2. With the group selected, assign its capability rights by enabling only the privileges the role needs (for example Create Kubernetes Clusters, or Access Activity Log for an auditor group). Leave every other right off; unticked is the deny.
  3. Open the Resources of Group tab, click Grant Access, and select the specific resource (for example the fincorp-prod-de VDC) from the drop-down. Granting a resource enables Read on it implicitly; raise to Edit only if the role requires changes.
  4. Open the Members tab and add the user from the Add User drop-down. The user now inherits exactly this group's rights and grants, and nothing more. (Do not add Administrators to groups; they already reach everything.)
  5. For automation, go to Menu > Management > Token Manager and generate an authentication token. Select a TTL from the allowed values (1 Hour, 4 Hours, 1 Day, 7 Days, 30 Days, 60 Days, 90 Days, 180 Days, 365 Days), choosing the shortest that fits the job. The token's permissions are the permissions of the user it is generated under, so generate it under a purpose-built service user that belongs only to the narrowly scoped group, never under a personal admin account.
  6. Copy the token value immediately. It is displayed exactly once at generation and is not recoverable afterward; store it in your secrets manager before leaving the screen.

Common mistakes:

  • Granting a resource at Edit when Read is enough. There is no deny rule to walk it back with; an over-broad grant must be removed and re-scoped.
  • Issuing API tokens under a personal or admin account. The token inherits that account's full reach; issue it under a dedicated, narrowly scoped service user instead.
  • Assuming a token can be paused. Deactivating a token means deleting it; deletion is immediate and permanent, and the value cannot be recovered, so plan rotation as delete-and-reissue.
  • Expecting federation to create or remove accounts. It authenticates only; the joiner/mover/leaver lifecycle is a manual IONOS-side runbook.
  • Treating the one-time token display as recoverable. Capture it at generation; there is no second chance to read it.

A short illustration of the credential boundary: scripting against the API uses the token as a bearer credential, never a username and password, which is exactly why the token must carry only the service user's minimal scope.

curl --location \
  --request GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  --header 'Authorization: Bearer <SERVICE_USER_TOKEN>'

The architectural point is in the header: the token is the identity. Whatever that service user can do, the script can do, which is why scoping the user, not the script, is the control.

Summary

IONOS access control is group-based with capability rights and resource grants kept separate, implicit read, and no deny rule, so least privilege is achieved by granting narrowly rather than by writing restrictive policy. Federation with SAML or OIDC is authentication only, with no just-in-time provisioning and no IdP-to-group mapping, which forces a manual joiner/mover/leaver runbook. API tokens inherit the issuing user's permissions and are shown once, so they belong to scoped service users and are rotated by delete-and-reissue.

Key Points:

  • Three account types: one non-revocable contract owner, unlimited Administrators (full reach minus payment method, no group needed), and Users who get access only through groups.
  • Capability rights (what a group may do) and resource grants (which resources, at Read/Edit/Sharing) are orthogonal; a user gets the intersection across their groups.
  • There is no deny rule and read is implicit, so least privilege means not granting; an over-broad grant is removed and re-scoped, not patched.
  • Federation is authentication only: the user must pre-exist (no JIT), the IdP does not map to groups, and joiner/mover/leaver is a manual runbook.
  • API tokens inherit the issuing user's permissions, allow up to 100 per user, are displayed once and not recoverable, and are deleted (not disabled) to revoke; issue them under scoped service users.

Important Terminology:

  • Capability right: A contract-wide group privilege governing what kind of action members may perform (for example Create Kubernetes Clusters).
  • Resource grant: An assignment of a specific resource to a group at Read, Edit, or Sharing level; granting enables Read implicitly.
  • Federation: SAML 2.0 / OIDC authentication trust; it verifies identity only and does not provision accounts or assign groups.
  • API token: A bearer credential that inherits the issuing user's permissions, shown once at generation and revoked by deletion.