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

Support pinning docker images by sha256 #1812

Open
3 tasks done
daneov opened this issue Apr 7, 2024 · 3 comments
Open
3 tasks done

Support pinning docker images by sha256 #1812

daneov opened this issue Apr 7, 2024 · 3 comments
Labels
community type:enhancement New feature or request

Comments

@daneov
Copy link

daneov commented Apr 7, 2024

Please confirm the following

  • I agree to follow this project's code of conduct.
  • I have checked the current issues for duplicates.
  • I understand that the AWX Operator is open source software provided for free and that I might not receive a timely response.

Bug Summary

Currently to override an image we need to provide both the image name and the tag, which is joined together by doing {{ image }} + ':' + {{ tag }}.

Because of this it is not possible to pin an image to the sha256 hash at the time of deployment, opening it up to images being replaced at a later time and thus opening up security issues.

AWX Operator version

2.14.0

AWX version

24.1.0

Kubernetes platform

kubernetes

Kubernetes/Platform version

1.27

Modifications

no

Steps to reproduce

Define an override for an image with the sha256:

redis_image: docker.private.registry.com/redis@sha256:7635b0bfdd7dd8552b4b31d6541fef07b734614045b45a52fd5cc27c9dada9e2

Expected results

To be able to specify any image by the sha256 reference.

redis_image: docker.private.registry.com/redis@sha256:7635b0bfdd7dd8552b4b31d6541fef07b734614045b45a52fd5cc27c9dada9e2

Actual results

This does not get propagated (can't remember if it halts deployment as well, I think it did but I'm not at work at this time)

Additional information

Currently, you'd override the following fields on the kind: AWX deployment (See #1441):

redis_image: docker.private.registry.com/redis
redis_image_version: latest

But using the sha it breaks the concatenation at

- name: Set default redis image
set_fact:
_default_redis_image: "{{ _redis_image }}:{{ _redis_image_version }}"
, but I'd expect this to function for all image overrides.

Operator Logs

No response

@kurokobo
Copy link
Contributor

kurokobo commented Apr 7, 2024

@daneov
Hi, does this meet your requirements?

  redis_image: docker.private.registry.com/redis@sha256
  redis_image_version: 7635b0bfdd7dd8552b4b31d6541fef07b734614045b45a52fd5cc27c9dada9e2

@daneov
Copy link
Author

daneov commented Apr 7, 2024

Thanks for getting back to me!
I've considered that but decided against it as I thought it brittle: it builds on internal knowledge of how the AWX-operator playbook works and is not intuitive.

Would this be the advised way, or do you think of it as something to get me going?

For me this would not work as we have tooling that looks for image records :

  1. e.g. RenovateBot
  2. Internal tooling that replaces image: <image>:<tag> in the yaml with image: <image>@<sha_hash to ensure immutability on our k8s deploy.

@kurokobo
Copy link
Contributor

kurokobo commented Apr 7, 2024

Hi, my idea is just a workaround 😃
As an alternative workaround, you can also specify custom image by adding environment variable RELATED_IMAGE_AWX_REDIS = "docker.private.registry.com/redis@sha256:7635b0bfdd7dd8552b4b31d6541fef07b734614045b45a52fd5cc27c9dada9e2" for Operator's deployment.

Of course the above approaches are not ideal, and I think it is a good RFE to suggest that native @DIGEST support should be provided.

@TheRealHaoLiu TheRealHaoLiu added the type:enhancement New feature or request label Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community type:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants