You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect that these incompatibilities are the result of kaniko storing configuration data (registry auth files, tls certs, etc...) in the same place that it uses to generate the data files ("operating folder") for the container image that is to be built.
Ideally these two folders would be separated so that one could change the "operating folder" to be a separate location, one that is not backed by memory for instance. Using kaniko in a kubernetes environment typically requires mounting read/only configmaps for supplying the credentials and additional certificates required for authenticated with private registries. In this case, passing in --kaniko-dir causes kaniko to break because it attempts to copy & rm -rf the configmap backed files to the directory defined by --kaniko-dir. There are ways to directly mount the configmaps into the desired --kaniko-dir destination ahead of time.
I also found that you have to explicitly set SSL_CERT_FILE=${kanikoDir}/ssl/certs/ca-certificates.crt, if you override the kaniko directory. Otherwise you'll hit cert verification issues.
Actual behavior
When
--kaniko-dir
(orKANIKO_DIR
) is set to a non standard location, this code: https://github.com/GoogleContainerTools/kaniko/blob/main/cmd/executor/cmd/root.go#L312 overwrites the DOCKER_CONFIG environment variable to point to a different and unintended location.Expected behavior
Setting
DOCKER_CONFIG
with either--kaniko-dir
orKANIKO_DIR
should utilize the docker config credential file provided by the user.To Reproduce
Steps to reproduce the behavior:
DOCKER_CONFIG
in the environment--kaniko-dir
set (and observe that theDOCKER_CONFIG
you provided is not used)Triage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: