A simpler and more secure architecture with built-in Drivers

The Humanitec team is pleased to present new built-in drivers. The Container and Terraform/OpenTofu Container Drivers are now built into the Humanitec Operator, simplifying configuration and increasing security.

What sounds like a technicality has a profound positive impact on the simplicity and security of your Humanitec setup. For the first time ever, you now have a full set of Drivers to completely execute all resource provisioning without sending any data outside your network.

Developer and platform engineering workflows do not change. Humanitec platform configuration actually becomes simpler, and a clearer architectural pattern emerges. You can move over gradually at your own pace. Sounds interesting? Let’s look at the details.

What are Drivers again?

Drivers provide the technical means to provision any resource as part of a deployment. Each Resource Definition defines the Driver to use in its driver_type property. When the Humanitec Operator running in your target Kubernetes cluster handles a deployment, it will call each Driver to provision the resource.

In practice, many organizations will only need a few select Drivers to meet their needs:

• Echo: simple input/output, useful for configs or mirroring real-world resources
• Template: similar to Echo, with more flexibility
• Container: runs a container image you provide. Useful for bringing your favorite IaC tool
• Terraform/OpenTofu Container: like “Container”, preconfigured for convenient Terraform or OpenTofu use

Moving to a self-contained setup

All these four Drivers are now built into the Operator. Provided they are the only ones you use, your infrastructure setup becomes much more self-contained.

Previously, the Operator would have to make calls to the Humanitec Orchestrator SaaS to execute most Drivers.

While being encrypted, these calls still mean data leaving your network. This often involves additional network routing requirements, and means having an external deploy-time dependency.

By switching exclusively to built-in Drivers, these limitations disappear. The Operator acts entirely as a self-contained unit, significantly improving both your security posture and architectural simplicity.

This setup also lets you discard:

• The Authentication for Drivers on the Operator requiring the ongoing maintenance of a public/private key pair
• The use of Orchestrator Cloud Accounts in Resource Definitions to inject credentials and launch provisioning Jobs
• The extra runner config resource required for some non-built-in Drivers

Clear architectural pattern

With promoting these new Drivers, we also move towards a clearer architecture pattern for working with the Orchestrator.

For each Resource CR using one of the built-in Container Drivers, the Humanitec Operator running on that cluster creates a Kubernetes Job that runs a container image to provision real-world resources with your favorite tooling. Here, responsibility for Job creation has switched from the SaaS Orchestrator, outside of your infrastructure, to the Operator, inside your infrastructure.

We can now more clearly categorize the required infrastructure elements.

The Operator cluster is where the Operator runs and receives the CRs. The runner cluster is where the runner jobs are created.

By default, those are one and the same cluster. This setup will work fine for most organizations.

But you can optionally use separate Operator and runner clusters, e.g. to fulfill networking or proximity requirements while provisioning.

Opt-in. No breaking change

The new Driver variants have new ids, so only by setting those ids as the driver_type in Resource Definitions will you start using them.

• humanitec/container-builtin
• humanitec/terraform-container-runner-builtin
• humanitec/opentofu-container-runner-builtin

You need to upgrade the Operator version to at least Helm Chart version 0.13.2 with App version 0.28.2.

In-place Driver updates for Resource Definition are already supported, so you can switch existing Definitions over for a smooth transition. Note that some adjustments may have to be made that will mostly be along the lines of simplification. Please refer to the official documentation for the built-in Container and Terraform/OpenTofu Container Drivers for the details.

What’s next?

We will publish a migration guide for users of the pre-existing Drivers and full examples once we find another minute. We already thoroughly revamped the reference documentation to guide you through each use case.

While the new Driver options are fully opt-in, we hope you find their benefits attractive enough to give them a try and pursue the simplified and more secure setup. As always, you can start small and in a controlled environment with just a single Resource Definition and expand from there.

Enjoy!