Declaring ressources using Kubernetes

[caspervk]

Hi

We have previously looked into Crossplane to deploy infrastructure as part of our helm chart applications. This includes both external cloud resources, such as a managed database, as well as resources internal to the application, such as auth tokens for the various components.

With Crossplane, I would define a CRD with provider credentials at the cluster level, which would allow deployments to commission external cloud infrastructure as needed, depending on the chart's values. I could even use Crossplane's terraform provider to do this to benefit from the terraform ecosystem.

Could such a use-case be supported by the tf-controller, or is it a bad fit? We have discussed having each chart deploy a GitRepository and associated Terraform resources referencing it. Another solution could be implementing a thin controller which picks up CRDs and exposes them as a pseudo Bucket or GitRepo for the source controller to pick up.

[chanwit]

Another solution could be implementing a thin controller which picks up CRDs and exposes them as a pseudo Bucket or GitRepo for the source controller to pick up.

This is exactly what I'm implementing. We would provide an easy way (reads: a single YAML) to generate a thin controller for GitOps and TF. This feature would be similar to the provider + package concept in Crossplane, but its implementation would be straightforward using the controller framework.

Please let me know what you think about it.

[caspervk]

Could you expand a bit more on your vision?

Crossplane's terraform provider, allowing for in-line terraform, is somewhat of a solution to the issue if paired with Composite Resources (XRDs), as it allows reversing the flow so that each deployment doesn't have the power to define its terraform, but simply references XRDs with pre-defined code. This way, I would be safe to supply the cluster with my cloud provider credentials, knowing that the terraform available to it is limited by the CRDs.

[chanwit]

I have been cooking the idea of having CRDs wrapping around GitOps + TF resources. Similar to Crossplane XRDs, this approach would let us fine-grained control of everything in the scope of Terraform. With this thin controller layer wrapping around GitOps + TF resources, we would not be coupled to specific versions of providers, or versions of Crossplane packages. We would freely upgrade or downgrade versions of any modules, for example.

To sum up, the approach I've been working on would

• provide YAML abstractions similar to XRDs,
• not get in the way when wanted to fine-grained control of TF resources.
• be able to move faster. When new providers or modules are available on Terraform registry, we would add properties to our CRDs to expose those Terraform features directly.

[caspervk]

Thanks a lot for the detailed explanation! Having a terraform-first system that could work both as a replacement for Atlantis and Crossplane at the same time, without involved compilation steps (terrajet), really does sound like an awesome idea!
We have been talking about abandoning Atlantis and Crossplane in favour of integrating more tightly with flux using this controller, and I'm now convinced that this direction is the right one. Really looking forward to the future!

[Skeen]

Is there an ETA for when this functionality will be developed?

[chanwit]

It's planned to start in Q3.

[chanwit]

@caspervk it's last day of Q3 and we shipped this feature in v0.13.0-rc.2.
Here's an example: https://github.com/tf-controller/hello-primitive-modules

[chanwit]

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: hello-world
  namespace: flux-system
spec:
  path: aws_hello_world
  values:
    greeting: Hi
    subject: my world
  sourceRef:
    kind: OCIRepository
    name: hello-package-v4.32.0
  interval: 1h0m
  approvePlan: auto

[caspervk]

Hey! Sorry for the late reply. This looks really awesome! 😄 👍
I originally inquired about this functionality because I am trying to utilise tf-controller in an air-gapped environment. Does this also allow me to bundle terraform provider dependencies inside the OCI image, instead of the proposed solution from #321?

[chanwit]

Hi @caspervk no, we don't have such functionality yet.

But it's really interesting to prioritize the capability to run TF-contoller in an air-gapped environment!

[caspervk]

Okay, fair. I just wasn't sure if I was missing something. It's a fairly rare use-case anyway.
Thanks for the swift reply! Can't wait to see what you have in planned for the future of this project!

[vSivarajah]

This might be exactly what we are looking for aswell. Currently we are exposing developer-facing CR's that are translated into Terraform CR using cuelang. If there are any way to inbuild this logic into tf-controller or make it extensive enough to map an existing custom resource to a terraform custom resource, it would be amazing.

We are experimenting with writing our own controller/operator to translate the developer-facing CRs into Terraform CR.

[artem-nefedov]

We do something like that with Crossplane compositions and kubernetes provider. Crossplane compositions allow you to create custom resources with basically any structure that you can imagine, claims for such resources are then handled by kubernetes provider, which creates Terraform resource in the cluster.