Change Details

From {T175297}: > 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 [[ https://github.com/docker/docker-credential-helpers | 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 for the pipeline job. Option #2 seems like the most secure to me but others should definitely weigh in.

From {T175297}: > 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 [[ https://github.com/docker/docker-credential-helpers | 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.

From {T175297}: > 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 [[ https://github.com/docker/docker-credential-helpers | 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 foron contint1001 for only the pipeline job. Option #2 seems like the most secure to me but others should definitely weigh in.