The GitLab PM responsible for the agent for Kubernetes work here. The agent supports automatic (and short lived) support for registry keys for the push-based a

The GitLab PM responsible for the agent for Kubernetes work here. The agent supports automatic (and short lived) support for registry keys for the push-based approach with [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy https://docs.gitlab.com/ee/topics/autodevops/stages.html#aut...), and we have documented how one can [set up container registry keys for the pull-based approach](https://docs.gitlab.com/ee/user/clusters/agent/gitops/secrets_management.html https://docs.gitlab.com/ee/user/clusters/agent/gitops/secret...) The difference between Argo/Flux and the agent is that Argo and Flux are pull-based deployment point solutions (especially Flux), while the agent (originally built on shared codebase with Argo) is the basic integration layer for GitLab - Kubernetes connections. This way, already today, GitLab provides integrated container vulnerability scanning that is out of scope for the other tools. About the half-stitched solution, among the three mentioned tools, only the agent supports server-side applies. The others have it as planned features. If you ever struggled with setting up the right annotations to use pull-based deployments and any competing controller at the same time, using server-side applies provides a lot of benefits.