One of these days I should work on a talk that I can do at user groups and conferences about my alternate reality of not using Linux as my primary deploy target (most of the time), or Docker or Kubernetes or The Cloud TM in general. Just so ppl. know that other options exist.
In my last job this is how we deployed our app to production. It was fast. It was reliable and everybody was able to understand wtf was going on :) (app and host names anonymized)
I am not big fan of giving out interactive ssh access to a 3rd parties. Even with a restricted account.
What you can do is to use ssh's "ForceCommand" to make it more secure. But that moves the actually deploy logic from the CI to the server.
It basically turns the ssh just into a fancy webhook with ssh auth.
https://github.com/tcurdt/nixcfg/blob/main/modules/hook-ssh.nix
@tcurdt yup - definitely adjustable to individual paranoia levels :)
will have a look at you link :)
Speaking of Github, their auth story feels so incredible frustrating:
- classic PAT
- fine-grained PAT
- Github Apps
- deploy keys
...and all have major drawbacks.
What do you use on the servers after the webhook triggered? Using a PAT to access GH feels so incredible bad/dirty.
You don't happen to know someone at Github that we could try to annoy into some progress?
Don't you need access to the GH package registry or GH repo from that intermediate server?
Or how do you pass on the build artefacts?
@tcurdt oh right, I had to look that up. Limited PTA for now. But yes, not a happy situation.
We could send the artifact in the we hook maybe.
Yeah, but as soon as we are talking OCI registry, sending the full image via webhook is less than ideal.
And access to the GH registry requires the classic PAT 🙄 (unless that has changed and I missed it).
So if @reconbot knows a person we could bug (or bribe, or offer help), that would be nice.
This is frustrating me for years now.
