Specify multiple stage in kargo.akuity.io/authorized-stage:

[hamadodene]

Hi Kargo Community,

I'm new to Kargo and currently setting up a pipeline to manage image promotions for all my applications.

I have many apps deployed using ArgoCD, and I use an ApplicationSet with the Git directory generator to create one Application per app.

Some of these apps are very similar — for example, they use the same base image (e.g., httpd) but serve different content by mounting different volumes. To support this, I've configured Kargo to update both the tag and digest and to restart all applications that use the same image.

Because I use a monorepo, some applications share the same image and others do not:

• For apps not sharing the same image, each app has its own Warehouse, Stage, PromotionTask, etc.
• For apps sharing the same image, I created a single Warehouse, Stage, and PromotionTask. This setup updates a shared YAML file used by all of these apps.

Here’s where I’m running into trouble:
To allow Kargo to sync an ArgoCD app, I need to add the annotation kargo.akuity.io/authorized-stage: <project-name>:<stage-name>. Since I’m generating my apps via ApplicationSet, I wanted to dynamically set the annotation using something like:

kargo.akuity.io/authorized-stage: 'kargo-it-{{app.path[1]}}:{{app.path[2]}}'

1. {{app.path[1]}} corresponds to the namespace.
2. {{app.path[2]}} is the app name.

This works well for apps with their own Stage. However, for apps that share a common image, they all rely on a single Stage with a generic name (e.g., httpd-stage). Because I use a single ApplicationSet for all apps, I’d prefer to support multiple authorized stages in a single annotation. For example:

kargo.akuity.io/authorized-stage: 'project1:stage1,project2:stage2'

My question is:

• Is it currently possible in Kargo to specify multiple stages in the kargo.akuity.io/authorized-stage annotation?
• If not, is there a recommended way to handle this use case without splitting into multiple ApplicationSets? I’d really prefer to keep all apps managed in one ApplicationSet for simplicity and maintainability.

Thanks in advance for your help!

[krancour]

I'm not quite following your setup, but it probably doesn't matter too much...

This has been discussed many times before, however, the request has usually been to support globs or regex. Those we cannot do on security grounds. This annotation is the only way we have for an Application to express "consent" to be modified by Kargo. The annotation would have to have been placed there by someone with proper permissions to create/update the Application, so its existence is that user's consent to delegate that permission to a particular Kargo Stage. The problem with globs or patterns is that it would allow for anyone who is able to create new Stages to create one with a name specifically engineered to allow unauthorized mutation of the Application by that Stage.

This has been discussed as recently as lastnight.

The request for "multiple Stages," however, assuming they're simply comma-delimited or something, with no support for globs or patterns seems safe. We could at least entertain that, however, a potentially superior solution has just occurred to me...

In the vast, vast majority of cases, the argocd-update promotion step is being used only to force the Application to sync and not used to mutate the Application in other ways. (Doing things like updating target revisions, Helm values, or Kustomize parameters are doable as well, but they're frowned upon and considered "pseudo-GitOps.")

I'm cautiously proposing now that it would be safe enough to allow forced syncing but no other mutations without any annotation/consent required. I can think of very limited harm that could arise from (anyone, essentially) requesting an Application to do nothing more than (re)-progress toward its existing understanding of desired state.

cc @hiddeco and @jessesuen in case they see vulnerabilities here that I do not.

If we were able to do this, it would solve a lot of problems for a lot of people.

[krancour]

@kamilatwork the idea here is not to add an await step but to allow the existing update step to sync an App on behalf of many Stages. That step already waits for completion of a sync it initiated.

[kamilatwork]

Yes, I know those are two somewhat unrelated issues. What I meant was that if argocd-await step is introduced (or argocd-update gets an option to not trigger sync) it shouldn't need to require authorized-stage annotation, just like you said, since it merely monitors an App.

[krancour]

argocd-update will not get an option to not trigger a sync. I proposed that if it's only triggering a sync, that is the circumstance under which we can probably relax things. Anything else definitely still requires some form of consent from the App.

[sbyrne-teck]

Any thoughts on a milestone release for this @krancour?. Eager to write an estimated date into my plan.

[hamadodene]

@krancour Should I create an issue for this, or will you take care of it?

[hamadodene]

Hi @krancour,

Thanks for your reply!
In my setup, this detail might not matter too much, but let me illustrate it anyway—it might help clarify why I’m approaching it this way.
My monorepo is structured like this (example for the dev environment; production is similar):

dev/<namespace_name>/<app_name>/ (helmfile.yaml + values.yaml)
To deploy all these apps, I use ArgoCD ApplicationSet with the Git directory generator.
Often, within the same namespace, multiple applications use the same base images. For example, we have many WordPress websites that all use the same httpd and php-fpm base images—the only variation is the mounted content.

I use Kargo solely to detect new image deployments, update the image tag, and trigger an ArgoCD app refresh.
Here's how I'm currently using Kargo:

1. I create a Kargo project per namespace.
2. For each application, I create a dedicated warehouse and stages.
3. Warehouses and stages are named using the app_name, and I dynamically set the kargo.akuity.io/authorized-stage annotation using the ApplicationSet path.
4. Each app has an image-config.yaml file located at:
   dev/<namespace_name>/<app_name>/image-config.yaml, which looks like:

tags:
  <app_name>:
    tag: 1.x

However, in cases like WordPress apps that all use the same image, I want to avoid duplicating warehouses and configs for each app. So instead:

1. I place a shared image-config.yaml at the namespace level:
2. dev/<namespace_name>/image-config.yaml.
3. I then create a generic warehouse and stage that updates this shared image config.
4. All applications in that namespace point to the same shared image-config.yaml.

Because this is a shared stage, I can’t dynamically set the stage via annotations using ApplicationSet like I can for app-specific stages.
The ideal solution for me would be the ability to:

1. Specify multiple stages for a single project, or
2. Specify multiple project+stage pairs for a single ArgoCD application.

Anyway,
I agree that using globs or regex for the authorized-stage annotation poses security risks, as anyone with permission to create new stages could potentially craft malicious names to gain unauthorized access. However, I believe supporting multiple stages specified explicitly as a comma-separated list is a safe and practical middle ground. Since the stages must be explicitly named by someone with appropriate permissions, I don’t think it introduces the same risks as pattern matching or globs, as you mentioned.

This approach is common in many Kubernetes tools and configuration systems where multiple values are provided explicitly, and it seems like a natural extension for Kargo. For example, apps like cert-manager or NGINX ingress-controller often use annotations with comma-separated lists to configure multiple values safely and explicitly.

[krancour]

Closing this and continuing the conversation in #4570.