evryfs / helm-charts Goto Github PK

Describe the bug
A clear and concise description of what the bug is.

I also filed issue directly to the dependency track repo as I do not know for sure whos issue is this: DependencyTrack/dependency-track#2374

We deployed Dependency-Track v4.7.0 via Helm chart on private Kubernetes cluster (chart repo https://github.com/evryfs/helm-charts/tree/master/charts/dependency-track). We have overridden parameters regarding dependency track application version (both frontend and apiserver), all LDAP connection parameters and Ingress definition, everything else is default.

After everything was successfully deployed and started (Kubernetes said that liveness and readiness are OK, we did not investigate the logs of particular pod), we started configuring application. We added some teams successfully, added some AD users, uploaded some BOM for projects and everything was running smooth.

After that we tried to delete some teams but received error, with stacktrace from apiserver pod below:

Version of Helm and Kubernetes:

Helm: 3.10.1
Kubernetes: 1.25.5_1525

Which chart:

evryfs-oss/dependency-track

What happened:

We are unable to delete teams which are added.

What you expected to happen:

To be able to delete arbitrary team if user

How to reproduce it (as minimally and precisely as possible):

1. Navigate to Settings -> Access Management ->Teams with admin user
2. Add some team
3. Try to delete it

Anything else we need to know:

I tried to install Dependency Track via Docker Compose (per instructions https://docs.dependencytrack.org/getting-started/deploy-docker/#quickstart-docker-compose) and I can add/delete teams without any error.

Describe the bug
When we install the dependency track 4.1.0 with the chart 1.0.0 with an ingress gateway enabled to expose the backend and frontend services. During the helm chart installation i get a validation error:

error validating "": error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "service" in io.k8s.api.networking.v1beta1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[1].backend): unknown field "service" in io.k8s.api.networking.v1beta1.IngressBackend]
helm.go:81: [debug] error validating "": error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "service" in io.k8s.api.networking.v1beta1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[1].backend): unknown field "service" in io.k8s.api.networking.v1beta1.IngressBackend]

Version of Helm and Kubernetes:
Helm 3.5.1
EKS Cluster: 1.18.9

Which chart:
Dependency Track 4.1.0 / Chart 1.0

What happened:
There is a validation error during the ingress services (frontend/backend) analysis. Maybe an error linked with the version of K8s apis used.

What you expected to happen:
The chart can be used with Kubernetes 1.18

How to reproduce it (as minimally and precisely as possible):
Install the dependency track with the chart and the config below for the ingress:

# Ingress entry point
ingress:
  enabled: true
  host: <Deptrak_FQDN>
  annotations: 
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    ingress.kubernetes.io/affinity: cookie
    ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: letsencrypt-issuer
  tls:
    enabled: true
    secretName: "dependency-track-tls"

Anything else we need to know:
I updated the code below:

  rules:
  - host: {{ .Values.ingress.host }}
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: {{ include "common.names.fullname" . }}-apiserver
            port:
              number: {{ .Values.apiserver.service.port }}
      - path: /
        pathType: Prefix
        backend:
          service:
            name: {{ include "common.names.fullname" . }}-frontend
            port:
              number: {{ .Values.frontend.service.port }}

Like that and it works fine after

  rules:
  - host: {{ .Values.ingress.host }}
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          serviceName: {{ include "common.names.fullname" . }}-apiserver
          servicePort: {{ .Values.apiserver.service.port }}
      - path: /
        pathType: Prefix
        backend:
          serviceName: {{ include "common.names.fullname" . }}-frontend
          servicePort: {{ .Values.frontend.service.port }}

Describe the bug
When i edit the configmap, nothing happens (e.g. adding ldap configuration). The configmap also contains h2 DB config although dependency-track uses postgresql DB.

Version of Helm and Kubernetes:
Helm version :
Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"}

Kubernetes version:
Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.7", GitCommit:"169db3bff4b5fb7722e967c5b6356713f05f15ed", GitTreeState:"clean", BuildDate:"2020-04-03T16:14:09Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
Dependency-track

