feat: add buildah param to inject secrets into the build #1099
Conversation
| cp -r --preserve=mode "$OPTIONAL_SECRET_PATH" /tmp/optional-secret | ||
| BUILDAH_ARGS+=("--secret=id=${OPTIONAL_SECRET},src=/tmp/optional-secret") | ||
| echo "Adding the secret ${OPTIONAL_SECRET} to the build, available at /run/secrets/${OPTIONAL_SECRET}" | ||
| fi |
There was a problem hiding this comment.
Technically, this allows the user to inject arbitrary content into the build. Although the same could be said for every volume mount unless the content comes from the output of a trusted task. The likelihood of this being misused seems slightly higher than for the other secrets, though still fairly low.
I'm not too concerned over adding this, just raising an observation
|
/retest |
| @@ -67,6 +67,11 @@ spec: | |||
| hours, days, and weeks, respectively. | |||
| type: string | |||
| default: "" | |||
| - name: OPTIONAL_SECRET | |||
| description: Name of a secret which will be made available to the build | |||
| with 'buildah build --secret' at /run/secrets/$OPTIONAL_SECRET | |||
There was a problem hiding this comment.
Btw, what is the reasoning behind the name OPTIONAL_SECRET?
There was a problem hiding this comment.
Hm, the first name I chose was EXTRA_SECRET. Meaning - it's just an extra secret in addition to the entitlement secret that you can inject into your build.
On reading, I thought that "extra secret" might spuriously convey the idea that the secret was "more secret" than normal secrets - which isn't the intent.
Rather than OPTIONAL_SECRET, we could consider ADDITIONAL_SECRET - or .. any ideas?
There was a problem hiding this comment.
ADDITIONAL_SECRET does sound a bit more straightforward.
ralphbean
force-pushed
the
secret-id
branch
2 times, most recently
from
efa55a3
to
8f493a4
Compare
|
Yes, it's amazing. In this line of this Containerfile the instructlab team is adding a "physically bound" container, embedding it in another container. Upstream, that works as is. In private environments, users need auth to pull that inner image during the build process of the outer image. This is incompatible with hermetic mode. I can imagine a user might someday want to use this in combination with hermetic mode in order to decrypt some content, encrypted at rest, during their build. But, that is an imagined use case - not real. |
The secret is made available only to RUN lines that are invoked with
`--mount`, like this:
```
RUN --mount=type=secret,id={secret-name} cat /run/secrets/{secret-name}
```
See https://docs.podman.io/en/latest/markdown/podman-build.1.html#secret-id-id-src-path
Signed-off-by: Ralph Bean <rbean@redhat.com>
Per review feedback. This is a more straightforward name.
The secret is made available only to RUN lines that are invoked with
--mount, like this:See https://docs.podman.io/en/latest/markdown/podman-build.1.html#secret-id-id-src-path