[HN Gopher] Show HN: Digger - Open Source Terraform automation a...
___________________________________________________________________
Show HN: Digger - Open Source Terraform automation and
collaboration tool
Author : ujnproduct
Score : 65 points
Date : 2023-07-09 10:51 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| notsahil wrote:
| They migrated from Python to Golang
|
| More Detailed Here:
| https://old.reddit.com/r/golang/comments/14rduec/we_rewrote_...
| izalutski wrote:
| Indeed we did :)
|
| Also blogged about it: https://medium.com/@DiggerHQ/we-rewrote-
| our-product-in-go-fr...
| lantry wrote:
| I was initially very interested in digger, because I need
| something like atlantis but the thought of a web-accesible server
| with owner-level access to my project seemed scary. Having
| everything in cicd seemed like a great solution. However, when I
| read the digger docs, I discovered that it too has a publicly
| accessible server, that gets autodeployed when you first run
| digger.
|
| 1. I don't like the idea of the tool creating resources I didn't
| explicitly tell it to create
|
| 2. I don't like the idea of a public endpoint for someone to pwn
| and get owner-level access of all my stuff.
|
| It would be nice if the docs explained what the serverless
| backend thing does (besides the vague comment about handling
| webhooks), and it would be nice if there was an option that
| didn't require the public backend even if it means slightly
| degraded functionality. (github actions can be triggered by PR
| opened, PR updated, comment created, comment edited, merge to
| main, and many other things. Seems to me like that should be
| enough?)
|
| https://docs.digger.dev/readme/how-it-works
| oneplane wrote:
| I'm surprised nobody has mentioned Atlantis yet. Running bare
| terraform in CI is a bad idea (to the extent that running an
| 'expect' script for an interactive tool is a bad idea), and when
| you consider the impact it can have (both on resources and on
| escalation) it should be out-of-band anyway.
| thinkmassive wrote:
| One of the major security issues with running terraform in your
| CI/CD pipeline is that it usually needs admin permissions to your
| entire cloud environment. To avoid this you need the pipeline to
| pass parameters to an internal process that actually applies the
| changes.
|
| Digger makes it sound like it might address this:
|
| > Digger runs terraform natively in your CI. This is: Secure,
| because cloud access secrets aren't shared with a third-party
|
| From the Github+AWS demo:
|
| > 4. Add environment variables into your Github Action Secrets
| (cloud keys are a requirement since digger needs to connect to
| your account for coordinating locks) AWS_ACCESS_KEY_ID &
| AWS_SECRET_ACCESS_KEY
|
| It sure looks like AWS admin credentials are shared with Github,
| and also available to anything else in the diggerhq/digger
| action.
| sausagefeet wrote:
| > It sure looks like AWS admin credentials are shared with
| Github, and also available to anything else in the
| diggerhq/digger action
|
| I am a co-founder of Terrateam[0] which is a Terraform CI/CD as
| well. At the end of the day, you need to execute something to
| do these operations and having this component open source is
| important for auditing purposes. For Terrateam, we lean heavily
| into GitHub Actions so GitHub is at least managing any secrets
| and runs. One challenge is users could pin the Action that we
| publish to a specific version, but we also update it regularly
| and communicating to customers to update it is a challenge.
|
| [0] https://terrateam.io
| mikedelago wrote:
| Yeah, weird for them to do that. Managing credentials like that
| sucks even from an ergonomics standpoint.
|
| In practice, it's pretty normal to use OIDC to authenticate
| Github Actions to AWS:
|
| https://docs.github.com/en/actions/deployment/security-harde...
| thinkmassive wrote:
| Ok yeah, looks like they recently added OIDC support:
| https://docs.digger.dev/cloud-providers/authenticating-
| with-...
|
| They should update the main readme to include this under
| Features, and also call it out in the demo files.
| evantbyrne wrote:
| Any CD is going to require some kind of authentication key. To
| minimize the surface area of a potential leak, create a user in
| AWS for the tool, only grant it access to the resources needed,
| and then create a key for that user to place in your CI. You
| should also enable audit trails in your AWS account so you can
| monitor for unusual activity.
| klysm wrote:
| You should create a role, not a user IMO. Also how do you
| manage that role/user? Via terraform?
| ljm wrote:
| I do similar with K8S and RBAC. The most common action in a
| repo is going to be to update a deployment with a new image
| or resource config, so that's all it can do.
|
| Still need a more permissive role to manage the cluster in
| other ways but you can isolate that and limit access to its
| repo.
| izalutski wrote:
| One of the founders here You could also use OIDC so no need to
| share keys
|
| https://docs.digger.dev/cloud-providers/authenticating-with-...
| ushakov wrote:
| I misread it as Dagger, the CI/CD tool (https://dagger.io)
| izalutski wrote:
| Yeah naming is fun
|
| The most fun thing is - Digger + Dagger could be a great combo!
| We haven't yet explored properly but in theory it shouldn't be
| anything different from adding another CI provider; we already
| support GitHub Actions, Gitlab CI and Azure DevOps
| seedie wrote:
| One of the main reasons for us to use a terraform collaboration
| tool is to easily manage state files.
|
| Would be awesome if they find a way to integrate state
| management.
| izalutski wrote:
| Thanks!! Great point; for now we're relying on S3+dynamo which
| many people prefer anyways; but state management is on the
| roadmap, we'll get to it soon
|
| Tracking here: https://github.com/diggerhq/digger/issues/206
|
| And btw contributions very welcome, we're a small team so every
| bit helps, even if it's just filing or labeling an issue
| mdaniel wrote:
| > S3+dynamo which many people prefer anyways
|
| Those people have not experienced the :heart_eyes_cat: of
| GitLab's TF state store, which I find just a bazillion times
| superior to creating TWO separate AWS resources only for
| storing a bunch of JSON to make TF work: https://docs.gitlab.
| com/ee/user/infrastructure/iac/terraform...
___________________________________________________________________
(page generated 2023-07-09 23:01 UTC)