📄️ Configure Providers
Credentials to access the cloud are represented by Providers in the controller, a cluster scoped resource. When defining a terraform module developers reference a provider using spec.providerRef, tying together the resource and credentials.
🗃️ Define Guardrails
3 items
📄️ Contexts
Contexts provide a means to share common configuration between Configurations. The resource type is Cluster scoped and can be used by any Configuration in the cluster.
📄️ Cloud Resources
This feature is only available from >= v0.4.0 releases
🗃️ Observability
1 item
📄️ Expose Costs
The costs integration allows developers to see their associated costs before applying the terraform. This controller currently uses infracost to extract the predicted costs of a configuration, exposing the cost within the status of the Kubernetes object. It is viewable by running kubectl get configuration.
📄️ Injecting Defaults
Currently via policies platform administrators have the ability to inject both variables and or secrets into developer Configurations, common use cases
📄️ Drift Detection
Drift detection periodically runs a terraform plan on a Configuration, ensuring the expected state (terraform state) and the actual cloud resources are in sync. Currently Configurations must opt in for drift detection via their spec;
📄️ Terraform State
Terraform stores state about your managed infrastructure and configuration. This state is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures. For a detailed understanding of terraform state, please visit the official docs.
📄️ Kubernetes RBAC
The following gives some guidance around the suggested roles and permissions in Kubernetes for consumers. In all cases, to remove duplication, the permissions are defined as a ClusterRole and bound locally within a namespace.
📄️ Customize Job Template
When a configuration is changed (i.e. for plan, apply or destroy), the controller uses a template to render the final job configuration, taking the options provided on the controller command line, custom policies and the terraform configuration itself. A batch job is created from all the options and ordered to execute the change. You can find the default template for this here.
📄️ Additional Secrets
The controller supports the ability to inject additional secrets into the terraform execution. A common use case to provide additional credentials, api tokens or custom configuration into the jobs.