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

[Bug]: when config.yaml is stored in a kubernetes secret certain values are ignored #171

Closed
2 tasks done
ilbarone87 opened this issue Feb 17, 2024 · 3 comments · Fixed by #181
Closed
2 tasks done
Labels
bug Something isn't working devops

Comments

@ilbarone87
Copy link

ilbarone87 commented Feb 17, 2024

Preflight Checklist

  • I could not find a solution in the documentation, the existing issues or discussions
  • I have joined the ZITADEL chat

Version

7.6.1

App version

2.45

Describe the problem caused by this bug

Seems that certain values such as "FirstInstance" are ignored when they need to be picked up from a kubernets secret.
I tend to exclude any running condition as the value "host" for the postgres database is picked up correctly.
This is my secret deployed through External Secret Operator

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
  creationTimestamp: '2024-02-17T11:21:57Z'
  generation: 1
  labels:
    app.kubernetes.io/instance: zitadel
  name: zitadel-config-secrets
  namespace: zitadel
spec:
  data:
    - remoteRef:
        conversionStrategy: Default
        decodingStrategy: None
        key: zitadel/zitadel-credentials
        metadataPolicy: None
        property: username
      secretKey: user
    - remoteRef:
        conversionStrategy: Default
        decodingStrategy: None
        key: zitadel/zitadel-credentials
        metadataPolicy: None
        property: password
      secretKey: password
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: zitadel-vault
  target:
    creationPolicy: Owner
    deletionPolicy: Retain
    name: config-secrets
    template:
      data:
        config.yaml: |
          Database:
            Postgres:
              Host: "{{ `{{ .host }}` }}"

          Machine:
            Identification:
              Hostname:
                Enabled: true
              Webhook:
                Enabled: false
          FirstInstance:
            InstanceName: ZITADEL
            DefaultLanguage: en
            Org:
              Name: Org
              Human:
                UserName: "{{ `{{ .user }}` }}"
                FirstName: Name
                LastName: Surname
                NickName: nickname
                DisplayName: name surname
                Email:
                  Address: email@address.com
                  Verified: true
                PreferredLanguage: en
                Password: "{{ `{{ .password }}` }}"
                PasswordChangeRequired: false

          CorrectCreationDate:
            FailAfter: 5m

          AddEventCreatedAt:
            BulkAmount: 100
      engineVersion: v2
      mergePolicy: Replace
status:
  binding:
    name: config-secrets
  conditions:
    - lastTransitionTime: '2024-02-17T11:21:59Z'
      message: Secret was synced
      reason: SecretSynced
      status: 'True'
      type: Ready
  refreshTime: '2024-02-17T11:21:58Z'
  syncedResourceVersion: 1-d88088a664abfc0f705ff670bb528ddb

this is my chart values.yaml file (adding only the relevant chunk)

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:
    ExternalDomain: zitadel.mydomain.com

    TLS:
      Enabled: false

    ExternalSecure: true
    ExternalPort: 443
    Database:
      Postgres:
        Port: 5432
        Database: zitadel
        MaxOpenConns: 20
        MaxIdleConns: 10
        MaxConnLifetime: 30m
        MaxConnIdleTime: 5m
        User:
          Username: zitadel
          SSL:
            Mode: verify-full
        Admin:
          Username: postgres
          SSL:
            Mode: verify-full


  # The ZITADEL config under secretConfig is written to a Kubernetes Secret
  # See all defaults here:
  # https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml
  secretConfig:

  # Annotations set on secretConfig secret
  secretConfigAnnotations:
    helm.sh/hook: pre-install,pre-upgrade
    helm.sh/hook-delete-policy: before-hook-creation
    helm.sh/hook-weight: "0"

  # Reference the name of a secret that contains ZITADEL configuration.
  configSecretName: config-secrets
  # The key under which the ZITADEL configuration is located in the secret.
  configSecretKey: config.yaml

Looking in the DB only the zitadel-admin user is created while there should be another user created with the FIrstInstance values provided in the secret

image

As you can also see the different timestamp values between the secret synchronisation and the user creation.

To reproduce

Use this example chart from https://github.com/zitadel/zitadel-charts/tree/main/examples/5-referenced-secrets

and then add to the referenced secret this:

FirstInstance:
  InstanceName:
  DefaultLanguage: en 
  Org:
    Name: ZITADEL
    Human:
      UserName: my-personal-username
      Email:
        Address: emailaddress
        Verified: false 
      Password: password

tested both with ArgoCD deployment and HELM cli from local

Logs

No response

Expected behavior

The user from FIrstInstance being created correctly

Relevant Configuration

Configuration is taken from here https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml

Additional Context

K8s version: rke2 1.27.10
ArgocCD: 2.10.6

@ilbarone87 ilbarone87 added the bug Something isn't working label Feb 17, 2024
@ilbarone87
Copy link
Author

Any update on this?

@fforootd
Copy link
Member

I haven not had time to look at it, but I am sure somebody will soon.

@eliobischof eliobischof linked a pull request Mar 1, 2024 that will close this issue
11 tasks
@eliobischof
Copy link
Member

@ilbarone87 thanks for reporting this bug. I linked the #181 that fixes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working devops
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants