Defining organization/ resource hierarchy on Public cloud platforms

Most of the public cloud vendors offer free tier to begin with which allows individuals to try out different service offerings and in the process learn them. This is good as far as trying and testing out the things. What happens when you try to set up an account and organize resources for your organization. Can you really go with the same approach that you use for a free tier account ? The answer is No.

It needs a set of disciplines and guidelines to design and set up an enterprise account for any cloud vendor. One needs to understand different factors, such as -

• Use case for using such account
• Usage level
• Organization policies and compliance needs
• Target audiences etc.

Motivation behind this article to help all those who want to understand how to go about Organization account provisioning and things to consider while doing so. A word of caution: use this article as guidelines and implement whatever best fits your needs. It is not necessary that all the things mentioned here fit your bill.

We will talk about four major public cloud vendors (at least I am aware of) while discussing the best practices so that it will be easy to understand for everyone out there.

Mechanisms to define organization hierarchy

A general requirement for any enterprise is to organize its resources and projects into a logical order. Public Cloud providers provide differing mechanisms to achieve this requirement. In a typical cloud computing platform Organization or Enterprise node is the top most entity which acts as parent for all other entities or resources getting on boarded down the line. This is the node which governs and controls actions occurring down the line in the hierarchy.

The terminology differs from one vendor to another, for example in AWS we have a root organization node at the top followed by Organization units below it. In GCP, we have folder resources parented by an organization node. Here is a comparison chart below -

This brings us to the topic of inheritance model followed by cloud vendors which is usually top down. However, there are some exceptions to it. For example, in the case of IBM (as on date of writing this article) an organization node only used for maintaining billing, applying subscriptions credits etc.

Factors to consider while defining organization hierarchy

With that in mind, let’s look at some of the factors to consider when defining organization/resource hierarchy for the public cloud vendor of your choice — Authentication and User management,Remediation approach and policy enforcement,Network layout,Access/Permissions inheritance and Billing.

1] Authentication and User management -

We do not need to emphasize how important this is to decide the authentication process for your cloud account. Most of the cloud providers have IAM (Identity and Access Management) as a separate service which takes care of user management and helps you define the authentication, authorization part. There are two preferred approaches to implement IAM -

a. Local user management — This is the most basic and easy way to set up user management. This includes creating and maintaining users, groups, policies, roles using above mentioned services. The advantage of this approach is to onboarded your users as quickly as possible and maintain separation of concerns. The downside of this approach is it involves a lot of manual work based on incoming users or leavers of your organization.

The second major drawback of this is defining and maintaining a separate user management process for the new cloud platform you are adopting. Just think about an organization with 5k to 10k users dealing with 4–5 different cloud vendors. How tedious this can get especially when something goes wrong with respect to permissions, cyber attacks, cross vendor resource sharing, etc

b. Federation — IdaaS (Identity As A Service) provides a managed solution to maintain your organization database. Some organizations may opt for using existing Identity and federate it to authenticate users in the cloud platform. Diagram below depicts an example implementation.

For example — Microsoft Azure AD offers capabilities such as Password Hash Synchronization or Pass through authentication through Azure AD connect which one can decide to authenticate against on premise (existing AD) or store the passwords of users into Azure active directory and synchronize them with existing AD whenever changes occur. Another example could be AD connect offered by AWS to synchronize the AD objects in the AWS cloud. This reduces the authentication call thus provides faster response.

So before you put pen to paper, consider point which will help you get answers to questions such as -

• Will my authentication and user management process support the entire organization or at all level in the resource hierarchy ?
• Will this model be scalable to support other cloud vendors, if added in the future ?
• Will this model be sustainable, seamless and how addition or removal of new components affect the entire authentication process ?

2] Remediation approach and policy enforcement

Here policy term does not refer to policy or permissions related to users. There are some policies which you want to control and enforce at top level (at organization nodes) so that whatever you configure or set will get inherited at the child nodes/entities.

For example — An organization compliance requirement states that no virtual machine will be spinned up using public IP or instance type/SKU of VM machines should not be greater than let say 2 vCPU and 4 GiB RAM. In MS Azure, one uses native policies or defines a custom one and places it at the root management node so that all child resources — management groups, subscriptions, resource groups, resources will inherit this and enforce every user to do so.

