IaC / GitOps brainstorming

[Eugeny]

Hey all,

I'm looking into starting the work on the native infrastructure-as-code / GitOps support for Warpgate - please feel free to post any thoughts, requirements or your ideal vision!

[Eugeny]

An example prior work PR: #2324

[workibear]

The idea is so good, I need it.It would be great if Targets and Roles could be directly imported and maintained through static YAML files. In addition, I would like to request support for assigning permissions directly to individual users, which would enable finer-grained access control, so that members can focus only on the machines they care about.

Currently, the workaround is to manually create a role for each member and assign permissions to the Target resources they own. This works well only because the team is small; as the team grows, this approach becomes a management burden. We may have to give up precise permissions and use more generic roles to reduce maintenance overhead. Ideally, permissions and resources could be managed as code (IaC) through static files, enabling version control and more scalable permission management.

[samtoxie]

Yes the PR i submitted indeed focuses on targets (+targetgroups) and roles. I think it would be a huge qol improvement, at least for myself.

I'd recommend opening a seperate issue about the second part btw, as it is a different feature seperate from the iac proposal. it will require some more work than extending the logic proposed in my PR to fully support that

[SteezyCougar]

We run Warpgate in Kubernetes via Helm. The biggest thing for us would be defining targets and roles directly in the YAML config file rather than only in the database (We actually do a jank injection script to do this today, which I hate). Being able to control everything via yaml and/or helm would be HUGE for us. Honestly a lot of the other solutions gatekeep their helm charts behind a paywall, so if we can make Warpgate strong in this regard I think it'd help with adoption.

I know different people deploy applications different ways, but probably one of the most universal strategies is either a singular config file, or everything able to be controlled via env-vars ultimately. (Also deploying warpgate instances in a stateless fashion or with multiple replicas easily would be AWESOME)