[Bug]: Helm Chart Existing Secret Admin Account Support #661

New Issue

OVERLORD · 2026-02-04T20:44:40+03:00

OVERLORD commented

2026-02-04 20:44:40 +03:00

Originally created by @h00lig4n on GitHub (Mar 5, 2025).

Where is the problem occurring?

I encountered the problem while using the application (Frontend)

What browsers are you seeing the problem on?

Brave, Chrome

Current behaviour

Hi,

This might be an inquiry, bug report or feature request...

Firstly, I can deploy Planka fine using admin_email in values.yaml, as per docs. It does state run with admin credentials parms in chart first and then remove from chart.

For both security and Gitops I would prefer to deploy a secret (sealed) separately and don't want to put admin creds into the valuesfile.

I'm trying to understand if this should work, (here's what it states in the chart:

## @param existingAdminCredsSecret Name of an existing secret containing the admin username and password
## NOTE: Must contain keys `username` and `password`
## NOTE: When it's set, the `admin_username` and `admin_password` parameters are ignored
existingAdminCredsSecret: ""

I not sure how existingAdminCredsSecret is used if it's not for this scenario? Should this work or is it unsupported?

The following setup gives me a running Planka instance with db schema, but no admin user in the db.

apiVersion: v1
kind: Secret
metadata:
  name: planka
  namespace: default
  labels:
    app: planka
type: kubernetes.io/opaque
stringData:
  key: mykey
  email: "myemail
  password: "mypassword"
  name: "admin"
  username: "admin"
  uri: postgresql://planka:mypassword@postgresql.common.svc.cluster.local:5432/planka

Which I reference through values.yaml

        existingSecretkeySecret: planka
        existingAdminCredsSecret: planka
        nodeSelector:
          node-role.kubernetes.io/worker: "true"
        resources:
          limits:
             cpu: 500m
             memory: 256Mi
          requests:
             cpu: 100m
             memory: 64Mi
        postgresql:
          enabled: false
        existingDburlSecret: planka
        persistence:
          enabled: true
          existingClaim: planka
          storageClass: "nfs"
          accessMode: ReadWriteOnce
          size: 10Gi
        ingress:
          enabled: true
          className: traefik
          hosts:
            - host: plan.mydomain
              paths:
                - path: /
                  pathType: Prefix
          tls:
            - secretName: tls-certificate
              hosts:
                - plan.mydomain

Desired behaviour

Installation should try and create/update admin user from Secret when provided in existingAdminCredsSecret.

Steps to reproduce

Refer to current behavior. Running on K3S, Helm via ArgoCD.

Other information

No response

Originally created by @h00lig4n on GitHub (Mar 5, 2025). ### Where is the problem occurring? I encountered the problem while using the application (Frontend) ### What browsers are you seeing the problem on? Brave, Chrome ### Current behaviour Hi, This might be an inquiry, bug report or feature request... Firstly, I can deploy Planka fine using admin_email in values.yaml, as per docs. It does state run with admin credentials parms in chart first and then remove from chart. For both security and Gitops I would prefer to deploy a secret (sealed) separately and don't want to put admin creds into the valuesfile. I'm trying to understand if this should work, (here's what it states in the [chart](https://github.com/plankanban/planka/blob/master/charts/planka/values.yaml): ``` ## @param existingAdminCredsSecret Name of an existing secret containing the admin username and password ## NOTE: Must contain keys `username` and `password` ## NOTE: When it's set, the `admin_username` and `admin_password` parameters are ignored existingAdminCredsSecret: "" ``` I not sure how existingAdminCredsSecret is used if it's not for this scenario? Should this work or is it unsupported? The following setup gives me a running Planka instance with db schema, but no admin user in the db. ``` apiVersion: v1 kind: Secret metadata: name: planka namespace: default labels: app: planka type: kubernetes.io/opaque stringData: key: mykey email: "myemail password: "mypassword" name: "admin" username: "admin" uri: postgresql://planka:mypassword@postgresql.common.svc.cluster.local:5432/planka ``` Which I reference through values.yaml ``` existingSecretkeySecret: planka existingAdminCredsSecret: planka nodeSelector: node-role.kubernetes.io/worker: "true" resources: limits: cpu: 500m memory: 256Mi requests: cpu: 100m memory: 64Mi postgresql: enabled: false existingDburlSecret: planka persistence: enabled: true existingClaim: planka storageClass: "nfs" accessMode: ReadWriteOnce size: 10Gi ingress: enabled: true className: traefik hosts: - host: plan.mydomain paths: - path: / pathType: Prefix tls: - secretName: tls-certificate hosts: - plan.mydomain ``` ### Desired behaviour Installation should try and create/update admin user from Secret when provided in existingAdminCredsSecret. ### Steps to reproduce Refer to current behavior. Running on K3S, Helm via ArgoCD. ### Other information _No response_

