Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use fully qualified image names #3023

Closed
sarayourfriend opened this issue Sep 13, 2023 · 1 comment · Fixed by #3071
Closed

Use fully qualified image names #3023

sarayourfriend opened this issue Sep 13, 2023 · 1 comment · Fixed by #3071
Assignees
Labels
🤖 aspect: dx Concerns developers' experience with the codebase ✨ goal: improvement Improvement to an existing user-facing feature help wanted Open to participation from the community 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: mgmt Related to repo management and automations

Comments

@sarayourfriend
Copy link
Collaborator

Current Situation

We use unqualified image names in our Dockerfiles and docker-compose files.

Here's a note from Podman explaining which this is not generally a good idea:

# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
# We recommend always using fully qualified image names including the registry
# server (full dns name), namespace, image name, and tag
# (e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,
# quay.io/repository/name@digest) further eliminates the ambiguity of tags.
# When using short names, there is always an inherent risk that the image being
# pulled could be spoofed. For example, a user wants to pull an image named
# `foobar` from a registry and expects it to come from myregistry.com. If
# myregistry.com is not first in the search list, an attacker could place a
# different `foobar` image at a registry earlier in the search list. The user
# would accidentally pull and run the attacker's image and code rather than the
# intended content. We recommend only adding registries which are completely
# trusted (i.e., registries which don't allow unknown or anonymous users to
# create accounts with arbitrary names). This will prevent an image from being
# spoofed, squatted or otherwise made insecure.  If it is necessary to use one
# of these registries, it should be added at the end of the list.

In other words, it's too easy for the wrong image to be pulled. On machines where multiple default registeries are configured, just up will hang while the docker backend asks which registry to pull each unqualified images from.

Suggested Improvement

Switch to using fully qualified image names, e.g., instead of airflow -> docker.io/apache/airflow and so on. This would need to be applied to essentially all of our images (except Elasticsearch, because we already pull it from a non-default registry anyway).

Benefit

Reduced ambiguity, reduced chance of the incorrect image working, eliminate issues on machines configured with multiple default search registries.

@sarayourfriend sarayourfriend added help wanted Open to participation from the community 🟨 priority: medium Not blocking but should be addressed soon ✨ goal: improvement Improvement to an existing user-facing feature 🤖 aspect: dx Concerns developers' experience with the codebase 🧱 stack: mgmt Related to repo management and automations labels Sep 13, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Openverse Backlog Sep 13, 2023
@ashiramin
Copy link
Contributor

@sarayourfriend I can pick this up.

@obulat obulat moved this from 📋 Backlog to 🏗 In progress in Openverse Backlog Sep 28, 2023
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in Openverse Backlog Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤖 aspect: dx Concerns developers' experience with the codebase ✨ goal: improvement Improvement to an existing user-facing feature help wanted Open to participation from the community 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: mgmt Related to repo management and automations
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants