jklein
28567842f3
The first Trivy run on this chart reported one finding out of 96 tests: AVD-KSV-0116, "Runs with a root primary or supplementary GID", because the pod context carried runAsGroup: 0 - copied from what the image expects. Checked instead of suppressed, and the check says the group is not needed. Counted across the image layer of quay.io/keycloak/keycloak:26.8.0: 521 of 522 entries are owned by 1000:0, and every mode present (drwxrwxr-x, -rwxrwxr-x, -rw-rw-r--) grants the OWNER full access. The one remaining entry is /opt itself, which needs only traverse. So uid 1000 gets everything it reads and executes through the owner bits, whatever group it is in. Group 0 is upstream's OpenShift arbitrary-uid pattern - root group plus a group-writable tree, so that ANY uid landing in group 0 can write. It buys nothing once the owning uid is pinned, which this chart does. Writes all go into the three emptyDirs, which fsGroup 1000 makes writable. So runAsGroup is 1000, the finding is gone rather than excepted, and no entry was added to ci/trivy/trivyignore.yaml - which matters more than one LOW finding: that file scopes by chart, so an AVD-KSV-0116 exception for keycloak would also have silenced it for the serving container, on a check that is making a fair point about an identity provider. The condition under which this goes back to 0 is written at the value: a path uid 1000 does not own. There is none in this image today. Part of #83