Publish ct-test-srv container on releases #7891
Conversation
mcpherrinm
force-pushed
the
mattm-ct-test-srv-container
branch
from
26c536b to
cd5c64f
Compare
|
I'm fine with using the existing workflows, but I was guessing the matrix might get over-complicated. I'll give it a try, though. |
|
If it were to be in the original workflows, would you want it to be part of make-assets.sh or the makefile? |
|
Oh, but I could include a new job in the same workflow, so at least the |
|
Another job in the same file is a definite improvement. I was imagining it as these same exact steps (no overlap with the makefile or make-assets.sh), just either before or after the other steps that those workflow jobs run. |
Just explicitly handle ct-test-srv. We can re-add a matrix if/when we want a second image, but this is a lot simpler for now.
|
OK, I went ahead and moved it to simple steps, just to build ct-test-srv, in the existing workflows. We can figure out how to handle multiple container images if and when that time comes. I think doing the minimal, straightforward thing is a good choice for now. |
|
There's a completely different tact we could take here too, which is to build a container with exactly the binaries from the release tarball - |
There was a problem hiding this comment.
LGTM. Agreed that this has less flexibility than the initial workflows, but I think the lack of proliferation of GO_VERSION locations is a bigger upside.
I think having all of the release tarball binaries in this image is also a great idea, though I slightly prefer the idea of having ct-test-srv separate from the other more-production-worthy binaries.
There was a problem hiding this comment.
Basically LGTM. I'd like to make sure I understand safe handling of GITHUB_TOKEN. Here's it's getting interpolated into the command line with echo "${{ secrets.GITHUB_TOKEN }}". In general command lines are logged.
According to https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-secrets, registered secrets are redacted from the logs. We know GITHUB_TOKEN is a registered secret because we access it using secrets.GITHUB_TOKEN.
So the redaction is the only mechanism in place keeping GITHUB_TOKEN out of the logs, right? I wish we could ask docker login to pull directly from an environment variable, but it does not appear to have that as an option.
According to https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#accessing-your-secrets, "If a secret was used in the job, GitHub automatically redacts secrets printed to the log. You should avoid printing secrets to the log intentionally." But it's not clear how else to log into GHCR.
|
Ah, it looks like we already use the In general I prefer to use plain commands over GitHub Actions, in order to minimize dependencies. But given that we already depend on this one, and it does add a small layer of protection to the credential (it's never logged, so never needs to be redacted), I'm in favor of using |
|
OK, so you're right relying on redaction is a bit dodgy. Instead, I can do what the previous step does and inject it into an environment variable, and then |
|
seems we posted past each other - I've updated to avoid printing, but could use docker/login-action too |
|
I like the printenv approach, and we can also follow up and remove our dependency on |
There's an old build of ct-test-srv at https://registry.hub.docker.com/r/letsencrypt/ct-test-srv that I'd like to remove, and replace usage of it with a container pushed automatically from Boulder releases.
I've set up the Github action that I hope is generic enough to also potentially push other containers (like boulder itself) in the future by adding to the matrix.