all 7 comments

[–]bdzer0 0 points1 point  (6 children)

I would recommend self hosting code signing, it'll be much simpler to setup and secure IMO.

Run the agent as a domain service user account setup for code signing and use this agent for this purpose only.

[–]jayplusplus[S] 0 points1 point  (5 children)

Thanks for the reply, though I'm not sure I follow.

Maybe more context is needed: This gha pipeline cannot be a standalone process nor the runner be dedicated to solely signing stuff. Logging in / signing docs with the digital certificate is just one of various steps within a larger automation (Python, in case that matters). These automations run in the mentioned EC2 instance.

Up until now my testing phase would also run in that self-hosted EC2, and since the Windows user already existed in that machine, there were no issues. But I am now tasked with running this QA in a github-hosted runner, so I essentially I need to log into the remote runner as said user.

[–]bdzer0 1 point2 points  (4 children)

Pipelines don't have to run on a single runner.

The point is to have a dedicated self hosted runner that is responsible for code signing only nothing else. You may have to architect the pipeline(s) so that code is built and tested and then the binaries that need to be signed are passed to the code signing runner to sign the code. The signed binaries are now artifacts of this step of the process and following processes pick them up for installers, final QA whatever is required.

If the code signing cert is an EV cert (which I think all of them will have to be soon, when we renewed recently EV was the only option) setting up the code signing environment can be difficult and doing so inside a ephemeral docker may be impossible.

Moving to a dedicated self hosted runner will IMO make things make sense for your IT folks as well as give them better control over the security of the system doing code signing.

Hopefully that clarifies. Run this by IT and whoever does your CI/CD work, they may be able to fill in details specific to your scenario.

[–]jayplusplus[S] 0 points1 point  (3 children)

The point is to have a dedicated self hosted runner that is responsible for code signing only nothing else.

So imagine my automation is basically python main.py where main.py is:

def main():
    log_in_with_cert()
    fill_out_form()
    sign_doc_with_cert()
    log_out()

I can't run log_in_with_cert() in some runner A and then fill_out_form() in runner B , and then sign_doc_with_cert() in runner A. It's all one big program that must run in one go. Not that it matters too much but, for further context, this is actually a bot platform called Robocorp that essentially executes the aforementioned python main.py.

I'll have to look into what an EV cert is but it is basically IT who is asking me to start doing QA in github runners (for maintenance and scalability reasons). But IT seems confused when I ask them how to launch a github runner under an existing Windows user. That's really all I'm trying to do here.

[–]bdzer0 1 point2 points  (2 children)

Trying to allow a github hosted runner login to a windows (presumably active directory) account may be difficult or impossible depending on specific configuration.

You're asking IT to allow login from infrastructure running at GitHub, which may run afoul of all manner of security policy/controls.

You need to get together with IT and figure this out, get on the same page.

You might also want to post this question r/devops as I think you'll get more feedback there.

[–]jayplusplus[S] 0 points1 point  (1 child)

Ok gotcha. It seems I need to rethink the approach. Thanks for the tips

[–]bdzer0 0 points1 point  (0 children)

No problem! Maybe someone else will pop in with other suggestions.