What happened:
No changes are taking into account when modifying the configmap

What you expected to happen:
Changes are taking into account when modifying the configmap

How to reproduce it (as minimally and precisely as possible):
Install the chart, change something in the configmap.

Anything else we need to know:
The applications.properties file is correctly updated in the config folder, but the content is not used i think

Describe the bug

The default login of dependency-track doesn't work in the default installation of the chart. According to this dependency-track documentation the default password and user is admin. Upon entering that into the login page, I get a HTTP code 405.

Version of Helm and Kubernetes:

helm list -A -a                                                                                                                                                                                                                        
NAME            	NAMESPACE       	REVISION	UPDATED                                 	STATUS  	CHART                 	APP VERSION
dependency-track	dependency-track	1       	2022-04-21 20:49:32.994378524 +0200 CEST	deployed	dependency-track-1.3.5	4.4.2      

kubectl version                                                                                                                                                                                                                                    
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:45:37Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}

Which chart: dependency-track

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

To test and evaluate dependency-track I installed the chart into my local kind cluster via:

kind create cluster
helm install dependency-track evryfs-oss/dependency-track --namespace dependency-track --create-namespace

As a next step I opened a port forward:

 kubectl port-forward service/dependency-track-frontend 8080:80 -n dependency-track

In the browser I tried to login with username admin and password admin. I get the response code 405 Method not allowed.

I exported the request my browser did as cURL request:

curl 'http://127.0.0.1:8080/api/v1/user/login' \                                                                                                                                                                                                                        
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Origin: http://127.0.0.1:8080' \
  -H 'Pragma: no-cache' \
  -H 'Referer: http://127.0.0.1:8080/login?redirect=%2Fdashboard' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36' \
  -H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  --data-raw 'username=admin&password=admin' \
  --compressed
<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.20.2</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

Anything else we need to know:

Trying to deploy with helm on Openshift (4.5.16), error from deployment:

FailedCreate
create Pod dependency-track-postgresql-0 in StatefulSet dependency-track-postgresql failed error: pods "dependency-track-postgresql-0" is forbidden: unable to validate against any security context constraint: [fsGroup: Invalid value: []int64{1001}: 1001 is not an allowed group spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 1001: must be in the ranges: [1000740000, 1000749999]]

Here the helm chart installed:

$ helm list
NAME                    NAMESPACE               REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
dependency-track        dependency-track        1               2020-11-05 11:12:47.0016078 +0100 CET   deployed        dependency-track-0.2.4  3.8.0

Describe the bug
Not able to use ecr-proxy helm chart with IAM Role, without defining awsAccessKeyId and awsSecretAccessKey.

Version of Helm and Kubernetes:
Helm: 3.1.2
Kubernetes: 1.15

Which chart: ecr-proxy:.0.2.1

What happened:
Not able to use this chart by using secrets with awsAccessKeyId and awsSecretAccessKey define.

What you expected to happen:
Can able to deploy helm chart to use IAM role for ecr-proxy

How to reproduce it (as minimally and precisely as possible):
Just use AWS roles (without using access key and secret key)

Anything else we need to know:
This may be due usage of env variable with the name AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in deployment. Removal of this solve the issue.
https://github.com/evryfs/helm-charts/blob/master/charts/ecr-proxy/templates/deployment.yaml#L53

I can also create an MR if needed

I need to deploy this Helm chart but I need to use a PaaS database (azure postgresql) , nevertheless I can't change this chart to work properly with my PaaS database. Sorry to bought you guys but I'm recently started to learn about Helm and I really appreciate if any of you could help-me.

dependency-track has released new major version. Also the architecture is different from from 3.x. Can we add support for 4.x ?

https://docs.dependencytrack.org/changelog/

@davidkarlsen @stevespringett

Hi, I believe you need to update the dependency track README with the new version and appVersion badges/tags.

Also, would it be worth including a link to the Dependency Track Change Log so that users of the chart are aware of breaking changes/things they need to know prior to upgrading the chart? Thanks!

