Understanding the roles of Workload Identities, Cluster Service Accounts, IAM Policies, and IAM Roles in managing access controls within AWS environments.
Exploring real-world use cases to illustrate the importance of effective IAM policy management in securing multi-tenant environments and aligning access controls with business requirements.
Comparing manual IAM policy management with streamlined approaches, such as Wayfinder's Package Workload Identities, to highlight the benefits of automation and centralised policy management.
Public cloud has provided huge benefits in getting infrastructure and services to people at the click of a button. For everyday users, getting server infrastructure into your hands in minutes really was impossible to imagine only 10 or 15 years ago. But the simplicity of cloud came at the price of unmanaged control leading to spiralling costs and lack of accountability.
One part of the bigger picture is figuring out how to add structure and organisation when providing access to public cloud services to users without hindering agility. The public cloud providers quickly realised the problem of accountability, and provided means to organise access and billing.
Although the public cloud providers have recognised the problems, there is still a gap as to how this fits into your organisation's structure and processes. We will look at best practice cloud account organisation strategies and how these relate to the public cloud capabilities from Microsoft, Amazon and Google clouds.
Organisations often started their foray into cloud with a single goal or a single project. As with all good IT, organic growth provided an ideal breeding ground for complexity. The single project turned into a department or company wide everything on cloud and it became a little unwieldy.
Before long, problems start to appear: large bills came as a huge shock, causing a lot of angst and internal finger pointing, but nailing down where resources are being consumed and costs incurred is a problem. Organisations realised that cloud was something that needed to be tamed and constrained, but didn’t want to lose the awesome agility and capabilities that were provided.
The public cloud providers started to create reference architectures to help customers understand what a well architected cloud looked like. Landing zones became a thing that described your core cloud architecture to bring some order and consistency. A core part of the architecture thinking was how to best manage cloud usage within the organisation through things like multi account strategies and how best to organise your organisation, teams and users to give better control and compliance.
Most cloud accounts start by just taking a credit card and getting on with doing things in the account that was created without thinking about future scaling. This was great for getting things done quickly, but fast forward 12 months and you find yourself in trouble.
Once your use of public cloud increases, managing through that single account becomes unsustainable, posing cost and security concerns. Things users found when scaling with that single account were:
The problems outlined with single accounts become much easier to control when moving away from a single account strategy and into managing your cloud with multiple account and organisation strategies.
Most of the public cloud providers have a set of best practice guidelines around landing zones (setting up your cloud architecture) and organisational structure (setting up groups, users and policies). The high level guidelines generally follow a similar set of high level principles:
An example of using public cloud organisational structures to group policy and control is described below. All of the cloud providers give you a method of creating hierarchical structures to manage the access, control and billing policies that make creating these structures straightforward.
One of the things that is confusing when looking at how public clouds provide account and organisation structures is that none of the three big clouds have a standard way of doing things or even naming things. Account, subscription or project? They sound different but are very closely related depending on which cloud you are using. Here’s a quick overview!
AWS provides a service called AWS Control Tower, specifically to address the needs of controlling AWS accounts and help in orchestrating a multi account strategy.
The core of organising AWS resources and usage lies in two container structures, AWS Accounts and organisational Units.
An AWS account acts as a resource container and resource isolation boundary (this is not the same as a user account). An AWS account is the core concept for providing a segmented controlled place for AWS resources to reside. Accounts are where users or workloads can be monitored and constrained in resource usage and cost control.
The OU is a higher level grouping of AWS accounts which allows you to create an organisational hierarchy making it easier to apply policy and control over a set of accounts. An OU contains one or more accounts and can be used as a logical grouping where a broad set of constraints and policy can be applied.
Microsoft Azure provides a well defined organisational structure hierarchy. Microsoft’s best practice details how to create a landing zone to organise your cloud workloads and resources as well as a best practice guide called a Cloud Adoption Framework.
The top level organisation unit is a management group. Care must be taken in designing which items live within the management group hierarchy as policy and control will be defined at this level and each of the items in the management group will inherit the top level policies.
An Azure subscription is a container under which resources are defined and used. The subscription can be used to define a logical boundary for functions or resources as well as the billing and access policy enforcement points to control:
Much like AWS and Azure, GCP provides organisation through “containers” in a hierarchy to provide:
The Organisation resource is the root node of the Google Cloud resource hierarchy providing central visibility and control over every resource that belongs to that organisation.
Folders are an additional grouping mechanism as organisational units that reside within an organisation. (You are required to have an Organisation resource as a prerequisite to using folders.)
The Google Cloud resource hierarchy, especially in its most complete form which includes an organisation resource and folders, allows companies to map their organisation onto Google Cloud resources providing logical attach points for access management and organisation policies. Both access and organisation policies are inherited through the hierarchy.
Getting your account organisation and structure right is important once you start to scale. Putting a multi account strategy in place is only part of your whole cloud strategy but when implemented, will give you a great starting place to provide the control, compliance and organisation into your use of public cloud.
