this is a great point. I've been following your work decently closely but this is the first time I thought about the "hostable" vs "non-hostable" differentiation. And thinking more deeply on it, of course it matters. There's a pretty big distinction and, naively, perhaps their attempt to protect TF Cloud with this doesn't even accomplish what they intended for it to accomplish. If the backend part is the thing...that was never even in contention, anyway. If this is the case, they only managed to hurt the community.

Architecturally, I think Terraform really ought to be hosted, because otherwise you have to trust everyone with a far-reaching admin cred on his desktop right next to Zoom and maybe BonziBuddy.

Not if you use "bastion" type hosts, right?

Same issue. Terraform doesn't separate invoker permissions from runtime permissions. It runs with whatever privileges the invoker provides and since it's doing arbitrary privileged things it generally runs with arbitrary privileges.

The only real fix is to run it in a client-server model like a web app where the user has limited permissions and the server gates access to the privileged backend permissions.

Put another way, if I want to create an S3 bucket on AWS, I need S3 CreateBucket privileges, not "run Terraform" privileges.

Ideally, wouldn't your configuration be checked in and only executed by a runner of some kind?

That’s pretty close to what I meant by hosted Terraform.

Yup

Don't grant privileges to users that should not have those privileges?

The gating here is at the cloud level...

A small counterpoint:

My $DAYJOB's architecture is completely self-hosted (Proxmox, Nomad, etc). I would not prefer to have some external tool managing that infrastructure.

Or you can give people enough permissions to plan but not apply and leave applying to a restricted set of users...

Also you can have laboratory cloud subscriptions seperate from production, where devs have full permissions.

That's tricky since the state file frequently contains secrets. You can try to keep secrets out of the state file but that's largely provider/resource dependent. For instance, if you create an AWS RDS Postgres database, the state ends up containing the resource password. If you allow only plans, users can still access the password in the state file.

For RDS you can change the password after creating the DB, or use the SecretsManager integration. There are similar workarounds for other providers and resources. I use TF without storing secrets in the state file (providers: AWS, kubernetes, helm, onepassword, datadog, auth0, and more).

You can exfiltrate secrets that aren't in the state, but are in accessible resources during a plan using an http data source with the secret encoded into the url

stuff like Atlantis exists. it doesn’t eliminate the need for someone/something to have wide permissions, but you definitely can narrow who/what has that access day to day.

It's a repeat of what Elasticsearch did to their community. Basically, their product got forked (Opensearch) and the fork is now popular. Result: access denied on a sizable percentage of new users that start off using the fork and will likely never transition to the closed source thing.

As a sales strategy it's dumb. I see this as an Elasticsearch/Opensearch consultant. A lot of people reaching out to me for help with that, seem to now default to starting with opensource, i.e. Opensearch. And since a lot of them are in Amazon (who created the fork) they make that really easy. Those are people who will likely never become Elastic customers.

The same will happen with Teraform. Many new users will default to the open fork. A lot of existing users might migrate to that.

There are some other examples:

- Oracle lost control of Hudson when it became Jenkins. Hudson is now a footnote in history.

- Likewise with OpenOffice, which now rots away at the Apache Foundation. LibreOffice is the main product now.

> It's a repeat of what Elasticsearch did to their community.

Not exactly the same as I understand. Amazon were providing Elasticsearch as a service with nothing in return. Fair enough (although there did seem to be some issues about alleged ripping off code and trademark infringement).

However as Elasticsearch needed to remain a viable business, they changed the licence.

https://www.elastic.co/blog/why-license-change-aws

I didn't know that any serious non-Hashicorp backends for Terraform existed before this scandal and I wouldn't have considered anything other than Terraform Cloud. The scandal has soured me on Hashicorp and made me aware of the alternatives. I doubt I'm the only one.

If you are on AWS, there is little reason not to use the S3 backend. If Hashicorp insisted on using their backend only, they would be as popular as Pulumi now (which will be another player to gain from this battle).

Pulumi are running ads on Twitter already about how they’ll never change their license.