Describe the solution you'd like
Upgrade to latest dt: https://docs.dependencytrack.org/2022/02/17/v4.4.0/

Describe alternatives you've considered
N/A

Describe the bug
Just a minor one, but I believe the ingress.yaml which currently uses:

        backend:
          {{ include "common.ingress.backend" (dict "serviceName" (print (include "common.names.fullname" . ) "-apiserver") "servicePort" 80 "context" $) | nindent 10 }}
      - path: /
        pathType: Prefix
        backend:
          {{ include "common.ingress.backend" (dict "serviceName" (print (include "common.names.fullname" . ) "-frontend") "servicePort" 80 "context" $) | nindent 10 }}
{{- end }}

should be:

        backend: {{ include "common.ingress.backend" (dict "serviceName" (print (include "common.names.fullname" . ) "-apiserver") "servicePort" 80 "context" $) | nindent 10 }}
      - path: /
        pathType: Prefix
        backend: {{ include "common.ingress.backend" (dict "serviceName" (print (include "common.names.fullname" . ) "-frontend") "servicePort" 80 "context" $) | nindent 10 }}
{{- end }}

As the nindent creates a blank line in the first scenario.

Version of Helm and Kubernetes:

$ helm version
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v0.21.0-beta.1", GitCommit:"0d10c3f72592addce965b9bb34992eb6fc283a3b", GitTreeState:"clean", BuildDate:"2021-08-31T22:03:33Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.11+c343126", GitCommit:"f12ed970dad7592bafc187c70f6c2caa8fef8843", GitTreeState:"clean", BuildDate:"2021-12-03T22:44:45Z", GoVersion:"go1.15.14", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
Dependency Track

What happened:
See above

What you expected to happen:
No extra blank line in rendering of ingress.yaml

How to reproduce it (as minimally and precisely as possible):
Helm template can be used:

helm template mydeptrack ./ --set ingress.enabled=true --set ingress.host=myapp.test.cloud --output-dir render

Anything else we need to know:
Don't think so...

Idea is to implement function from this https://docs.dependencytrack.org/getting-started/internal-ca/

Hi there,

Given there are quite a few alerts I would like to suppress it would be great it there was an easy way on how to add a suppressions.xml file via e.g. a ConfigMap to the deployment.

Thanks

Hello everyone,
we are not able to deploy your Helm Chart for Dependency Track in our k8s cluster. The reason is that we can't connect the volume "data-dependency-track-postgresql-0" because the storageClass is not set.
Although we have set it in the values.yml.

  postgresql: 
    global: 
      storageClass: "ebs"
    persistence: 
      storageClass: "ebs"
  ingress:
    enabled: true
    hosts:
      - host: xxx.yyy.com
        paths:
          - "/"
    tls: 
      - secretName: secret-tls-certificate
        hosts:
          - xxx.yyy.com
  persistentVolume:
    enabled: true
    storageClass: "ebs"
  persistence:
    enabled: true
    storageClass: "ebs"

Is there a value we miss here?
The volume for dependency track is bound without problems.
Many thanks in advance

Describe the bug
A clear and concise description of what the bug is.

Reference Kubernetes secret is not clear if supported in values file for github app here , is it mount additional volume and reference the secret or reference the secret name directly. do we just reference the app id and the existing secret created from pem key ?

envFrom:

• secretRef:
  name: github-runner-app

Version of Helm and Kubernetes:

3 , 1.23

Which chart:

github-actions-runner-operator

Is your feature request related to a problem? Please describe.
When we deploy the dependency-track chart with nodeSelector values in values.yaml, nodeSelector doesn't come into effect in deployment.

Describe the solution you'd like
nodeSelector template should be added in templates/frontend/deployment.yaml and templates/backend/deployment.yaml. e.g:

templates/frontend/deployment.yaml:

  {{- with .Values.frontend.nodeSelector }}
  nodeSelector:
    {{- toYaml . | nindent 8 }}
  {{- end }}

