GoogleContainerTools
setcap still not being persisted in v1.8.1
Actual behavior According to this ticket, the bug of setcap not being persisted should be fixed, but it's not the case in latest v1.8.1 version
Expected behavior setcap should be persisted while building with kaniko
To Reproduce Steps to reproduce the behavior:
- Create the following Dockerfile:
FROM node:14.20.0-bullseye-slim
RUN apt-get update
RUN apt-get install -y default-jre chromium zip curl jq software-properties-common gnupg openssh-client git bzip2
RUN curl -fsSL https://apt.releases.hashicorp.com/gpg | apt-key add -
RUN apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
RUN apt update && apt install vault
RUN setcap cap_ipc_lock= /usr/bin/vault
-
Build the image using latest kaniko image:
docker run -it -v $(pwd):/workspace -v ~/.docker/config.json:/kaniko/.docker/config.json --entrypoint "" gcr.io/kaniko-project/executor:v1.8.1-debug /kaniko/executor --context <path to Dockerfile> --destination <registry>/<image> -
Run the image locally command
docker run -it <image> /bin/sh -
Try to execute Vault, you will have a permission denied
# vault -v
/bin/sh: 1: vault: Operation not permitted
- If you execute the setcap command which is supposed to be executed during the build, it fixes the issue:
# setcap cap_ipc_lock= /usr/bin/vault
# vault -v
Vault v1.11.0 (ea296ccf58507b25051bc0597379c467046eb2f1), built 2022-06-17T15:48:44Z
Additional Information
| Description | Yes/No |
|---|---|
| Please check if this a new feature you are proposing |
|
| Please check if the build works in docker but not in kaniko |
|
Please check if this error is seen when you use --cache flag |
|
| Please check if your dockerfile is a multistage dockerfile |
|
I am noticing the same issue in my pipelines. The issue seems to be the identification of chances in a layer and not persisting them. A layer that that only contains a setcap command is not detected as containing any changes, as opposed to not persisting them. I would also consider this a bug, but we came up with a workarround that solves it for us. By combining the install and setcap layer changes are identified and persisting works:
RUN apt update && apt install vault &&
setcap cap_ipc_lock= /usr/bin/vault
This has also the advantage that the image sizes is not unnecessaily increased as a pure setcap would write the same file again which would add an additional 191M in case of the vault binary
indeed this is resolving the issue, thank your for your workaround @CGeorg-ci !
Anyway I think you're right by saying that this is still an annoying bug that should be fix if possible
This is pretty confusing... @headyj you refer to version 1.8.1 for a fix, but the fix is only included in 1.9.0+. Can you check again if it is working for you now?
I am still experiencing this with 1.9.1 and the described workaround does not appear to change the situation.
An workaround.
DO RUN touch <filename> to update mtime of target file, after do setcap.
I am still experiencing this with 1.9.1 and the described workaround does not appear to change the situation.
Note that only --snapshotMode=full honors security.capability. If you used a different mode, that may not work.
