Establish consistent guidelines and guardrails for managing authorization to cloud resources in Landing Zones. Authorization management should consider key principles like segregation of duties, need-to-know and separation of privileged and unprivileged roles.

Resource Authorization Management describes the processes and practices used to grant permissions on cloud resources. As such it is about finding a balance between agility and control for each Landing Zone.

There are two fundamental design approaches to answering this question: Open and Closed Landing Zones.

Open and Closed Landing Zone Designs

Open landing zone designs allow teams to create and modify IAM roles and permissions on cloud tenants. The cloud foundation only enforces a minimum set of IAM policies on the tenant.

Closed landing zone designs on the other hand prevent teams from creating or modifying IAM roles and permissions on cloud tenants. Teams must request all such changes via the cloud foundation team or the provided tooling like Service Account Management.

Benefits and Risks of Landing Zone Designs

Criteria	Closed Landing Zone	Open Landing Zone
Privilege Escalation Risk	✅ Easy to control by scoping role permissions appropriately and avoiding IAM related permissions.	⚠️ Difficult to secure against privilege escalation attacks. Few platforms offer built-in mitigations capabilities (e.g. Kubernetes), others required complex measures (e.g. Azure Policy countering Azure RBAC). Furthermore users can accumulate permissions over time.
Principle of Least Privilege	⚠️ As roles tend to be more generic (cross resources) difficult to implement because user and service accounts often carry too many permissions. Risk of rogue users and automation impacting resources (e.g. unintentionally deleting resources).	✅ Allows teams to create dedicated IAM roles for users and service accounts scoped to the least privileges necessary. Team members working in the same tenants can have different permissions on services and resources. Depending on the platform, "sudo" modes can be implemented by allowing users to assume a higher privileged role.
Recertification	✅ Simplified recertification based on known risk profiles of standard IAM roles. Depending on the implementation of Federated Identity and Authentication across supported cloud platforms, certification of the central IAM repository (e.g. an AD) might be sufficient.	⚠️ Difficult to perform as cloud tenants can have highly individualized IAM roles and assignments on resource level. This makes it difficult to assess risk profiles of individual roles and consider it in recertification processes appropriately.

Key Considerations and Best Practices

• Start with default roles in cloud-native Landing Zones

  Cloud providers typically offer a set of built-in roles that grant typical set of permissions (e.g. Contributor on Azure or Editor on GCP). While a more fine-granular segregation of roles can enable better fulfillment of least-privilege principle, the advantages of centralized oversight and consistency typically outweigh these benefits in the early stages of a cloud journey. Most authorization concepts use 2-3 types of default roles (e.g. Reader, Developer, Manager).

• Use a clear and consistent mapping of roles to groups across all cloud platforms

  Creating "role-groups" with a consistent naming policy like $tenant-$role in cloud platform directories simplifies permission management by reducing the number of permissions assignments necessary (e.g. after Tenant Provisioning). Also, these "role-groups" can be easily integrated with existing IAM infrastructure, see Identity and Access Management Alignment and Federated Identity and Authentication

Related Tools

• meshStack

  meshStack allows operators to define a multi-cloud role model that teams can consume in self-service. meshStack replicates assigned roles and groups to cloud platform directories and cloud tenants.

  Learn More

Did this page help you?