templates/backend/deployment.yaml:

  {{- with .Values.apiserver.nodeSelector }}
  nodeSelector:
    {{- toYaml . | nindent 8 }}
  {{- end }}

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
We are running multiple ingressclasses, so we need to be able to specify the spec.ingressClassName on the ingress

Describe the solution you'd like
To be able to specify ingress.ingressClassName in the helm values.yaml file - this would then generate a spec.ingressClassName entry in the ingress, with the value that was specified in the values.yaml file

Describe alternatives you've considered
None really TBH - the deprecated kubernetes.io/ingress.class annotation no longer works on the latest controllers

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
I was trying to override the spec.paths values of my ingress, but the chart predefined paths kept overriding them, so i had to manually edit the values of the ingress through OpenLens app

Version of Helm and Kubernetes:
1.25 and 3.10.0

Which chart:
dependency-track

What happened:
my defined ingress rules are getting overridden by the charts defined values

What you expected to happen:
i want to set the ingress paths myself like this

spec:
  rules:
    - host: example.com
    - http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: dependency-track-apiserver
                port:
                  number: 8085
          - path: /
            pathType: Prefix
            backend:
              service:
                name: dependency-track-frontend
                port:
                  number: 8084

How to reproduce it (as minimally and precisely as possible):

use this values for your ingress

ingress:
  enabled: true
  tls:
    enabled: false
    secretName: ""
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
  host: example.com
spec:
  rules:
    - http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: dependency-track-apiserver
                port:
                  number: 8085
          - path: /
            pathType: Prefix
            backend:
              service:
                name: dependency-track-frontend
                port:
                  number: 8084

Anything else we need to know:

Dear Team, Thank you for excellent work. Let me apologize using bug template but I don't see any template which can be used for asking question.
I am trying to integrate dependency-track with Azuer OpenId and not sure how to do that as there is no single consolidated documentation available. I looked into multiple sources and got confused to be honest. Following is my finding and lots of questions may be :).

1. Default values.yaml

     frontend:
     enabled: true
     replicaCount: 2
     image:
       repository: dependencytrack/frontend
       tag: 4.4.0
       pullPolicy: IfNotPresent    
       configmap:
       config: |
         {
             "API_BASE_URL": "",
             "OIDC_ISSUER": "",
             "OIDC_CLIENT_ID": "",
             "OIDC_SCOPE": "openid profile email",
             "OIDC_FLOW": ""
        }    
     env:
       - name: API_BASE_URL
         value: ""
   
   

2. Is it possible to configure OpenId integration using config map shown above? Do we need to refer https://docs.dependencytrack.org/getting-started/configuration/.
3. Do we need to set API_BASE_URL? I am using nginx proxy so not providing any.
4. Then so get additional help, I googled and come across DependencyTrack/dependency-track#1104 (reply in thread).
   This has added more confusion as it has more environment variable for apiserver & frontend server.

What I am looking for is concreate steps which enables me to configure the integration. I promise to update documentation with exact steps and create the PR for you. You can directly reach out to me in Tietoevry.

Regards
Rahul Mahulkar

Is your feature request related to a problem? Please describe.
Please upgrade dependency-track chart to the latest version. The current version is 4.8.2.
https://docs.dependencytrack.org/changelog/
Describe the solution you'd like
Upgrade the helm chart to install the latest version of dependency-track

Describe alternatives you've considered
N/A

Additional context
N/A

My instance of dependency-track-apiserver seems to be having an issue creating the desired directories and it is causing the pod to crash because java is unable to open the needed log file. The pod is running as user 1001. Any guidance would be helpful.

Not a bug, but the page at https://evryfs.github.io/helm-charts/ returns a 404, preventing us from finding the github-actions-runner-operatorr chart.

I am trying to use the nvd mirror function of dependencytrack. However, in ingress, everything except the /api path is forwarded to the front-end.
When I select the mirror path, I always get a file not found page on the front-end.

Of course I just have to change the ingress setting every time. But I want to keep the value by using the settings in helm.

Add mirror path setting to "/helm-charts/tree/master/charts/dependency-track/templates/ingress.yaml"

thanks.

