How can we have a custom action created via the helm chart?

[jessebot]

I'm working on some infrastructure as code to bootstrap zitadel and Argo CD. I found this helpful discussion in the argo-cd repo that mentions creating a custom action to get argo-cd and zitadel working nicely together. I'm not sure how to make sure this action is created at install time with this chart though. Should it be passed into a configMap somewhere?

I noticed that in the values.yaml that there's a link to the defaults.yaml that shows an actions section:

# Default values for zitadel.
zitadel:
  # The ZITADEL config under configmapConfig is written to a Kubernetes ConfigMap
  # See all defaults here:
  # https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml
  configmapConfig:
    Database:
      cockroach:
        Host: "crdb-public"
        User:
          SSL:
            Mode: "verify-full"
        Admin:
          SSL:
            Mode: "verify-full"

    Machine:
      Identification:
        Hostname:
          Enabled: true
        Webhook:
          Enabled: false

However in the default.yaml, I only see a couple of sub-sections for Actions:

Actions:
  HTTP:
    # Wildcard sub domains are currently unsupported
    DenyList:
      - localhost
      - "127.0.0.1"

My confusion is due to the fact that the structure doesn't seem to match the actual action input in the GUI:

Would the values I pass in be something like this?

zitadel:
  configmapConfig:
    Actions:
      groupsClaim:
        allowedToFail: true
        timeout: 10
        script: |
          function groupsClaim(ctx, api) {
            if (ctx.v1.user.grants === undefined || ctx.v1.user.grants.count == 0) {
              return;
            }

            let grants = [];
            ctx.v1.user.grants.grants.forEach(claim => {
              claim.roles.forEach(role => {
                  grants.push(role)  
              })
            })

            api.v1.claims.setClaim('groups', grants)
          }

I guessed based on the api docs here, but I can't tell if the parameter for the name should also be passed in like this?

zitadel:
  configmapConfig:
    Actions:
      groupsClaim:
        name: groupsClaim
...

Also do I still need to include the default HTTP action, something like this?

zitadel:
  configmapConfig:
    Actions:
      HTTP:
        # Wildcard sub domains are currently unsupported
        DenyList:
          - localhost
          - "127.0.0.1"
      groupsClaim:
        name: groupsClaim
 ...

Thanks for any pointers you can give and thanks for maintaining this helm chart :)

[fforootd]

Hi, thanks for asking and sharing 😁 I was not aware people integrated ArgoCD

At the moment the defaults.yml mainly includes runtime configuration that we need to start zitadel. So most of the resources can't be configured through this. The actions sections ATM only defines allow/deny list for the http method provided by the actions runtime.

To declarative bootstrap resources one could either write an operator that uses our go-sdk (or APIs) or use the TF provider.

Btw. what currently is possible is to start zitadel with a service account that can be used to connect to the API or with TF.
https://zitadel.com/docs/self-hosting/deploy/kubernetes#setup-zitadel-and-a-service-account-admin

[jessebot]

Awesome, thank you so much for your prompt and helpful response!

To declarative bootstrap resources one could either write an operator that uses our go-sdk (or APIs) or use the TF provider.

Oh, neat, this is exciting! For now, I'm working to just setup Argo CD and Vouch behind zitadel as both work with keycloak right now, and that covers the bulk of my devops home-lab needs, but if I'd be setting this up for a client, it would be really nice to have everything k8s-first as it cuts terraform out of the picture.

The initial code I'd be writing would be for Users, Roles, Grants, Actions, and I suppose Applications in order to satisfy my current needs. I might as well make it an operator, but I haven't written one before. I know golang well enough and k8s architecture is what I do for a living, so it can't be that hard. Would you be interested in a PR to this repo after I do some initial testing? In my current backlog, that's probably around 2-3 weeks down the road.

[fforootd]

Would you be interested in a PR to this repo after I do some initial testing? In my current backlog, that's probably around 2-3 weeks down the road.

Sure we always appreciate the work of our community!

Using Zitadel with CRDs would certainly be a cool approach for the k8s community!
We could extend our helm chart to deploy an operator that in turn manages the resources.

If you need any guidance or help to get started feel free to keep the discussion here or join our discord server zitadel.com/chat