Because open source software is so common in contemporary development environments, it’s possible that your environment depends on publicly accessible container images kept on Docker Hub. These dependencies can put your CI/CD pipeline at risk for security and reliability issues if they are not configured and controlled properly. They provide some recommended practices in this article that your teams can implement to lower these risks.
Keep local replicas of public containers
Stronger security measures can be implemented and the maximum reliability can be achieved by storing local copies of public containers wherever feasible. You can find more information in the recommendations that the Open Containers Initiative published about accessing public content.
Authenticate yourself when using Docker Hub
It is advised that you always visit Docker Hub with authentication rather than using an anonymous account. Making anonymous queries carries additional dangers beyond security ones. You run the risk of exceeding rate constraints, which could compromise the dependability of your CI/CD pipelines. There are several choices for authentication, depending on the design of your CI/CD infrastructure and the Google Cloud services you use:
Use Artifact Registry Remote Repositories: You can use Artifact Registry remote repositories to provide a regional cache of your dependencies and to authenticate with Docker Hub instead of directly referencing Docker Hub repositories within your build processes. The following Artifact Registry documentation page contains comprehensive instructions for using Docker Hub access tokens with Artifact Registry: Set up authentication for remote repositories on Docker Hub.
To work with Docker images, use Cloud Build. It offers authentication methods for getting images from Docker Hub into your build processes. If you generate your container images using Docker Hub images, you can utilize these authentication methods.
The subsequent Cloud build configuration file demonstrates how to launch a private image and log into Docker using the credentials kept in Secret Manager. See Interact with Docker Hub images for additional details on how to use Cloud Build to communicate with Docker Hub.
steps:
name: ‘gcr.io/cloud-builders/docker’
entrypoint: ‘bash’
args: [‘-c’, ‘docker login –username=$$USERNAME –password=$$PASSWORD’]
secretEnv: [‘USERNAME’, ‘PASSWORD’]
name: “gcr.io/cloud-builders/docker”
entrypoint: ‘bash’
args: [‘-c’, ‘docker run $$USERNAME/REPOSITORY:TAG’]
secretEnv: [‘USERNAME’]
availableSecrets:
secretManager:
versionName: projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION
env: ‘PASSWORD’
versionName: projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION
env: ‘USERNAME’
By adhering to the above-mentioned recommended practices, your CI/CD pipelines’ security posture will improve and the dependability risk will decrease. Furthermore, putting in place the appropriate authentication rules for your environments guarantees that corporate security standards are fulfilled or surpassed while also removing roadblocks in development that arise later in production.