Add liveness/readiness probes, and maybe use startupprobes:
https://blog.devgenius.io/understanding-kubernetes-probes-5daaff67599a
for the api and frontend deployments.

Describe the solution you'd like
Adding probes help to check that the service is in fact starting as it should and healthy.

Describe alternatives you've considered
N/A

Additional context
Related: #63 but this died out.

We are hitting a small issue with the postgres DB not requesting enough CPU. I understand that most users might be running a separate psql, but it would be convenient to be able to configure the subchart in cases where the bundled one is enough.

I'm not a helm expert, but based on what I could read in the docs, it should be enough to just add everything from the postgresql chart's values.yaml and put it in the values file for Dependency Track.

If you can confirm that this is a good idea, and that my approach seems sound, I'll happily create a PR with the change.

Is your feature request related to a problem? Please describe.
I cannot pass values to the postgresql subchart. More specifically resource requests and limits for the chart.

Describe the solution you'd like
I can pass values to the postgresql subchart

Describe alternatives you've considered
I could deploy the postgresql chart separately, but in my case, i just need to tweak the resources.

Can you please update chart to take github PAT as input:
https://github.com/evryfs/helm-charts/blob/master/charts/github-actions-runner-operator/values.yaml#L73

Hi, just wondering if you could please share info as to the purpose of the dependency track ci directory and yamls within it, where are these used please?

Thanks,

Matt

Describe the bug
On running the helm chart, pod is taking a lot of time to download the necessary packages required. Hence service not available on port 80.

Version of Helm and Kubernetes:
helm -
Client: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}

kubectl -
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
dependency track

What happened:
Error in downloading necessary packages.

What you expected to happen:
Packages to be downloaded and service running on port 80.

How to reproduce it (as minimally and precisely as possible):
helm init
helm install ./ --namespace dt --name dt
kubectl logs -f --namespace dt <POD_NAME>

Anything else we need to know:
Attached the log files.
logs-from-dependency-track-in-dt-dependency-track-c9b86b6f-p4tqp.txt

Hello,

I was upgrading the dependency track to the latest version, after the upgrade I noticed that there is two replicas from the frontend, I got back to chart and I saw it really is 2

Would you please explain to me why this is needed ? How does it effect the performance of the UI ?

https://github.com/evryfs/helm-charts/blob/master/charts/dependency-track/values.yaml#L16

Thanks in advance

Is your feature request related to a problem? Please describe.
When deploying the helm chart, there is no possibility to mount additional volumes, e.g. for secret files. We are using ssl inspection in our company network so the container needs to know our company ca certificates.

Describe the solution you'd like
It would be nice if there was a section in the helm chart which supports mouting volumes, secrets or config maps. Imo this should be fairly easy to implement.

Upgrade dt to 4.3.3: https://docs.dependencytrack.org/2021/08/20/v4.3.3/

Is your feature request related to a problem? Please describe.
Upgrade to latest 4.3.x release in order to get new features, specifically the OIDC changes which are favourable, as well as supposedly fixing the infamous postgresql infinite-loop bug.

Also, please upgrade the postgres child chart to latest compatible version.

release notes: https://docs.dependencytrack.org/changelog/

Describe the solution you'd like
Upgrade to latest release: https://docs.dependencytrack.org/2022/05/18/v4.5.0/

Describe alternatives you've considered
N/A

Additional context
N/A

Describe the bug

I am deploying the helm chart in this repo alongside the apiserver and frontend which are packaged as separate K8s deployments and services within this.

When we try to login in via the UI and we receive HTTP 405 Method Not Allowed.

Given that the chart deploys frontend and backend as separate deployments and services, what should we be using as the API_BASE_URL in the frontend so that it can talk to the backend and we don't receive the HTTP error.

Version of Helm and Kubernetes:
Helm v3.5.2
Kubernetes 1.19.0

Which chart:
Dependency Track 4.2.0 / Chart 1.0.4

What happened:

From the Dependency Track documentation and here https://github.com/DependencyTrack/frontend#deployment that something might need to be provided for API_BASE_URL.

