Cloud Resources
This feature is only available from >= v0.4.0 releases
Terranetes supports two interfaces to provisioning cloud resources; Configurations which are the legacy implementation and the CloudResources. While Configurations provides a one-to-one mapping to the Terraform module, CloudResources takes a more managed approach. Rather the exposing the entirety of options to the consumer, CloudResources pick and choose which attributes are exposed, thus reducing the heavy lifting by the users and well and ensuring options do not diverge from a known path.
Note, while the user facing interface is the CloudResource, a managed Configuration is created by the controller as the implementation detail. You can think of CloudResources as a means of creating a managed Configuration.
What are Revisions?
Revisions are the templates for CloudResources, each of these are versioned assets which has been curated and tested against, containing the defaults the organization requires and exposing only the functionality which is contextual. The basic gist is;
- Revisions point to a terraform module.
- They contain all the default options which the platform wants defaults to in the module.
- They contain all the options which they want exposed to the consumer.
- Versions can track the upstream terraform module, or move independently of it.
- All CloudResources reference back to a Revision in the cluster.
- To upgrade a CloudResource consumer update the Revision it points to.
The following depicts the relations between Plans (a collection of Revisions), CloudResources and the Configuration it manages.
Revision specification?
Revisions are made up for three sections
Plan
Describes the metadata associated to the Revisions; the version, description, categories and so forth.
spec:
## Defines we are a member of a package
plan:
## Is the name of the package we are a part of
name: fake
## Is a collection of categories
categories: [mysql, aws, fake]
## Is a description for what this plan provides
description: Provides a dummy terraform module for testing
## Is the version of the package
revision: v0.0.3
- name: is probably the most important field here, as all Revisions are grouped by this field. Revisions with the same
spec.plan.nameare logically grouped into a Plan. Plans order these Revisions using semvar. So when a CloudResource references a Plandatabase, without specifying a version; it looks up the Plan and retrieves the latest version. If it specifies a version, it looks up the Plan and checks a Revision of said version exists. - categories: is a collection of tags associated to the revision, these are user facing and largely used for searching.
- description: provides a human readable description of the intended use for the Revision
- revision: is semvar version associated to this revision.
Inputs
Inputs are the options the platform team want to expose to the consumers.
spec:
## Is a list of inputs the user is permitted to override
inputs:
- key: sentence
description: Is a sentence we want to print
required: true
default:
value: hello from second additional
- key: vpc_id
description: Hello
- key: list
description: A list of names
default:
values: [a, b, c]
- key: (required) maps to the terraform variable within the module the Revision is backing.
- description: (required) provides a human readable description to the variable.
- required: (optional) indicates if the user MUST specify a value.
- default.value: (optional) can be a string, number, list or map and is used as the default value for the variable.
Configuration
The last section is provides a template to the Configuration, determining the module source, default values, enabled features and so forth.
spec:
configuration:
## Using a public repository
module: https://github.com/appvia/terranetes-controller.git//test/e2e/assets/terraform/dummy?ref=master
## Where to write any secrets
writeConnectionSecretToRef:
name: outputs
Thus the managed Configuration at the end is a combination of this section plus the optional inputs from above.
How to create Revisions?
By hand of course, a Revision is nothing more standard CRD; however using the tnctl create revision command.
tnctl create revision https://github.com/terraform-aws-modules/terraform-aws-rds?ref=v5.9.0
How to validate a Revision?
Part of the responsibility model of using CloudResources is passing a known and tested asset to the consumer. Terranetes tries to make this workflow simpler by using the tnctl verify revision.
$ tnctl verify revision revision.yaml
? Input identifier is a mandatory input, what should it's value be? test
🔰 Validating Revision Syntax
▫️ The Revision CRD is syntactically correct with no errors found 🟢
🔰 Validating Revision Specification
▫️ The Revision does not have any categories defined 🟠
▫️ The Revision has a description defined 🟢
▫️ The Revision has the default description defined 🟠
▫️ The Revision has a changelog defined 🟢
▫️ The Revision has the default changelog defined 🟠
🔰 Validating Revision Inputs
▫️ Checking input: backup_window 🟢
▫️ Checking input: allocated_storage 🟢
▫️ Checking input: identifier 🟢
🔰 Retrieving Checkov Version
▫️ Discovered Checkov version: "bridgecrew/checkov:2.3.291" 🟢
🔰 Retrieving Terraform Version
▫️ Discovered Terraform version: "hashicorp/terraform:1.5.6" 🟢
🔰 Validating Module Policy permits Revision
▫️ Found 1 module constraint policies 🟢
▫️ Revision is not permitted by any policy 🔴
🔰 Validating Cloud Credentials Provider
▫️ Checking if we providers associated with the revision 🟢
▫️ Provider referenced exists in cluster 🟢
🔰 Validating of Context References
▫️ Revision does not reference any values from context/s 🟢
🔰 Validating against Checkov Security Policy
▫️ Checkov is using the code, not the plan, consider --use-terraform-plan 🟠
▫️ Found 1 security policies to validate against 🟢
▫️ Revision has passed 18 checks in policy: "checkov" 🟢
▫️ Check ID against documentation: https://docs.bridgecrew.io/docs 🟢
▫️ Ensure that RDS instances have Multi-AZ enabled 🔴
Check ID: CKV_AWS_157
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure that RDS instances have performance insights enabled 🔴
Check ID: CKV_AWS_353
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure that respective logs of Amazon Relational Database Service (Am 🔴
Check ID: CKV_AWS_129
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure that AWS database instances have deletion protection enabled 🔴
Check ID: CKV_AWS_293
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure that RDS instances has backup policy 🔴
Check ID: CKV_AWS_133
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure that enhanced monitoring is enabled for Amazon RDS instances 🔴
Check ID: CKV_AWS_118
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Ensure CloudWatch log groups retains logs for at least 1 year 🔴
Check ID: CKV_AWS_338
Resource: module.main.module.db_instance.aws_cloudwatch_log_group.this
▫️ Ensure RDS instance with copy tags to snapshots is enabled 🔴
Check ID: CKV2_AWS_60
Resource: module.main.module.db_instance.aws_db_instance.this[0]
▫️ Revision will fail on security policy: "checkov" 🔴
🟢 Passed: 8, Warning: 4
🔴 Failed: 10
[Error]: revision failed verification checks
The default validation checks the codebase but not the terraform plan. For a more complete validation we'd recommend passing read-only credentials and using the --use-terraform-plan flag, exporting the usual environment variable such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and so forth.