Closed flickerfly closed 2 years ago
Definitely some good thoughts here and is something we've been tossing around. Something I've considered is forking the gitlab runner and building witness directly into it. This may be difficult to get official Gitlab buy in, however, and would require users to run their own runners.
eBPF is particularly interesting to me but requires privileges which may make it unattractive for some customers.
We are working on config file support which should clean up the actual implementation.
Attestor docs are currently WIP, but you can see the draft here: https://github.com/testifysec/witness/tree/chore/attestor-docs
Thank you both. Interesting idea on forking the Gitlab runner. It would be very cool if Gitlab would help speak to that integration as having it that native would be very nice.
@flickerfly FYSA: We are starting work with GitLab on an integration. We will track the work here: https://gitlab.com/gitlab-com/alliances/alliances/-/issues/257
Looking forward to it!
We will track this in GitLab
I'm interested in seeing what you folks are thinking about in regards to implementing this in a Gitlab pipeline.
I'm imagining bringing the tool into the pipeline might be made complex in pipelines that run in different pre-existing containers for each job since the tool needs to be onboard for each of those jobs to run the command. Would you be recommending a
before_script:
on each job to install witness? In a Kubernetes scenario, is there a method to run each gitlab runner pod with a witness sidecar? Maybe there'd some sort of Cillium/eBPF type solution in the near future. I presume you guys have given it more thought than me at this point, but also know that there isn't likely a simple answer for all gitlab runner scenarios.Doc Placeholder from the README: https://github.com/testifysec/witness/blob/main/docs/attestor.md#gitlab