podman auto-update: reject short image names on container creation

[tmds]

ExecStart has:

ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--sdnotify=container \
	-d \
	--replace \
	--name awesome-worker-app \
	--label io.containers.autoupdate=registry awesome-worker-app:latest

This container is running:

$ podman ps
CONTAINER ID  IMAGE                                COMMAND     CREATED        STATUS            PORTS                   NAMES
2fbeb5c35c56  localhost/awesome-worker-app:latest              7 minutes ago  Up 7 minutes ago                          awesome-worker-app

auto-update is checking docker.io:

$ podman auto-update 
UNIT                        CONTAINER                          IMAGE                      POLICY      UPDATED
awesome-worker-app.service  2fbeb5c35c56 (awesome-worker-app)  awesome-worker-app:latest  registry    failed
Error: registry auto-updating container "2fbeb5c35c5604996c22518047f33181282473f6f2f8077b8b47cfe3be9d4542": image check for "awesome-worker-app:latest" failed: reading manifest latest in docker.io/library/awesome-worker-app: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

I know I can fix this using io.containers.autoupdate=local.

Does it make sense to check docker.io for autoupdate=registry when the image is referenced as awesome-worker-app:latest (and localhost/awesome-worker-app:latest)?

cc @mheon @rhatdan

[rhatdan]

@vrothberg PTAL
Is this happening on a podman-machine?

[Luap99]

I think this is expected and why we have both io.containers.autoupdate=registry and io.containers.autoupdate=local so podman does not have to guess what it is.

[tmds]

This is on Fedora 36 with Podman 4.2.0.

I think local vs registry is about whether to try to pull the image.

What is unexpected for me is that for podman run awesome-worker-app:latest means localhost/awesome-worker-app:latest.
While for podman auto-update it means docker.io/library/awesome-worker-app:latest.

[vrothberg]

I will take a look. Podman should pull from localhost but it may be pulling from both, localhost and Docker.io for some reason. I’m traveling at the moment, so it may take a couple of days.

…

On Wed 21 Sep 2022 at 08:44, Tom Deseyn ***@***.***> wrote: This is on Fedora 36 with Podman 4.2.0. I think local vs registry is about whether to try to pull the image. What is unexpected for me is that for podman run awesome-worker-app:latest means localhost/awesome-worker-app:latest. While for podman auto-update it means docker.io/library/awesome-worker-app:latest. — Reply to this email directly, view it on GitHub <#15879 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZDRA62EQFHVUGLIC6SVXTV7L7KXANCNFSM6AAAAAAQR6A2DY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vrothberg]

OK, now I see it. awesome-worker-app:latest is not a valid input as auto updates require a full image reference.

It looks like a regression as Podman should error out on container creation.

[tmds]

It looks like a regression as Podman should error out on container creation.

You mean: dotnet run awesome-worker-app:latest should error out?

[vrothberg]

It looks like a regression as Podman should error out on container creation.

You mean: dotnet run awesome-worker-app:latest should error out?

Yes. See the following quote from the docs:

The registry policy requires a fully-qualified image reference (e.g., quay.io/podman/stable:latest) to be used to create the container. This enforcement is necessary to know which image to actually check and pull. If an image ID was used, Podman would not know which image to check/pull anymore

[vrothberg]

I opened #15933 to fix the underlying issue.

[tmds]

podman will now error out when creating a container with a short name if it has the auto-update label.

Another approach would be for auto-update to use the same image resolution for short-names as podman create/run.
(Or, to always use localhost when a short name is provided with the auto-update label.)

I'm laying out some options, because I like using short names for local images.

[vrothberg]

Another approach would be for auto-update to use the same image resolution for short-names as podman create/run.
(Or, to always use localhost when a short name is provided with the auto-update label.)

Those can be subject to change. It is non-deterministic. While images can still be rewritten via /etc/containers/registries.conf, I think that forcing users to specify a fully-qualified image name is the right thing to do.

Since auto updates are security relevant, I think it's important to have as less "magic" as possible.

I'm laying out some options, because I like using short names for local images.

Using localhost/foo:bar will still work. Only foo or foo:bar will be rejected.

[vrothberg]

To elaborate on the local images: The lookup order can vary based on the images present. Requesting a FQN there as well reduces ambiguity.

[rhatdan]

I agree FQN should be required.