An account receives broad access to finish a deployment and keeps it afterwards. The team hesitates to revoke it because a program may still rely on those credentials. Assigning a role has not established its lifecycle.
Consider an organisation with production and staging, a supplier engaged for three months and a deployment pipeline. It must define the resources each may control and the evidence needed when access ends. Four platforms offer different mechanisms for these same decisions.
1. Define the scope of authorisation
Cloud control-plane permissions govern infrastructure provisioning and configuration changes. They also control identity administration. Access to records inside an application is configured separately through that application’s roles and permissions.
Google Cloud organises resources under an organisation, optional folders and projects. Permissions assigned above a resource can apply below it. The team examines direct and inherited access with relevant conditions and deny policies. Google documents this hierarchy.
Azure distinguishes Microsoft Entra directory roles from Azure RBAC resource roles. Directory administration and resource administration follow different scopes. A role in one system does not automatically describe access in the other. Microsoft explains role assignments and scope.
AWS uses accounts as an important boundary. Organisation SCPs and RCPs can limit permissions without granting them. Effective access depends on the relevant policies and request context. An applicable explicit deny prevails, but one general union-and-intersection formula does not explain every case. The team follows the AWS evaluation rules for the tested scenario.
Infomaniak Public Cloud organises OpenStack users by project. Those identities differ from Manager accounts administering products and contracts. Two projects do not remove the powers of an account with broader product-level administration.
Across all four platforms, groups describing people and groups describing an application permission make assignments easier to read. The chosen role must allow the required work without unnecessary actions. Exceptions need an owner and review date.
2. Limit privileged access in time
For the supplier in our example, authentication checks sign-in and authorisation determines actions. Strong authentication alone does not limit how long the supplier can administer production.
Google Privileged Access Manager organises temporary access with the chosen request and approval conditions. The team defines role and scope, including duration and approvers.
Azure Privileged Identity Management can make a person eligible for a role and control activation. Reasons and approval may accompany an additional authentication requirement. The PIM controls and licence requirements need checking for the people involved.
AWS provides temporary sessions and credentials. That does not by itself describe the workflow granting additional privilege. IAM Identity Center documentation discusses temporary privileged access and partner solutions. The organisation selects a process it can operate.
Infomaniak documentation does not present the same integrated temporary-activation arrangement for Keystone roles. Explicit removal and verification may need to be organised separately. A function not documented should be clarified with the provider when material to the project; this does not establish that no supplementary control can be built.
Emergency access needs a tested path back to normal conditions. An unmonitored rescue account can undermine controls applied to ordinary administrators.
3. Give programs their own identity
A deployment pipeline should not depend on a staff member’s personal account. Its identity records the required actions and resources, with an owner and removal conditions.
Google service accounts attached to resources can obtain tokens. External workloads can use Workload Identity Federation under configured trust conditions, potentially avoiding a distributed long-lived key. Google distinguishes workload identity types.
Azure managed identities remove the need for an application to store and manage its own authentication secrets. System-assigned identities follow their resource’s lifecycle. User-assigned identities can survive and serve multiple resources, which changes ownership and removal considerations.
AWS roles can provide temporary credentials to compute services. Federation and IAM Roles Anywhere address other environments. The choice depends on available identity and trust relationships. Any lasting key needs a justified purpose and a managed renewal process.
Infomaniak offers OpenStack application credentials, avoiding a person’s password in a program. The team checks assigned roles and expiry. Access rules can restrict services and API methods or paths. The secret needs appropriate storage because showing it once does not create a recovery copy.
A dedicated identity does not guarantee minimal privileges. The test executes a necessary action and attempts one that should be refused. A backup job, for example, must distinguish creating copies from deleting retained ones according to the chosen protection scenario.
4. Connect access with history and removal
An inventory describes present permissions. It does not automatically reconstruct an earlier date. The organisation distinguishes assignments and sign-ins from resource operations, then defines the evidence it needs.
Google offers policy-analysis tools and Cloud Audit Logs with specific scope and activation conditions. Policy Analyzer’s documentation explains the limits of its results.
Azure distinguishes directory logs from resource activity. The Azure activity log has limited native retention that exports can extend. Access reviews organise confirmation of continuing need.
AWS CloudTrail and usage information help investigate access and adjust policies. Evidence still depends on the services and event categories actually collected. Activity history does not replace a complete permissions inventory.
For Infomaniak, the organisation examines user and role lists along with application credentials, then the events available by service. Provider-administration logs and records from its own applications answer different questions. Public Cloud terms help establish that division.
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
The diagram separates Manager, kSuite and OpenStack identities so each access path can be checked during account removal. Infomaniak’s identity documentation documents regional role differences. In dc3-a, reader includes permissions equivalent to member, while in dc4-a, member does not automatically include reader. Permission tests therefore use the deployment region.
Compare the operating work required
The platform decision can now use common requirements rather than isolated feature names.
| Decision | Google Cloud | Azure | AWS | Infomaniak Public Cloud |
|---|---|---|---|---|
| Scope | IAM hierarchy and inheritance | RBAC scopes and separate directory | Accounts and policy evaluation | OpenStack projects and product administration |
| Temporary privilege | PAM | PIM under applicable licensing | Sessions and a defined elevation process | Removal and checks using available functions |
| Workloads | Service accounts and federation | Managed identities and federation | Roles and federation | Application credentials |
| Evidence | Policy analysis and logs | Reviews and directory/resource logs | CloudTrail and access analysis | Inventories and service events, with additions as needed |
The organisation estimates the work required to meet its requirements, whether through a native function, an added tool or a maintained procedure. It checks licensing and evidence collection alongside its capacity to keep those arrangements running.
Swiss residency and OpenStack interfaces may favour Infomaniak for a particular project. Integrated governance mechanisms elsewhere may address different needs. In every case, the team must verify access actually granted and withdrawn.
For the supplier in the example, the access review verifies the authorised resources and expiry of privileged role assignments. It also checks the pipeline’s service identity and confirms account removal when the assignment ends. Applying these checks to each provider makes the four architectures comparable.
Functions and offers can change. Design should use the documentation for the selected services, regions and licence tiers at deployment time.