From T175297: Define new Jenkins pipeline for container build phase:

Another issue that has arisen in testing this is that the default credential store for Docker is very insecure. By default, it stores all usernames/passwords given to docker login in the clear (in ~/.docker/config.json) until a subsequent docker logout is called. That means there is a substantial window of time where any other Jenkins job running via the same remote agent could gain access to the registry credentials.

Docker has functionality for alternative credential stores so that passwords aren't stored in the clear, but that solution wouldn't protect against this particular attack vector. Any job running via the same agent (same machine as jenkins-deploy) will have read access to the store and thus the registry credentials.

A few other possibilities in addition to using a sane credential store:

1. Somehow pass the docker config (containing creds) to docker push via stdin. This seems maaaybe possible via --config /dev/stdin but would be hacky as hell.
2. Ensure all jobs or at least all other jobs that run on contint1001 (where we're going to eventually run the pipeline job) are isolated inside containers.
3. Run a separate Jenkins agent as a different user on contint1001 for only the pipeline job.

Option #2 seems like the most secure to me but others should definitely weigh in.