This seems like a simple question. A simple question, which is often asked by members of the finance department. It’s just a list of the cloud services and resources being used to support our software. It’s a good question, what resources are being used by whom, and how are the resources configured. 

It sounds like this list of cloud resources might be useful to our finance team to an auditor. 

What are our cloud resources? (And how are they configured?) It’s a deceptively simple question with challenging answers. 

DevOps and IT departments should be able to provide an inventory list including configuration properties. Teams strive to do this well, or may already do it because

• They have infrastructure as code (IaC) approach exclusively and are able to provide the configuration files
• They have cloud inventory management practice in place keeping track of inventory and resources that have been acquired over time

If your team can answer this question right away and give you a ready list and properties, then your organization is in top shape, because your DevOps/IT department either

• is using an infrastructure as code approach exclusively
• has good practice in place regarding keeping track of which inventory has been acquired over time.

How does a DevOps/IT team build a list of cloud resources? 

Our team was excited to see an announcement from Google Cloud of functionality that makes it easier for Dev, DevOps and IT teams to generate a list of resources used in projects, folders or organizations. This provides an automated way for developers to generate a list of resources and properties in a format that can be used by DevOps and IT as part of IaC but can also be used by others including finance and audit. 

How does your team build a list of cloud resources?  

Build a list of cloud resources 

Interacting with the resources and services of your cloud provider is done usually in two ways

1. Via a web console
2. Via a CLI

Then, it all boils down to two sub-problems, which we discuss in the next subsection. 

1. Listing all resources

There is no single answer. It is straightforward and unique for every cloud provider.

For AWS, you can get all resources in the “Resource Groups & Tag Editor”, by opening the “Tag Editor” and pretending to be interested in adding tags. This part lets you list all resources and export them as CSV. This is not an intuitive spot. Furthermore, it will also be a long list as every snapshot is appearing in that list as well. When you use the CLI, you may use the

aws cloudcontrol --list-resources

command, but you need to specify a type to get the requested resource.

For Azure, one can use the Azure CLI and type

az resource list

command. But: It will only export the respective region that your configuration sets. To get all of them, you need to run it multiple times with different regions.

Google Cloud is the only cloud provider that makes it simple in a single command:

gcloud asset search-all-resources

Generating a list of resources for each provider has been solved. There are challenges with the portability of configurations across cloud providers and specific challenges to be aware of relating to the limitations and region-dependency.

2. Getting the configuration setups

Once you have a list of resources, you need to document the configurations. This section builds on the list of all your resources.

Is each resource configured? 

Depending on the size of your infrastructure, you may have hundreds of entries that you are now looking at, and automation is inevitable.

And for each resource, you may not be able to get all information in one go. Take for example AWS EC2. You may run

aws ec2 describe-instances

The output will be a JSON, and in between there are references to other resources, such as VPC ids or EBS volume ids. You would need to run follow-up commands to retrieve those. And each resource is different.

You see that this problem very quickly becomes exponential if approached in a brute-force manner.

How to build a list of cloud resources & configs?

The answer lies in the remark at the beginning of this article: Infrastructure as code. Since you are still reading, this did not apply fully to your organization.

‍

If you do not have your resources codified, there is a way to export them into the popular Terraform format, using the following open source project: https://github.com/GoogleCloudPlatform/terraformer

‍

We have tried it with a variety of different cloud providers (Amazon, GCP, Azure, AliCloud, and others). Terraformer works well. Special attention needs to be paid if you are using multiple regions. We have needed to export region by region, which is a fairly short iteration given that each cloud provider’s region list is fairly limited (each has under 50 regions). The resources can be acquired via wild-card notation, which makes it very simple.

Key Insight - Use different folders for each region

Here is an example command for getting all AWS resources exported as Terraform for the ca-central-1 region:

terraformer import aws --resources=* --regions=ca-central-1

Be aware, the Terraformer will overwrite the folders and files for each region. 

Terraformer will create a folder called `generated`, and its subfolders are of the form `aws/<RESOURCE_ID>`, where `<RESOURCE_ID>` is the respective resource. Each subfolder contains one or more terraform files.

Hence, you will retrieve all information about your cloud configuration into a single folder.

Altering the –path-pattern parameter will allow the addition of region data.

terraformer import aws –resources=* –regions=ca-central-1 –path-pattern=
{output}/{provider}/{regions}/{service}

What to further do with this information?

Terraformer provides a method across providers to extract resources and configurations in a file system structure with tf/json and tfstate files. With all of your resources exported as TerraForm files, you’re on the beginning of your journey to become  a 100% IaC organization. The TerraForm files can be added into your code repository, and start allowing updates only via alteration of these files. You may discover even resources you own which you are not even using and maybe paying for.

This export also enables you to run common security scanners such as CoGuard on the TerraForm files and their underlying application, dependencies and containers. This will help prepare your organization to be ready for security audits. 

Furthermore, you can now go a level deeper and discover which applications are running on the specific resources and extract further, scannable, information there. By the end, you have a close to complete overview of your cloud configuration landscape.