News for hackers. Stuff that matters.
Re:HashiCorp Did It Backwards by erik_seaberg on Tuesday September 05, 2023 @07:03PM (#37399013)
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.
Re:HashiCorp Did It Backwards by nightfly on Tuesday September 05, 2023 @07:40PM (#37399357)
Not if you use "bastion" type hosts, right?
Re:HashiCorp Did It Backwards by nijave on Tuesday September 05, 2023 @08:05PM (#37399578)
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.

Re:HashiCorp Did It Backwards by foota on Tuesday September 05, 2023 @08:34PM (#37399825)
Ideally, wouldn't your configuration be checked in and only executed by a runner of some kind?
Re:HashiCorp Did It Backwards by erik_seaberg on Tuesday September 05, 2023 @08:55PM (#37399989)
That’s pretty close to what I meant by hosted Terraform.
Re:HashiCorp Did It Backwards by nijave on Wednesday September 06, 2023 @07:20AM (#37403573)
Yup
Re:HashiCorp Did It Backwards by ArchOversight on Tuesday September 05, 2023 @08:32PM (#37399811)
Don't grant privileges to users that should not have those privileges?

The gating here is at the cloud level...

Re:HashiCorp Did It Backwards by wingmanjd on Tuesday September 05, 2023 @07:33PM (#37399289)
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.

Re:HashiCorp Did It Backwards by jolux on Tuesday September 05, 2023 @07:48PM (#37399430)
Or you can give people enough permissions to plan but not apply and leave applying to a restricted set of users...
Re:HashiCorp Did It Backwards by quickthrower2 on Tuesday September 05, 2023 @08:14PM (#37399642)
Also you can have laboratory cloud subscriptions seperate from production, where devs have full permissions.
Re:HashiCorp Did It Backwards by nijave on Wednesday September 06, 2023 @07:06AM (#37403495)
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.
Re:HashiCorp Did It Backwards by joombaga on Wednesday September 06, 2023 @11:24AM (#37406503)
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).
Re:HashiCorp Did It Backwards by macca321 on Thursday September 07, 2023 @08:23AM (#37417895)
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
Re:HashiCorp Did It Backwards by notnmeyer on Tuesday September 05, 2023 @09:55PM (#37400503)
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.