[Updated] Authenticate with Docker to avoid impact of Nov. 1st rate limits

Thanks for the reply Alican! :slightly_smiling_face: I set up Docker authentication for my CircleCI jobs so I should be good now.

I’m not super happy that Docker is now going to make data profiles on all of us based on the images we pull, but that’s not something CircleCI can do much about of course.

We decided to use jfrog to cache docker hub artifacts using jfrog’s remote and virtual repositories.

but we don’t want to make any promises right now. We will definitely release an official statement before the Nov 1 deadline

I think the issue is, if the answers come sometime before the deadline, that doesn’t give people a lot of time to make the changes they may need to make.

I’m wondering, I think you all are still split between AWS and GCP, but for the stuff on GCP, would configuring Docker on the GCP hosts, at least, to use the gcr.io dockerhub mirroring (https://cloud.google.com/container-registry/docs/pulling-cached-images) work?

Is Circle considering hosting its own convenience images on a separate registry and / or mirroring them to GCR / ECR / etc? That away, at least users could use the same auth for their own private images and Circle’s convenience ones (assuming permissions were open enough).

Would also be great if https://circleci.com/docs/2.0/private-images/ could include an example of authenticating to GCR (as described in https://circleci.com/docs/2.0/google-auth/)

Would it be feasible to have magic global environment variables for this so that we don’t have to change hundreds of lines of code?

Nthing this. We use orbs extensively, but also have a lot of workflows which don’t currently have a context. So we’d have to modify hundreds or even thousands of individual projects’ configs to add a context where one isn’t now, even if we added the auth piece to our executors in orbs.

Even if it’s an organization-wide flag, or an env var that only gets set if credentials are defined, something along these lines would make this much more practical than updating contexts and / or env variables in tons of projects.

1 Like

I added Docker authentication to my CircleCI builds, but how can I see if this works ahead of the November 1 deadline?

The ‘Spin up environment’ step has no information about authentication nor does it mention working with the username. The FAQ links to a page that discusses setting up authentication, but without information on how to verify if this works.

In my Docker account I can neither find information on usage pulls.

6 Likes

I’m using YAML’s merge feature to reduce duplication in a given config file. For instance:

version: 2.1

docker-auth: &docker-auth
  auth:
    username: $DOCKERHUB_USERNAME
    password: $DOCKERHUB_PASSWORD

workflows:
  version: 2
  workflow:
    jobs:
      - job1:
          context: dockerhub
      - job2:
          context: dockerhub

jobs:
  job1:
    docker:
      - image: circleci/whatever
        <<: *docker-auth
    steps:
      - checkout
  job2:
    docker:
      - image: circleci/whatever
        <<: *docker-auth
    steps:
      - checkout
4 Likes

Agree. I have the same question

3 Likes

Thank you. I will try this and update here again

Hi,

My organization has the performance plan, which should allow us to get the silver support plan automatically I believe. I opened a support ticket for this question below but have not been able to get a response yet, and we need to update a large number of CircleCI config files correctly before Nov 1. Any help would be appreciated. Thanks

We are using a docker executor job like so below. We have a context setup with the docker credentials. With the changes to docker hub rate limiting and the required authentication for docker hub, we are authentication for the primary container setup in the job below.

My question is whether these credentials setup in the primary container are passed to the remote environment setup by the “setup_remote_docker” step when it executes docker building/pushing and running commands or we need to add another step explicitly for docker login before running the docker run command, which I assume will run the remote environment.

This is the document I read and its not clarified in this document. I should mention you need “setup_remote_docker” as a step if you use the docker executor, so it cannot just be removed.

test:
docker:

  • image: circleci/python:3.7.3-stretch
    auth:
    username: $DOCKERHUB_USERNAME
    password: $DOCKERHUB_PASSWORD

working_directory: ~/repo

steps:

  • checkout

  • setup_remote_docker

  • load_image_from_cache

  • run:
    name: Run tests
    command: >
    docker run --rm -t --net=host
    $PACKAGE_NAME:git rev-parse HEAD
    /bin/sh -c “echo placeholder”

1 Like

Thank you, I think it works, but we only know for sure come Nov 1st

They may have resolved this by now. I did a test yesterday following the new tutorial in the docs for authenticating your executor setup (https://circleci.com/docs/2.0/private-images/). I added a few extra characters to my password and then the job started to fail, saying it couldn’t pull the image:

Error response from daemon: Get https://registry-1.docker.io/v2/cimg/node/manifests/14.13.1: unauthorized: incorrect username or password
1 Like

Update

We’ve added a warning message when auth is invalid, so you should see:

Warning: No authentication provided, this pull may be subject to Docker Hub download rate limits.

2 Likes

Any word on authenticating to orbs like aws-ecr? Even if CircleCI and Docker work out a deal to avoid throttling, it seems useful to allow non-anonymous pulls. And if you don’t work out a deal, Nov 1 is only two weeks away now.

We’re working on it right now, and will hopefully have something official to share very soon that will make it easy.

@trevorr We do have a support article about workarounds for orbs right now if you’re interested!

1 Like

Any direction you can provide me on this one.

Great, thank you! :+1:

For people that look for this message, it’s approximately the fifth line in the ‘Spin up environment’ task. For example:

Build-agent version 1.0.41417-4036f5a3 (2020-10-16T14:37:07+0000)
Docker Engine Version: 18.09.6
Kernel Version: Linux 8dc5fabcbe7d 4.15.0-1077-aws #81-Ubuntu SMP Wed Jun 24 16:48:15 UTC 2020 x86_64 Linux
Starting container cibuilds/hugo:0.62.2
Warning: No authentication provided, this pull may be subject to Docker Hub download rate limits. 
  image cache not found on this host, downloading cibuilds/hugo:0.62.2
0.62.2: Pulling from cibuilds/hugo
...
1 Like

fyi, I added this to the first step of each job to automatically verify the build with a connection error when it’s running. (In short, it’s redirecting docker domains to localhost to fail the connection)

- run: |
  echo "127.0.0.1 registry-1.docker.io auth.docker.io index.docker.io dseasb33srnrn.cloudfront.net production.cloudflare.docker.com" | sudo tee -a /etc/hosts
  sleep 5

You would still have to manually verify the docker executor image yourself.

Any recommendations on how to enable authenticating with Docker in forked PRs?

So far, the only way I can think of is to enable “Pass secrets to builds from forked pull requests” and then utilize contexts to limit which env variables are accessible to the jobs being run in forked PRs.

In other words, it seems that if you’re using Docker executors in jobs that are exposed to forked PRs, there is no way to protect your Docker username and access key.

Would be nice if CircleCI added project or org-level authentication that would take place outside of the pipeline.

1 Like

I really want to suggest (again) that something higher level that required less adjustment of individual steps would really have been ideal.

Also, w/r/t orbs, it would be nice if Circle could publish a convention (e.g., DOCKERHUB_USER / DOCKERHUB_PASSWORD that would be relatively standard so that orbs could (if people followed the convention) take those from environment and / or a context without additional parameter configuration.

1 Like

As far as both orbs and the convention, I see a very interesting comment from @KyleTryon in the following comment with a little tease:

Also, this confirms that DOCKERHUB_USERNAME would probably be the convention for anything that did need to have those magic env vars (re: my post above)

1 Like