IAM: There and back again using resource hierarchies

Learning to use the public cloud for your first project can feel like hunting for treasure in deep, hidden dungeons, or battling fire-breathing dragons. There's jargon to learn, cryptic formulas to unravel, and countless ways to get yourself into trouble. Despite charting a course across an unfamiliar landscape, at some level it's also an exciting adventure into the unknown. 

You have ways to make sure that your journey is safe, and to keep all your resources secure, from thieves or (digital) sorcerers. As you explore, you’ll need strong Identity and Access Management (IAM) policies to protect your projects, and their resources, or you're bound to have sneaky brigands running around in your environment.

So can you just jump in and worry about the details later? While you could certainly use a build-as-you-go approach, you probably want to consider the underlying architecture before building that castle of stone, or it could sink into the swamp. Or even worse, it catches fire, crumbles, and then sinks into the swamp. Nobody wants that. It’s important to create a mental model for organizing your cloud resources to properly secure them. 

Using Google Cloud resource hierarchies to create trust boundaries

You first want to start by considering how your business works and then map that to a tree hierarchy in the cloud. At the top is your organization, maybe followed by divisions or lines-of-business, and within each of those are sub-divisions or departments. Finally, you have different teams with principals at the bottom of the tree. This organizational structure should be represented in your cloud hierarchy, because it makes access control using identity management that much simpler. 

Take a look at this example of the fictional continent of Middle-earth mapped to elements of a resource hierarchy. Notice how much easier it is to establish limited access to your most precious resources:

The benefits of using folders

Folders help isolate environments from each other, creating boundaries that work like walls, mountains and rivers separating each area of resources. Besides segregating business divisions, you could also use resource hierarchies to mirror business rules. For example, you could partition production and non-production environments into different folders or separate out a regulated environment to ensure you’re focused on the compliance requirements for that particular set of resources. 

Think about how your resources fit inside this structure and which roles should have access to them. Not everybody gets to be queen (or cloud admin). Some have to content themselves with more limited authority like the duke or countess of a minor principality. Having these borders in place also prevents territorial encroachments that lead to chaos and civil war. Everyone knows their boundaries and an administrator can take comfort in the benefits of peace across their cloud kingdom. 

By creating a hierarchy that matches your organizational structure, you will find that it’s much easier to limit the blast radius of a security issue within your environment by granting rights to grouped roles based on least-privilege and separation-of-duties. Resource hierarchies will also allow you to delegate more easily without having to assign rights to individual principals or roles. This approach demonstrates how identity becomes the key to access control and risk reduction in the cloud (or Middle-earth).

Remember, access is inherited in a resource hierarchy. You will need to consider what global restrictions you require for certain roles across your organization. For example, are there some access limitations that you want for marketing, but not engineering? By default, resource hierarchies have transitive inheritance, so you must be explicit if you want to disallow access to a principal that has inherited certain rights.

Landing Zones can simplify your efforts

You don't have to build it yourself from scratch. If this all feels overwhelming to design and implement, Google Cloud’s Architecture Center has a design concept called Landing Zones to assist you with the implementation. 

Landing Zones represent modular architectural patterns that can provide configuration guidance as you build out your secure cloud infrastructure. They encompass multiple architectural domains, including identities, resource hierarchies, networking and security. By using Landing Zones, you can create a thoughtfully designed architecture that meets your organization’s immediate needs with the ability to scale in the future.  

In summary, to get started with resource hierarchies, you’ll need:

• Google identities

• IAM policies

• An Organization (folders are optional)

Now is the time to improve the security of your cloud infrastructure by using the robust capabilities found in Google Cloud’s identity management tools.  Whether it’s a new quest or you’re trying to bring some sanity and peace to your existing environment, using resource hierarchies can help you evolve your infrastructure kingdom to achieve secure-by-design through strong identity-based access control.