Unified Data Model
Resoto has a unified data model (UDM) with support for static typing and inheritance.
When working with multiple clouds, it can be tedious to what resource kinds and attributes are named. To implement org policies (such as "no unencrypted storage volumes" or "every compute instance must have a cost center tag"), you don't want to rewrite those checks for every cloud provider.
resourcekind defines basic attributes common to all resources (e.g.: name, creation time, etc.).
volumekind defines properties that are common to most storage volumes.
gcp_diskkinds define properties that are specific to AWS and GCP, respectively.
The information whether a volume is encrypted or not comes from a boolean of the volume kind.
When searching for unencrypted volumes,
search is(volume) and encrypted = false will find any unencrypted volume, no matter which cloud they were created in.
You can also perform searches using virtual attributes like
age across all resources without having to worry about provider-specific naming of the creation timestamp.
At the same time, you can still search by cloud provider-specific properties (e.g., AWS KMS Key ID or Google Cloud "last attach" timestamp).
resource Base Kind
Every resource collected by Resoto has the
resource base kind, which defines properties common to all resources.
|Resource identifier (does not need to be unique across all resources)|
|Cloud-specific resource name|
|Resource kind in Resoto|
|Resource creation time|
Resoto uses the time this resource was first discovered when the cloud provider does not provide this value.
|Last accessed time as of the most recent resource collection|
Resoto attempts to synthesize the last access timestamp when the cloud provider does not provide this value.
|Last modified time as of the most recent resource collection|
Resoto attempts to synthesize the last modified timestamp when the cloud provider does not provide this value.
Resoto's resource hierarchy abstracts over data models from different cloud providers to deliver a unified data model that allows for data retrieval across clouds.
Every resource in Resoto has the
resource base kind as its root.
Resoto also introduces abstract model classes for different resource types, making it easy to query and reason about common data.
aws_ec2_volumeinherits from the base
volumekind, which itself inherits all properties from
aws_ec2_volumehas all properties of
resource, in addition to its own properties:
gcp_diskis also a volume.
A Google Cloud Disk resource is conceptually similar to an AWS EC2 Volume and the two resource types have many properties in common.
Supported Resource Types
Resoto has built-in support for resource types from the following cloud providers:
Amazon Web Services
See How to Collect AWS Resource Data for step-by-step directions to configure Resoto to collect Amazon Web Services (AWS) resources.
See How to Collect DigitalOcean Resource Data for step-by-step directions to configure Resoto to collect DigitalOcean resources.
See How to Collect Google Cloud Resource Data for step-by-step directions to configure Resoto to collect Google Cloud resources.
See How to Collect Kubernetes Resource Data for step-by-step directions to configure Resoto to collect Kuberenetes resources.
For a list of available kinds, you can use the
kinds CLI command:
To view the properties of a specific kind, use
> kind aws_ec2_volume
- name: id
Complex and Simple Kinds
We have looked at complex kinds so far: a complex kind has a name and a set of properties.
Each property has a name and also a kind. The kind of such a property can be a complex or a simple kind.
There are several simple kinds that are available in Resoto out of the box:
|any of the above *|
* The special type
any is only used in scenarios where the type is really not known and could be anything. Coercing is not possible for such a type.
Since Resoto uses JSON in order to exchange data, all the different simple types have to be expressed as simple type.
Resoto also introduces some additional simple types like
date. The reason for this is the ability to coerce proper values from values given to Resoto.
Assume a user wants to query a resource by creation time.
According to the model, we would need to filter for the
ctime property. Since Resoto knows the type
ctime (which is of kind
datetime), it can interpret the value given by the user.
> search ctime < "2018-09-28"
ctime is of type
datetime values in Resoto are always stored as ISO-formatted datetime strings, so
"2018-09-28" is coerced into a valid
datetime. Depending on the server time, the value would be evaluated to something like:
> search ctime < "2021-09-28T22:00:00Z"
This also allows the usage of relative times. If we want to query resources that have been created in the last 3 days, we could express this with a relative datetime string:
> search ctime > "-3d"
"-3d" using the current server time into a valid datetime string.