feat: add image digest
This MR adds image digest to the container spec.
Related MRs:
- Build and Deploy jobs gitlab-org/gitlab!68783 (merged)
- auto-build-image auto-build-image!75 (merged)
Merge request reports
Activity
Thank you for your contribution to GitLab. We believe that everyone can contribute and contributions like yours are what make GitLab great!
- Our Merge Request Coaches will ensure your contribution is reviewed in a timely manner*.
- You can comment
@gitlab-bot label ~"group::"
to add a group label. - After a few days, feel free to ask
@gitlab-bot help
or ping a Merge Request Coach. - Read more how to get help.
This message was generated automatically. You're welcome to improve it.
added Community contribution label
mentioned in merge request gitlab-org/gitlab!68783 (merged)
mentioned in merge request auto-build-image!75 (merged)
added 1st contribution label
mentioned in issue gitlab-org/quality/triage-reports#4364 (closed)
mentioned in issue gitlab-org/quality/triage-reports#4366 (closed)
mentioned in issue gitlab-org/quality/triage-reports#4368 (closed)
added Category:Auto DevOps backend devopsconfigure [DEPRECATED] labels
Setting label(s) ~"group::configure" sectionops based on Category:Auto DevOps ~"group::configure".
added groupconfigure [DEPRECATED] sectionops labels
requested review from @zmartins
assigned to @kinolaev
@kinolaev
Thank you once again for your contribution.My apologies if I am lacking context on this change but it seems that this MR is dependent on the approach currentl proposed in auto-build-image!75 (merged) so my suggestion is to wait for the dependencies to get merged before moving forward with this one.
Thanks you also for adding the motivation as part of gitlab-org/gitlab!68783 (merged):
Until gitlab-org/gitlab#18984 (closed) is implemented, a user with the developer role can deploy thier code to production environment without the maintainer approval by updating production container image in registry, and this is a security risk. This and related MRs prevents such situations by adding the image digest to the container spec when deploying to k8s. The developer can still update (or delete) the production container image in registry, but the updated image will not be deployed to the production environment.
I was wondering if the scenario you are referring to is: (1) a developer changing the image and pushing it directly to the registry OR (2) a developing changing the image by having a new commit into a specific branch.
please let me know your thoughts on the above.
Hello @zmartins!
I refer to scenario 1, when a developer is pushing their image with commit tag of main branch directly to the registry, so k8s will use that image while starting a pod on a new node.
I don't think of auto-build-image!75 (merged) as a dependency, but rather as one of three parts of one feature - image pinning, so first I want to know is this feature interesting for gitlab auto devops team and if yes all three MR can be merged in any order.
On it's own, I am not sure if we should be getting the digest from a (arbitrary) file.
A thought I had is to get read the image digest here, and then use that to pin the
image
in theDeployment
resource. Of course, that leaves a time window between the build stage, and this job where developer can update the image. Still, better than nothing ?WYDT @kinolaev ?
/cc @hfyngvason @zmartins
Edited by Thong KuahThat was my first MR !212 (closed)) Yes, it's better than nothing but maintainer must verify manually on each commit that image was not updated between build and production jobs. So I think that passing digest as artifact is better and I don't see any potential problems with it. Do you?
As we discussed in gitlab-org/gitlab!68783 (merged) we can make dependency optional to allow using Deploy.gitlab-ci.yml without Build.gitlab-ci.yml (I think this is a really rare case) or just document that Deploy.gitlab-ci.yml requires job named build (atrifact image_digest.txt is already optional).
Edited by Sergei NikolaevOn it's own, I am not sure if we should be getting the digest from a (arbitrary) file.
Agreed. However, given that we already have
CI_APPLICATION_TAG
, maybe we can export aartifacts:reports:dotenv
fromBuild.gitlab-ci.yml
that includes the digest? Then,auto-deploy-image
wouldn't need to know about this detail at all. Unfortunately, we would still need a dependency onbuild
inDeploy.gitlab-ci.yml
to tie it together, which is being discussed in gitlab-org/gitlab!68783 (merged).Regarding safety of the dotenv addition: This would override YAML
variables
, but have a lower priority than any other user-defined variable (instance, group, project, pipeline), so it would probably be a safe change to make.Hello @hfyngvason! Ok, I will make dependency on build optional with
needs
and add digest toCI_APPLICATION_TAG
(interesting idea). Thank you!So, upon further thought, there is one risk with adding it as
CI_APPLICATION_TAG
: Breaking workflows relying onimagePullPolicy: Always
to rebase their images without a redeployment. With the image digest appended, they would need to rerun both the build and the deployment job to achieve the same effect.This seems like a relatively low-risk scenario, as the above workflow is hardly supported by Auto DevOps already. I don't think there's a reasonable way to restart all pods from within Auto DevOps besides changing the deployment manifest, which should generally not happen on redeployment right now.
In fact, by adding the digest, we actually make it easier to achieve this, and make it a safe operation, as the user should be able to revert to a previous digest by overriding
CI_APPLICATION_TAG
.
requested review from @tkuah
removed review request for @tkuah
I updated MR gitlab-org/gitlab!68783 (merged) and this MR is not needed any more, so I close it.
added groupenvironments label and removed groupconfigure [DEPRECATED] label