Cloud access on Google Cloud, Azure, AWS and Infomaniak

Note, 9 September 2026: I build on Azure and Google Cloud; AWS appears in this article as a point of comparison, the four decisions reading better across four platforms than across two.

Every access problem I inherit starts with a reasonable exception. Someone has to finish a deployment on Friday evening, receives Owner on the whole subscription, and still holds it two years later. Nobody removes it: nobody can say which service would stop.

The repair is not another security product. It is four decisions: who receives a right, over which resources, for how long, and what record proves it later. Google Cloud, Azure, AWS and Infomaniak hand you very different instruments for those decisions, and one of the four is missing most of them.

This covers the cloud control plane: the rights that create, change or delete infrastructure and administer other identities, not permissions inside a business application. The company in the examples is Swiss, 10 to 50 people: a small technical team, production and staging, a provider on a three-month mandate, a deployment pipeline that runs without a human account, and a backup job whose credentials cannot delete anything.

The four decisions

1. The smallest useful scope: Grant the role on the narrowest set of resources that still allows the work. A project administrator can destroy every resource in the project; one confined to a single storage space cannot. That limits what a stolen account reaches, without preventing the theft.
2. Groups that describe people, groups that describe rights: org.finance names a population, access.prod-billing-read names a right on a system, and the first feeds the second when every member needs it. A reviewer reads both facts off those names; azure-users gives neither.
3. A standard role, and a named exception: Start from a role the provider maintains, and write a custom one only when a standard role opens a sensitive action the job does not need. Give that exception an owner and a review date.
4. One identity per program: Record its owner, purpose, scope, credential method, last use and removal condition. Prefer an identity attached to the resource, or federated, that receives a short-lived token, over a key sitting in the code.

The four platforms side by side

Where a right applies

Google Cloud stacks resources under an organization, optional folders and projects. A role granted on a container reaches everything inside it, so effective rights add up what sits on the resource and on its parents. A deny policy can block permissions an allow policy grants elsewhere. Google documents the hierarchy and inheritance model.

Azure runs two systems that people constantly confuse. Entra roles administer the directory itself: users, groups, registered applications, sign-in rules. Azure RBAC administers the resources, down a hierarchy of management groups, subscriptions, resource groups and resources. A Global Administrator does not automatically command a subscription; Microsoft provides an emergency elevation to recover a lost one, to be switched off again straight after. The Azure RBAC model describes scopes and identity types, and Microsoft documents the elevation and its removal.

AWS makes the account the real boundary, and groups the accounts into organizational units under an organization. What inherits downward is the ceiling, not the grant: service control policies and resource control policies cap what an account may do and grant nothing at all by themselves. An effective permission is the intersection of the identity policy, the SCP, the RCP and any permissions boundary, in union with a resource policy, and an explicit deny anywhere wins. AWS sets out that evaluation logic, and recommends SCPs and RCPs as organization-wide guardrails. Reading a single policy therefore never tells you what someone can do.

Infomaniak Public Cloud has one level: the project. Nothing above it hands rights down, nothing below it subdivides them, and each OpenStack user belongs to a single project. Separation is achieved by creating another project, not by narrowing a scope. The Public Cloud user guide confirms the separation and the one-project limit.

Getting in, and staying privileged

Sign-in conditions belong to the identity provider on all four platforms, and authorization decides what happens afterwards; confusing the two produces narrow roles reached through a badly protected login. The real difference between the four is how long an administrator stays an administrator.

Google Cloud has Privileged Access Manager: a right issued for a fixed period, with a justification and, if you want, an approval. Google documents it.

Azure has Privileged Identity Management: the person is eligible for a role rather than holding it, activates it for a limited time with a reason, and can be made to pass an approval and multi-factor check. It needs Microsoft Entra ID P2 or Entra ID Governance, licensed for the people who hold eligible or temporary rights and for their approvers and reviewers, not per role definition. Microsoft describes the controls and the licensing categories.

AWS starts from short-lived credentials: a human federates through IAM Identity Center and assumes a role for a session, so nothing durable is handed out. What AWS does not ship is the request-and-approve workflow around it. On the question of raising a right for an hour and taking it back, its documentation names validated partner solutions rather than a feature of its own: Apono, CyberArk, Okta Access Requests and Tenable. AWS says so on the IAM Identity Center page.

Infomaniak has nothing of the kind: a Keystone role stays until someone removes it by hand, with no approval, no expiry and no review documented. Two-factor authentication protects Manager across the Organization, and OpenStack users can enable a time-based code for Keystone, which stops a stolen password from opening a session and changes nothing about the role behind it. Infomaniak documents two-factor for the Organization and the TOTP procedure for Keystone.

How a program authenticates

Inside Google Cloud, a program uses a service account attached to its resource and receives a short-lived token; outside, Workload Identity Federation exchanges proof from AWS, Azure or GitHub for short-lived Google credentials. The downloaded JSON key is the thing to avoid: whoever copies the file acts as that account until it is disabled, and an organization policy can forbid creating keys at all. Google separates attached, federated and external cases.

Azure managed identities obtain an Entra token with no password, certificate or key stored anywhere. A system-assigned identity lives and dies with its resource; a user-assigned identity outlives it and can serve several, so its owner and its scope deserve more attention. An external deployment system can present a federated credential instead of an application secret. Microsoft explains both types.

AWS delivers the credentials of an IAM role straight to the compute service, so nothing long-lived reaches an application running on EC2 or Lambda. Outside AWS, three documented routes: IAM Roles Anywhere with an X.509 certificate from your own PKI, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity for a CI platform holding a JSON web token. Long-term access keys survive only for named exceptions. AWS states the rule for workloads.

Infomaniak issues an application credential: the program gets its own identifier instead of borrowing a person’s password. The creation command accepts an expiry date, access rules restrict it to precise services, methods and paths, and the secret appears exactly once. A monitoring job can receive GET on the path that lists servers, and nothing else. Infomaniak documents the expiry and the single display of the secret.

The evidence you can produce afterwards

All four tell you who holds a right at present. They differ on what they tell you about last March.

Google Cloud lists current holders through Policy Analyzer, with no promised refresh delay and no coverage of mechanisms outside authorization, so read it as a state rather than a history; Cloud Audit Logs carry the administrative operations, and some data-access logs need explicit activation. Azure adds access reviews that make an owner confirm a need before the refused rights are stripped, and keeps the activity log 90 days unless you export it. AWS generates a tightened policy from what CloudTrail actually recorded, and its last-accessed information exposes the roles and credentials nobody uses any more. Google states the Policy Analyzer limits, Microsoft the reviews and the activity log, AWS its own practice.

Infomaniak lists OpenStack users, their roles per project and the application credentials: the rights that existed the day you exported them, and no more. The terms promise instance event logs and one year of retention for the actions of Infomaniak’s own administrators, and leave the evidence from your systems to you. No ready-made historical report covers Keystone rights, so an organization that must show the state of access on any past date builds that export itself, and validates its fields and retention before signing. Article 7 of the Public Cloud terms sets those limits.

The Infomaniak gap, stated plainly

People and organization

Company directory

Employment status and job groups

Enterprise SSO and SCIM

Sign-in and account provisioning for supported Infomaniak services

Infomaniak Manager and kSuite

Organization, contract and product administration

Infomaniak documents no automatic provisioning of OpenStack accounts from the company directory. A departure must therefore remove each OpenStack access separately.

Public Cloud infrastructure

OpenStack / Keystone user

A separate account created for one project

Role and project

Reader, member or a specialized role

Public Cloud project

Servers, storage, network and technical commands

Infomaniak Public Cloud runs on OpenStack, and the terms in force state that customer data stays exclusively in Swiss data centres that Infomaniak owns. That, plus a documented and widely used infrastructure API instead of one vendor’s own, is the real gain: Swiss residency and portability. Infomaniak presents the platform and the contract states where the data sits.

Sovereign does not mean safe by default, and four things you can do on the other three platforms have no equivalent here.

One person, two accounts

Manager and kSuite hold the contract and the products; OpenStack holds the cloud identities, and Infomaniak states that the two populations have nothing to do with each other. Single sign-on and automatic provisioning through SAML 2.0 and SCIM 2.0 exist in the kSuite Enterprise offer only, and nothing published says SCIM touches Keystone accounts. Every arrival and departure is therefore two operations, and forgetting the second leaves a working cloud account behind a closed directory. The comparison reserves the feature for Enterprise and the SSO guide names the compatible providers.

A second project is not an authorization boundary

It separates production, staging and distinct clients usefully enough, but a sufficiently privileged Manager account still administers the Public Cloud product and every project under it.

The published roles are the roles you get

Infomaniak publishes reader, member, SwiftOperator, creator and load-balancer roles, and the current identity guide documents no way for a customer to define new Keystone roles. Their behaviour also changes by region: in dc3-a the documented reader includes permissions equivalent to member, while in dc4-a member does not automatically carry reader. Test one allowed action and one forbidden action in the region you actually deploy to. The identity guide lists the roles and the services they cover.

Nothing is backed up for you

The Public Cloud terms state that Infomaniak creates no automatic backup of customer data. Recovery needs a writing account that cannot delete retained copies, at least one copy under credentials the production administrators do not know, and a restore that has been run and timed. Infomaniak offers Swiss Backup; configuring and testing it stays with you.

Choosing between them

Infomaniak suits a small company that wants Swiss residency, OpenStack portability and a Swiss-law contract, over a limited number of projects, and that accepts doing by procedure what the others do by product: two lifecycle operations instead of one, privileged roles removed by hand, evidence assembled itself.

Google Cloud and Azure suit a company that needs privileged access to expire on its own and sign-in rules tied to the state of the device. AWS suits one willing to treat the account as the unit of separation and to buy or build the approval workflow, in exchange for the strictest guardrails of the four: an SCP caps a whole branch of the organization whatever a local administrator grants. Anyone with hundreds of projects, or an obligation to reconstruct rights at any past date, should price that work before comparing subscriptions.

Sources and verification dates

• Google Cloud: hierarchy and inheritance, IAM overview, Privileged Access Manager, workload identities, Policy Analyzer limits.
• Microsoft: Azure role assignments, emergency elevation, PIM, Entra licensing, managed identities, access reviews, activity log.
• AWS: IAM security best practices, policy evaluation logic, temporary access elevation.
• Infomaniak: Public Cloud, Public Cloud terms, Public Cloud users, kSuite pricing, SSO and SCIM, Keystone identity and roles, TOTP, application credentials, two-factor authentication.

I checked the Google Cloud, Azure and Infomaniak claims in the providers’ documentation on 26 August 2026, and the AWS claims on 3 September 2026. Features, role definitions, licence tiers and prices change after those dates.