Thanks for this a lot, I was just asking about possibility of corporate secret management with keybase. First time I hear about encrypted repos but I was considering using team storage just to keep corporate secretes in a file system.
Currently I use Gitlab on premise and I put secrets on the repository in a pass format. GitLab runner has single secret, to access the password store. This is clearly different then OP's context in which he wants to utilize everything in cloud.
While this works great and devs can read secrets on any OS, I was considering alternatives for easier on-boarding and additional features. I looked into all kind of secret sharing stuff for teams, both commercial and FOSS, but for some reason I don't "feel it". Vault feels like designed more for machines then humans. Commercial ones seem prohibitively expensive plus not feeling great using cloud for secret management (or anything non-trivial for that matter - I could go with status page maybe). So far Psono looks most promising in FOSS world.
In this case, one could use 2 job servers - one that is used only for sensitive things like deployments, and another one for other stuff, in this case build. This could be 2 Gitlab runners (the ci yaml file itself doesnt require changes) for example so build happens on Gitlab.com infrastructure and the deployment happens on the runner tagged something like self-destruct. If you think about it, is it enough that this is PI in your kitchen ? - if accessible from outside it can be hacked, so this probably needs to be deploy and terminate myself scenario to minimize exposure even further - perhaps one day also in cloud, lets call it proton-runner (it would still require leap of faith to some measure).
the “Pi” wouldn't need to be (publicly) reachable. It would just need to be able to connect to Keybase and other private services. For remote management and talking to private services over internet, i guess SSH, VPN or Zerotier <3 ?
Edit: for secrets in Keybase i think repos are better since its not as easy to mistakenly delete the files ? Plus one has change history. But other people might know better than me.
to determine when to deploy i mention its possible to listen to team chat messages for commits, so event based. There might be more efficient solutions, think i came across somewhere that its possible to listen to other types of events. need to dig deeper
well, erhmm yes :-) so i was exploring if it was possible to do that in the same way we can give our (encrypted) data to Keybase. Or at least, utilise as much as cloud services as possible.
Currently I use Gitlab on premise and I put secrets on the repository in a pass format. GitLab runner has single secret, to access the password store. This is clearly different then OP's context in which he wants to utilize everything in cloud.
While this works great and devs can read secrets on any OS, I was considering alternatives for easier on-boarding and additional features. I looked into all kind of secret sharing stuff for teams, both commercial and FOSS, but for some reason I don't "feel it". Vault feels like designed more for machines then humans. Commercial ones seem prohibitively expensive plus not feeling great using cloud for secret management (or anything non-trivial for that matter - I could go with status page maybe). So far Psono looks most promising in FOSS world.
In this case, one could use 2 job servers - one that is used only for sensitive things like deployments, and another one for other stuff, in this case build. This could be 2 Gitlab runners (the ci yaml file itself doesnt require changes) for example so build happens on Gitlab.com infrastructure and the deployment happens on the runner tagged something like self-destruct. If you think about it, is it enough that this is PI in your kitchen ? - if accessible from outside it can be hacked, so this probably needs to be deploy and terminate myself scenario to minimize exposure even further - perhaps one day also in cloud, lets call it proton-runner (it would still require leap of faith to some measure).