What you expected to happen:
We are able to login in via the UI without receiving a HTTP error.

How to reproduce it (as minimally and precisely as possible):

• Install Dependency Track with the chart.
• Go to the URL created for Dependency Track.
• Submit initial startup default credentials and login.

I've got exactly the same problem as issue #7, for some reason this was closed without an answer.

Any ideas?

In my case I'm trying to setup the database connection. So part 2 of this question is how do I include sqljdbc4.jar as documented here https://docs.dependencytrack.org/getting-started/database-support/

Is your feature request related to a problem? Please describe.
We are running multiple ingressclasses, so we need to be able to specify the spec.ingressClassName on the ingress.
the deprecated kubernetes.io/ingress.class annotation no longer works on the latest controllers.

Describe the solution you'd like
To be able to specify ingress.ingressClassName in the helm values.yaml file - this would then generate a spec.ingressClassName entry in the ingress, with the value that was specified in the values.yaml file

Describe alternatives you've considered
Only manually editing the ingress

Additional context
Same problem that was reported and fixed on dependency-track issue

Drop use of token in chart releaser: helm/chart-releaser-action#28

I am attempting to deploy the helm chart to a Kubernetes instance in Azure. After seeing the bitnami postgresql pod crashing, I enabled the bitnami debug mode and the pod outputted this. Would you know what needs to be configured in other for this to be fixed?

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /bitnami/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers ... 400kB
selecting default timezone ... Etc/UTC
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
2023-05-02 15:18:12.269 UTC [98] FATAL: data directory "/bitnami/postgresql/data" has invalid permissions
2023-05-02 15:18:12.269 UTC [98] DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).
child process exited with exit code 1
initdb: removing contents of data directory "/bitnami/postgresql/data"
running bootstrap script ...

Describe the bug
Proper naming should be:

{
  "pools": {
    "A": {
      "servers": [
        // hosts of replicated pool, https://github.com/facebook/mcrouter/wiki/Replicated-pools-setup e.g.:
        "mcrouter-memcached-0.mcrouter-memcached.mcrouter.svc.cluster.local:11211",
        "mcrouter-memcached-1.mcrouter-memcached.mcrouter.svc.cluster.local:11211",
        "mcrouter-memcached-2.mcrouter-memcached.mcrouter.svc.cluster.local:11211",
      ]
    }
  },

but by default service names generated as mcrouter-0.mcrouter.mcrouter.svc.cluster.local:11211 resulting in non-working mcrouter, template missing -memcached twice, for pod and for service names.

Version of Helm and Kubernetes:

helm v3.12.3
kubernetes v1.24.15

**Which chart**:
mcrouter

What happened:
wrong configuration applied by default

What you expected to happen:
default config have proper settings to work

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

dependencies:
  - name: memcached
    version: ~6.6
    repository: https://charts.bitnami.com/bitnami
    condition: mcrouter.memcached.enabled

condition mcrouter.memcached.enabled should be memcached.enabled?

Describe the bug
Installed Dependency-Track using Helm Charts. The Pod is in RUNNING state but the logs state the following error:

13:20:15.349 ERROR [VulnerabilityIndexer] An error occurred while adding a vulnerability to the index
java.nio.file.AccessDeniedException: /data/index
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
	at java.nio.file.Files.createDirectory(Files.java:674)

Version of Helm and Kubernetes:
Helm Version: 3.2.3
K8s Version: 1.18

Which chart:
dependency-track

What happened:

1. Installed Dependency-Track using Helm Charts.
2. Pod is RUNNING
3. SVC is CREATED
4. After exposing the service to an external-IP address, only the title of the website along with a Blank Web-Page is displayed.
5. Upon further debugging the issue and checking the logs of the pod, the following error is getting printed on repetative basis
   13:20:15.349 ERROR [VulnerabilityIndexer] An error occurred while adding a vulnerability to the index java.nio.file.AccessDeniedException: /data/index at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) at java.nio.file.Files.createDirectory(Files.java:674)

What you expected to happen:
Service to be UP and RUNNING and DEPENDENCY-TRACK being AVAILABLE via Exposed Service