It plays a vital role where one wants to design a remediation approach so that even if things go wrong due to unknown reason, a safeguard is present to un-do the things and maintain a standard environment. A perfect example to explain this is to implement tagging of resources. Every resource created (by anyone) should have a set of tags associated with it such as owner name, department/project name, purpose, etc.This is to track the ownership and helps in billing so that invoices can be sent to appropriate departments or projects.

In case the user forgets to do so, have a policy in place which will enforce this and append at least basic tags and send out notification to Administrators of this. Azure and GCP have very mature solutions in place as compared to IBM cloud who is developing a service on similar lines.

In a nutshell when you understand and neatly define policies and remediation approaches for your organization, it helps you mitigate unwanted and unpleasant scenarios (may be intended or unintended one) and maintain a standard and secure hosting environment at all levels in the resource hierarchy.

3] Network layout

Designing a network layout considering current as well as future requirements is an essential part as this is one of the activities which can not be carried out again and again. Hence thorough understanding and detailed discussions with different departments/teams such IT security, Monitoring team etc is must.

Design should also cover your requirements of connectivity to on-premise environments (or may be a second cloud vendor). For e.g. An antivirus server or vulnerability scanner with limited licenses is present in an on premise environment which can be utilized to perform scans in the cloud environment. Hence sharing of such resources at each level in the hierarchy and the manner in which they will be consumed is essential.

Let’s take an example of GCP which offers subnets created in one project (host project) to be shared across multiple other projects (service projects). To enable such sharing across different projects requires permission management in the hierarchy.

Having a detailed discussion with your network team (if exists) will help you layout the network as well as an organization hierarchy for your cloud resource consumption and use the scariest resources such as ip addresses effectively without breaking or affecting existing functionalities.

4] Access/Permissions inheritance

This section is about permissions/ policies associated with user accounts, groups, etc. Permissions/policies applied at the organization node generally gets inherited. However, it is important to understand what the effective policy/permission is for a user when applied at a different level. Consider the below example in GCP.

If a person named Bob is granted Project editor role at folder — Data science dept, he will have editor role on all the projects — A,B,C in the resource hierarchy. In addition to that even if you remove his editor role at project level, he will still get the Editor role inherited from Folder — Data science dept.

However, in the case of IBM that does not hold true. For instance consider the below example.

A permission granted to user A at an enterprise node will not allow him to create or manipulate resources or account level. A user needs to be invited exclusively in order to gain access to that account.

Hence it is absolutely necessary to understand who (user) needs what access (role) to which resource. Refer and understand whether the resource hierarchy provided by a given cloud vendor follows similar hierarchy for IAM policy. This ensures every individual has the right level (a least privilege) access to perform his/her duties.

Hence studying, understanding and defining the level of permissions required at each level (keeping in mind principle of least privilege) will help you define your organization hierarchy which will cater to users’ access demand without discouraging (and hampering) their ease of using cloud resources.

5] Billing -

As mentioned at the beginning of this document almost every cloud provider provides a free tier account to try out the stuff and get comfortable with service offerings.

Apart from free tier, we usually see Pay as you go, Subscription based pricing models which allows you to consume services and pay the bill on a monthly basis or based on your usage.

A billing factor can be controlled using a cost control mechanism which is a focus for every individual or an enterprise as it helps save money which can be better utilized. Different cloud providers provide different structures for setting up billing or applying subscription/credits which can be utilized for resource consumption. For example, AWS has a concept of consolidated billing where in one master account which is also called payer account pays for all the member (linked) accounts. In this way, you have one place wherein you can get a view of all the expenditures occurring in the sub accounts/linked accounts.

This is in contrast to what IBM cloud offers. In IBM cloud, if you have a subscription based model (which is usually suggested for enterprise accounts), a set of credits gets applied at organization nodes (based on an agreement between your company and IBM cloud) which can then be utilized by all the child nodes such as account groups and accounts. A resource quota can be set at individual account level to control the spending by each account. As soon as all the credits are burnt (and you have not requested new credits), your account turns into Pay as you go model.

In the case of Azure, the billing hierarchy is different from the resource hierarchy where it has enrolment, department, account, subscription as described here.

Hence it is absolutely necessary to understand what are the billing options made available by respective cloud vendors and how does it affect your resource hierarchy. Based on that, one can design and implement organization/resource hierarchy to best suit the needs.

Conclusion

Although Cloud providers equip users with mechanisms to organize and control resources at enterprise scale, architects and designers have to consider multiple factors such as Authentication & user management, policy compliance, network layouts, access/permission inheritance and billing to define an optimal design that works well for the organization.