Last updated on February 3rd, 2023 at 5:28pm
As you begin to grow and scale your cloud footprint, you quickly discover why governance is so important. Without governance, it becomes a challenge to:
- Understand who is accessing your cloud environments
- Get a clear line of sight into your organization's cloud financials and set meaningful budget enforcements
- Establish boundaries across your organization to continually monitor and address compliance-related concerns
All of these challenges make cloud governance a necessity. So, how do you get started with cloud governance?
We work with customers who've chosen our solution because we offer all the pillars of cloud governance - Account Management, Budget Enforcement, and Continuous Compliance - in one solution. In this post, we'll share how we help organizations set course and navigate the cloud governance journey. We'll also offer some advice on best practices should you make the journey yourself.
Follow the Money/Set Up Funding Sources
We start by following the money. Specifically, we establish where the money is coming from. These are the Funding Sources in cloudtamer.io, and they are key to the budgeting and cost control aspects of governance.
To get your cloud accounts up and running, you must ensure that there is enough money to fund them. When determining your Funding Sources, it's best to think about the specific funding streams within your organization, like R&D funds or contract line items. From these, you can allocate funds to your cloud accounts. Costs incurred on these accounts can then be associated back to the Funding Source and effectively tracked across the organization.
Establish Organizational Structure
An organizational structure represents the people and functions necessary to achieve your organization's goals. The organizational structure also determines how funding flows between levels within the company. Within cloudtamer.io, we have Organizational Units (OUs), which are building blocks that act as containers for cloud projects and allow you to build out a hierarchy that reflects your company’s organizational structure in the cloud.
While it is important to align the OUs with your organization chart and funding routes, it is also critical to determine the types of cloud account offerings available for users within the organization. For example, we've seen customers offered "sample" cloud accounts with limited funding and capabilities to experiment with before fully embarking on the cloud transition process. These sample accounts should be limited to a small number of people, but sometimes they are more widespread. Make sure you check for limitations on these types of accounts prior to orchestrating the OU structure.
As you design and build out the OU hierarchy, be aware of the pathways and groupings for fund allocation and policy inheritance. "Sample" and real-world cloud accounts are funded differently and must be organized and bucketed accordingly within the OU structure. In addition, accounts within the organization have varying restrictions or policies applied. These restrictions, policies, or cloud-specific resources are called Cloud Rules within cloudtamer.io. Both Funding Sources and Cloud Rules are applied hierarchically and can be allocated or inherited from parent OUs to child OUs and, ultimately, to the cloud accounts. The hierarchy needs to be set up in a manner that aligns with the organization's cloud activities and goals.
Best Practice: Structure your organizational hierarchy based on where funds originate.
Determine Roles & Set Up Permission Schemes
Next we define a standard set of roles and permissions. Within most organizations, there's a variety of user personas within your cloud accounts: Administrator, Manager, Developer, Operation, etc.
We recommend you break these types of roles down even further. For example, a Developer can be a Cloud Developer, a Tester, or a Database Engineer. Defining these roles is an important exercise. Then, you must align the types of permissions these roles will have both within the cloudtamer.io application and from the perspective of the user's cloud environment(s). We also recommend that you document the roles and permissions. This will help when determining how to categorize future users, and having documentation of your process is always helpful in case of personnel changes within your organization.
Best Practice: Provide users with only enough access to perform their job, i.e., use the principle of least privilege.
Align Roles & User Groups
With your roles fully defined, you can now begin to define user groups. First, you should determine each user's placement within the OU structure based on their role in the organization and their cloud needs. When creating each user, you can include information about the type of user and indicate metadata about them (i.e. name, ID, email, etc.). Then you can use the cloudtamer.io application to create OUs and user groups and begin loading in those users.
Here's an example of the suggested steps in practice:
User indicates where their group resides within their organizational hierarchy (the OU structure in cloudtamer.io)
Company A —> Division B —> Department C —> Group ABC
User from ABC Group requests the following types of cloud accounts (each one of the following accounts will reside in a cloudtamer.io project within Group ABC)
1. ABC Group Development (Dev)
2. ABC Group Test
3. ABC Group Production (Prod)
User indicates the different types of users who will be able to interact with the above accounts (in cloudtamer.io individual users are bucketed into their respective user groups)
1. User Group: Manager
Raul Gomez / [email protected] / ID: 2210
2. User Group: Application Administrator
Johnathan Thomas / [email protected] / ID: 5213 /
Bradley Beal / [email protected] / ID: 1256
3. User Group: Developer
Mary Antoinette / [email protected] / ID: 9123
William Taft / [email protected] / ID: 9234
Lawrence David / [email protected] / ID: 9345
Create Projects
As shown in the example above, you create projects in cloudtamer.io under their respective OU. Projects are the smallest unit of organization within the application and they receive their funding from the parent OU directly above them. The parent OU must have enough funds allocated to it to cover the project’s cloud expenses. Additionally, as user groups are aligned to their respective roles at the OU level, users will simultaneously have access to their respective projects, inheriting access (or lack thereof) hierarchically. This inheritance model is a huge benefit as it eliminates the need to edit each individual project repeatedly within an OU and align roles and user groups one at a time.
Provision Accounts
Next, cloud accounts (think an AWS account or Azure subscription) are attached to a project. These accounts can be external accounts that aren't currently managed by cloudtamer.io. In my experience, some customers load in a slew of cached accounts ahead of time, ready to be used as needed. Customers that have a heavy footprint of users requesting new accounts typically favor this option so the onboarding process moves along in a more efficient manner.
Projects are the best place to set up budget enforcements because they are self-contained and give you the most specific control over your organization's money. When explaining to a customer the need for budget enforcements, we typically lead with the question, "Do you want to wait a week or more to discover that one of your users signed into their cloud account this past weekend, spun up a few costly services, and caused your cloud spend to spike significantly?" This is precisely the reason we have the budget enforcement feature built into cloudtamer.io: so that project owners can rest easy by creating actionable enforcements ahead of time to do their job proactively.
Best Practice: Use cloudtamer.io cached accounts to preload your cloud accounts so they're quick and easy to assign to a project upon request.
Establish Cloud Access Roles
Last but not least, we bridge the gap between cloudtamer.io and access to a user's cloud account (i.e., their AWS account or Azure subscription) through the use of cloudtamer.io Cloud Access Roles (CARs). As indicated by the name, a CAR is essentially the ability for a user to log in to their cloud environment. It represents an IAM role that is created in an AWS account or an Azure Role Definition that is created in an Azure subscription. The role has a trust policy that allows cloudtamer.io to provide the user with proper access.
We typically suggest that you align the CAR at an OU level and, through inheritance, it is also available on all child projects below for users that have access to the role. A good use for these roles is for System Administrators, Network Engineers, or Billing Managers that need access to the same services in every cloud account. Again, we recommend documenting your CARs and the roles for which they should be used for maximum visibility of the permissions you've granted within cloudtamer.io.
At this point, based on the user's role and permissions, he or she will now be able to log in to cloudtamer.io and federate into the cloud environment. As this process becomes the norm for onboarding users and providing access to cloud environments, the organization gets confidence around access, budget, and security and compliance in their cloud ecosystem, and the goal of cloud governance is achieved.
Before closing, let's touch on the topic of pilots and training - topics that are worth their own posts. Regardless of how you implement your cloud governance solution - cloudtamer.io, home-grown, or another solution - take a phased approach. Group accounts into categories and phases for user onboarding. Starting with a small selection of innovators and scaling up in complexity through your multi-tenant and production accounts allows you to take time between each phase to evaluate and adjust your onboarding strategy. You don't want to pilot new systems in your production accounts, so it makes sense to start small and with non-production accounts. This approach allows for time before each phase for end user training in smaller groups. This approach also delivers a better chance at success, allows you to learn and iterate, and provides a solid foundation on which to build and scale.
