| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 810413: Periodically run malloc_trim via apscheduler https://review.opendev.org/c/zuul/zuul/+/810413 | 11:32 | |
| @mnasiadka:matrix.org | Hello, from what I understand based on docs - secrets are not available in untrusted projects in changes under review (unmerged) - if I’m right - how to handle things like docker credentials for pulling images from auth-required registries? | 17:44 |
|---|---|---|
| @fungicide:matrix.org | mnasiadka: in opendev we have some jobs which use credentials in their playbooks and are then inherited, just make sure to clean up any credentials that might get written to disk before running untrusted playbooks in jobs inheriting that | 17:47 |
| @clarkb:matrix.org | right the secrets are available to the jobs but only in trusted contexts. And then you have to be careful taht you don't leak those credentials from there | 17:48 |
| @fungicide:matrix.org | obviously, running untrusted commands that could be speculatively altered and giving them access to sensitive data is basically impossible to secure | 17:48 |
| @clarkb:matrix.org | I think docker allows you to hash/encrypt the secret somehow which maybe useful to avoid leaking | 17:48 |
| @clarkb:matrix.org | Another options specific to container images would be to have a step (or a dedicated job) put the images you need in a buildset registry without credentials (if that doesn't expose any material) and have the jobs pull from there | 17:49 |
| @clarkb:matrix.org | eg if you're authenticating just to avoid rate limits then this might work | 17:49 |
| @clarkb:matrix.org | but if the container content itself is protected then that may not be useful | 17:49 |
| @fungicide:matrix.org | also if you put the list of images you want downloaded into a job variable, you can have it passed to the parent which is doing the authenticated downloading in a trusted context, so the speculatively-run job could still in theory alter the image list. whether that's a safe choice, i can't say (could it be used to convince the parent job to expose its credentials somehow if a malicious container were injected?) | 17:54 |
| @jangutter:matrix.org | mnasiadka: An option which can be used _with great caution_ is to use a trusted token to generate a one-time time-limited token during the trusted context. That you can persist on either the executor or the worker. We use a variant of this method for _readonly_ secrets in our isolated Zuul. | 17:56 |
| @jangutter:matrix.org | It is definitely not a generic answer to this problem. The correct answer is "why are you requiring authentication to readonly resources". | 17:57 |
| @jangutter:matrix.org | It also works against making something reproducable. | 17:59 |
| @mnasiadka:matrix.org | fungi: I just need to download images, nothing inside their content is secret, so a parent job in config-project that will download images and push them to buildset registry and then remove the credentials is pretty fine for me. | 18:09 |
| @jangutter:matrix.org | mnasiadka: yeah that will work, the annoying thing is that you can only really test the whole thing after it's merged, so the procedure to update it is like any base job. | 18:12 |
| @fungicide:matrix.org | though also if the downloading and uploading part is in a parent job and then you have an untrusted child job that passes the list of images to the parent, you could still speculatively test changes that involved adjustments to the list of images | 18:17 |
| @jangutter:matrix.org | Yeah, just the trusted section is tricky. | 18:18 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 954988: WIP: Stub provider documentation https://review.opendev.org/c/zuul/zuul/+/954988 | 21:35 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 954988: WIP: Stub provider documentation https://review.opendev.org/c/zuul/zuul/+/954988 | 21:37 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 22:08 | |
| - [zuul/zuul] 954988: WIP: Stub provider documentation https://review.opendev.org/c/zuul/zuul/+/954988 | ||
| - [zuul/zuul] 957053: Move zuul image tags definition to base provider https://review.opendev.org/c/zuul/zuul/+/957053 | ||
| - [zuul/zuul] 957054: Move label tags to common_label https://review.opendev.org/c/zuul/zuul/+/957054 | ||
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!