How to reproduce it (as minimally and precisely as possible):
Simply install dependency-track using helm charts

Anything else we need to know:
Thats all about it.

After upgrading to the chart having split between api and frontend the frontend has no content on the home/dashboard, all other pages seems correct. Any idea what this could be?

Describe the bug
The Postgresql password is being hard coded in values.yaml, it is not good practice to hardcode default credentials in Helm charts especially when the Postgresql chart contains a random-generate function to create passwords.

postgresql:
  enabled: true
  postgresqlUsername: deptrack
  postgresqlPassword: deptrack
  postgresqlDatabase: deptrack

A clear and concise description of what the bug is.
this is not good practice to use a fixed password, especially when the rando-generate function is already in the chart
Version of Helm and Kubernetes

Helm v3.5.2
Kubernetes 1.19.0

Which chart:
Dependency Track 4.2.0 / Chart 1.0.4

Hi!

We need to add annotations to dependency-track service accounts to allow IAM permisions in GKE, these annotations are required to allow access to CloudSQL databases.

Is your feature request related to a problem? Please describe.
Not having annotations in the SAs would mean we need to add long-live, non-auditable JSON files for authentication

Describe the solution you'd like
Add suppport for annotations on service accounts

Describe alternatives you've considered
Using long-lived, non-auditable JSON files as mounts on sidecars

Currently there is no way to put annotations on pods.

Is your feature request related to a problem? Please describe.
We are trying to configure linkerd on all our pods and require annotations on pods to do so.

Describe the solution you'd like
The Bitnami chart for grafana-operator deployments has:

  template:
    metadata:
      labels: {{- include "common.labels.standard" . | nindent 8 }}
        {{- if .Values.operator.podLabels }}
        {{- include "common.tplvalues.render" (dict "value" .Values.operator.podLabels "context" $) | nindent 8 }}
        {{- end }}
      {{- if .Values.operator.podAnnotations }}
      annotations: {{- include "common.tplvalues.render" (dict "value" .Values.operator.podAnnotations "context" $) | nindent 8 }}
      {{- end }}

Given the use of the Bitnami common library by evryfs I think having the same would be good.

Describe alternatives you've considered
The only other way we've come up with is 'kubectl edit' :(

Describe the bug

When configuring image pull secrets when using private docker repositories for both postgres and dependency track the charts require different format image pull secrets and dependency track only reads them from global

The dependency track chart expects image pull secrets in the values:

global:
  imagePullSecrets:
    - name: regcred

The postgres chart expects image pull secrets in the values:

global:
  imagePullSecrets:
    - regcred

Version of Helm and Kubernetes:

Which chart:

Dependency Track

How to reproduce it (as minimally and precisely as possible):

Using values

global:
  imageRegistry: private-repo/repo
  imagePullSecrets:
    - name: regcred

What happened:

 # Source: dependency-track/charts/dependency-track/templates/backend/deployment.yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -187,6 +251,8 @@
         app.kubernetes.io/managed-by: Helm
         app.kubernetes.io/component: backend
     spec:
+      imagePullSecrets:
+      - name: regcred

 ---
+# Source: dependency-track/charts/postgresql/templates/statefulset.yaml
+apiVersion: apps/v1
+kind: StatefulSet
+    spec:      
+      imagePullSecrets:
+        - name: map[name:regcred]

What you expected to happen:

 # Source: dependency-track/charts/dependency-track/templates/backend/deployment.yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -187,6 +251,8 @@
         app.kubernetes.io/managed-by: Helm
         app.kubernetes.io/component: backend
     spec:
+      imagePullSecrets:
+      - name: regcred

 ---
+# Source: dependency-track/charts/postgresql/templates/statefulset.yaml
+apiVersion: apps/v1
+kind: StatefulSet
+    spec:      
+      imagePullSecrets:
+      - name: regcred

Anything else we need to know:

Rather than using global values for the image pull secrets could you add .Values.imagePullSecrets value to the dependency track chart and default to the global value if it's null