weekly.tf #17 - module security; tf+k8s

The march toward the 0.13 release continues. Meanwhile module security and working with Kubernetes are big topics.

Bridgecrew is a fairly new player in the infrastructure security space.

This report cover analysis of modules in the registry, analyzing them for common security issues. They ran their checkov tool across all modules in the registry, noting violations and analyzed the results based on download counts and provider types.

Here's the thing- I am not surprised. As an active Terraform user I have been consistently disappointed with the quality of open source modules. Heck, I am even disappointed at modules I have written. It is just too easy to prioritize connivence and ease of use over more challenging concerns like security. And once you have written the code it can be hard to refactor and improve things. Good code is not written, it is refactored*.

More coverage of this report here.

I don't know about you, but I am thoroughly excited by this. My team is currently transitioning our workflows to Enterprise and being able to grant more finely grained permissions will make a number of use cases easier to manage.

Terraform + K8S– bad idea or best idea?

A few things about the using Terraform and Kubernetes together. As fitting its role as the most exciting new technology, every other technology is being integrated with Kubernetes.

If you are unfamiliar with the options for using Terraform to manage resources in Kubernetes clusters, this article is good overview. It covers the two Hashicorp-maintained providers, plus a kustomize provider that I didn't know about.

Here's the thing- There is a serious mismatch in the ways that Kubernetes and Terraform work. It is good to see progress here, but I doubt that HCL will ever be as good for managing k8s resources as yaml, as much as a pain it is is to work with yaml.

Side note - this article led me to yet another tool for Terraform workflows.

I clicked on this bait-y headline hoping for a serious argument supporting this. After all, I am a stan.

But it just isn't there.

What is, is an argument for infrastructure-as-code, which can be done via basically any programming language and workflow tool.

Here's the thing- Basically any form of infrastructure-as-code is better than managing infrastructure via ad-hoc means (aws-cli, kubectl, web consoles, etc). You can argue that Terraform is better than CDK, but just like any diet is better than junk food, any systematic automation is going to better than ad-hoc management of cloud infrastructure.

Not an Argo expert, but I feel like it is really becoming the leading (aka buzziest) tool for GitOps for Kubernetes. So it is not too surprising that it would be seeing use for other workflows, like running Terraform.

Here's the thing- Like I said before, automation is better than not automation. Especially in cases where you can maintain an authoritative state model and use a tool to apply that state. This seems like an area whre Argo excels and having a single workflow tool for managing application and infrastructure delivery is appealing.

0.13 stuff

If you maintain a provider like I do, here is a guide for getting your provider docs in the registry.

Yeah so, modules are getting count, for_each and depends_on. Hopefully you have hear this from this newsletter already.

Herein lie examples of how to use them.