OVERLORD closed this issue

2026-02-04 20:44:46 +03:00

OVERLORD commented

2026-02-04 20:44:50 +03:00

@h00lig4n commented on GitHub (Mar 5, 2025):

Update:
I set admin_email and admin_name in values.yaml as well as specify secret.
It takes username and password from the secret, and admin_email and admin_name from the admin parameters :).
I guess this is what it actually states in the documentation, but it's perhaps a little confusing.

admin_email: "notmy.email@spam.me"
admin_name: "Admin"
existingSecretkeySecret: planka
existingAdminCredsSecret: planka

@h00lig4n commented on GitHub (Mar 5, 2025): Update: I set admin_email and admin_name in values.yaml as well as specify secret. It takes username and password from the secret, and admin_email and admin_name from the admin parameters :). I guess this is what it actually states in the documentation, but it's perhaps a little confusing. ``` admin_email: "notmy.email@spam.me" admin_name: "Admin" existingSecretkeySecret: planka existingAdminCredsSecret: planka ```

OVERLORD commented

2026-02-04 20:44:56 +03:00

@justmitch123 commented on GitHub (Mar 6, 2025):

Hey @h00lig4n , I find the best documentation for helm tends to be reading the raw charts.

https://github.com/plankanban/planka/blob/master/charts/planka/templates/deployment.yaml#L126-L136 is where the secrets get used. So in this sense, existingAdminCredsSecret is the name of the secret that you have created (in your case planka ) and the admin username and password will be set to the contents of the secret with the keys of username & password

There are a fair few secrets in this file that work similarly so that you can create the secret object, as you have, and the planka chart can consume them.

@justmitch123 commented on GitHub (Mar 6, 2025): Hey @h00lig4n , I find the best documentation for helm tends to be reading the raw charts. https://github.com/plankanban/planka/blob/master/charts/planka/templates/deployment.yaml#L126-L136 is where the secrets get used. So in this sense, `existingAdminCredsSecret` is the name of the secret that you have created (in your case `planka` ) and the admin username and password will be set to the contents of the secret with the keys of `username` & `password` There are a fair few secrets in this file that work similarly so that you can create the secret object, as you have, and the planka chart can consume them.

OVERLORD commented

2026-02-04 20:45:13 +03:00

@h00lig4n commented on GitHub (Mar 6, 2025):

Hey @h00lig4n , I find the best documentation for helm tends to be reading the raw charts.

https://github.com/plankanban/planka/blob/master/charts/planka/templates/deployment.yaml#L126-L136 is where the secrets get used. So in this sense, existingAdminCredsSecret is the name of the secret that you have created (in your case planka ) and the admin username and password will be set to the contents of the secret with the keys of username & password

There are a fair few secrets in this file that work similarly so that you can create the secret object, as you have, and the planka chart can consume them.

Hi,

Thanks for the response, and good advice. I'll close this. It works as posted in my last comment.

I guess the only observation is that you need to specify admin_email and admin_name in the values for it to create the account.
It does mean I need to check in a bogus email into git, which is not a biggy.

Speculating this might be an issue if configuring OIDC and needing a real email, although I haven't looked at that config yet so just speculating.

@h00lig4n commented on GitHub (Mar 6, 2025): > Hey [@h00lig4n](https://github.com/h00lig4n) , I find the best documentation for helm tends to be reading the raw charts. > > https://github.com/plankanban/planka/blob/master/charts/planka/templates/deployment.yaml#L126-L136 is where the secrets get used. So in this sense, `existingAdminCredsSecret` is the name of the secret that you have created (in your case `planka` ) and the admin username and password will be set to the contents of the secret with the keys of `username` & `password` > > There are a fair few secrets in this file that work similarly so that you can create the secret object, as you have, and the planka chart can consume them. Hi, Thanks for the response, and good advice. I'll close this. It works as posted in my last comment. I guess the only observation is that you need to specify admin_email and admin_name in the values for it to create the account. It does mean I need to check in a bogus email into git, which is not a biggy. Speculating this might be an issue if configuring OIDC and needing a real email, although I haven't looked at that config yet so just speculating.

OVERLORD referenced this issue

2026-02-04 21:12:25 +03:00

[Bug]: Unable to create more than 1 project #749

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#661