Automatically allow images for allowed extensions to be pulled

[jandubois]

I don't know if this has been implemented: every allowed extension must internally also be added to the allowed images list, if allowed image checking has been enabled as well.

Originally posted by @jandubois in #4655 (comment)

[mook-as]

• What should happen if the extension allow list is not enabled?
• What should happen if the extension allow list includes specific tags? Can the user pull images from different tags (since we haven't implemented the image allow list with tags properly)?
• Assuming both the image allow list and extension allow list are enabled, would this confuse administrators when people could pull & run images they haven't put into the image allow list (without actually trying to run it as an extension)?

[jandubois]

• What should happen if the extension allow list is not enabled?

Then the names should not be added.

• What should happen if the extension allow list includes specific tags? Can the user pull images from different tags (since we haven't implemented the image allow list with tags properly)?

Yes, the images are added without tags to the Allowed Images list. The current proxy mechanism for filtering doesn't allow us to implement filtering by tag because it requires access to the actual data (manifests) and not just the URLs. Current filtering just adds redirects based on the URL.

• Assuming both the image allow list and extension allow list are enabled, would this confuse administrators when people could pull & run images they haven't put into the image allow list (without actually trying to run it as an extension)?

I would hope not, but we can point it out in the documentation. If they trust the image to be allowed as an extension (where they can execute arbitrary code on the host), why would they want to block the user from running the image as a container?

[jandubois]

Just to be explicit: The allowed extensions would be added ephemerally when writing the nginx config file. They would not be added to the Allowed Images preference setting, so would not show up in the dialog, and would not be written to settings.json.

[mook-as]

Imagine an extension, example.com/foo. The admin allows example.com/foo:1.2, because example.com/foo:1.1 had an issue. But the user would be able to pull example.com/foo:1.1 (running as a container rather than an extension), because we don't support tags in the image allow list.

Completely separate: extensions can run containers, using arbitrary images (not just the extension image). Or they can come with a compose file, which again supports arbitrary images. What should happen in that case?

[jandubois]

Imagine an extension, example.com/foo. The admin allows example.com/foo:1.2, because example.com/foo:1.1 had an issue. But the user would be able to pull example.com/foo:1.1 (running as a container rather than an extension), because we don't support tags in the image allow list.

Yes, but there is no way around this. There are limits as to what you can do in filtering pull requests. The mechanism is to avoid accidental policy violations. You can't stop a malicious user this way, who could always download an images as a tarball to the host and install it with docker load. Or whatever. Same way a user with an editor and a compiler can build any app locally.

Completely separate: extensions can run containers, using arbitrary images (not just the extension image). Or they can come with a compose file, which again supports arbitrary images. What should happen in that case?

The images would still be subject to the Allowed Images list.

This actually illustrates one benefit of the Allowed Images list: it prevents accidental indirect installation of images from unapproved locations. Also helps with helm charts, that might request an image from a source you did not anticipate.