Helm Repo / Helm Chart

[zeug-it]

Current Behavior

There is no public helm repository / helm chart from the project.

Proposed Behavior

It would be great if there would be a public helm repository for DepenencyTrack, There is no easy clean way to deploy the software on a cloud native stack like k8s. There is a helm third party chart, but it is noch maintained / updated. For us this is a showstopper to use this great software in live deployment because, maintainance is manual this way and not possible via renovate bot etc.

Greetings, Martin

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[Jasper-Ben]

:wave: @zeug-it

We are also interested in this, for the same reasons you gave (once dependencytrack is actually usable for our use-case (https://github.com/DependencyTrack/dependency-track/issues/2988)).

Mid-term we could help maintain the helm chart.

[nscuro]

@melba-lopez Do I remember correctly that you and your team are working on this?

[NissesSenap]

There is one created, it just isn't part of this repo. https://github.com/DependencyTrack/dependency-track/issues/210 Sadly, it doesn't seem to have been updated in a long time. But it can probably be looked at for inspiration.

[nscuro]

The MediaMarktSaturn team is maintaining a chart here: https://github.com/MediaMarktSaturn/helm-charts/tree/main/charts/dependency-track

CC @heubeck

[heubeck]

Shall we update the README with a listing of all know chats?

[zeug-it]

In my opinion, this would be great!

[NissesSenap]

Isn't it better to add an official one instead? This company specific tends to be just that, company specific. And it's really easy that it's an individual that cares extra DT that makes sure that it's upgraded and maintained. But if that person gets other things to do, or leaves the company, they tend to not get patched. For example: https://github.com/evryfs/helm-charts/tree/master/charts/dependency-track, haven't been updated for a year. I understand why that happens.

But my point is that DT should manage a helm chart on its own. I'm currently looking at DT for my company, and assuming that we start using it, I'm happy to help out with maintenance of it. But I feel that I'm not the ideal person to do the initial commit since I currently don't know enough on how DT works.

[heubeck]

But my point is that DT should manage a helm chart on its own.

Would also support this, as an own repository best, so that the review/change process is decoupled from the main repository.

[NissesSenap]

Yesterday I learned that project hyades exists, https://github.com/DependencyTrack/hyades/. The new architecture seems to simplify k8s deployments by allot. It might be worth waiting for them to finish that job, and I assume merge to this repo as a v5. And create the helm chart from that version.

We could of course create a helm chart for hayedes now, so that is ready.

[nscuro]

We already have a chart for Hyades (https://github.com/DependencyTrack/hyades/tree/main/helm-charts/hyades, basic usage instructions here), but it doesn't yet accommodate for all the various extension points organizations may need. If anyone here is experienced with Helm, and has a few minutes to spare, we'd love you to have a look and let us know what may need to be added or changed to make it usable for you. :)

Just a hint: There is one StatefulSet in there - the plan is to make this optional (opt-in) such that the service will be deployed as Deployment by default.

[ybelMekk]

A year ago we were looking for the same ting, but can’t sit around and wait, maintaining this: https://github.com/nais/dependencytrack

[mehradn7]

Hi, what is the status of a public Helm Chart tied to Dependency Track?

I've looked into https://github.com/DependencyTrack/hyades/ as mentioned above, but it would be great to have a minimal Helm Chart equivalent to the docker-compose.yml shared in the docs, as one may not need the extra features brought by Hyades.

[nscuro]

I have created https://github.com/DependencyTrack/helm-charts and intend to move the hyades chart, as well as a dependency-track (for the current v4.x line of DT) chart in there over the coming days.

What are people expecting from an "official" chart? Anything you have on your wishlist?

I see https://github.com/evryfs/helm-charts/tree/master/charts/dependency-track is bundling a Postgres instance, is that really necessary? IMO running PostgreSQL in k8s may not be something we should encourage, but that's just an opinion of course.

[melba-lopez]

@melba-lopez Do I remember correctly that you and your team are working on this?

yes! i forgot about this .... after our community meeting i can put more info

[Jasper-Ben]

I see https://github.com/evryfs/helm-charts/tree/master/charts/dependency-track is bundling a Postgres instance, is that really necessary? IMO running PostgreSQL in k8s may not be something we should encourage, but that's just an opinion of course.

Agreed! We switched from this chart to the mediamarkt/Saturn one for exactly this reason

[NissesSenap]

I have created https://github.com/DependencyTrack/helm-charts and intend to move the hyades chart, as well as a dependency-track (for the current v4.x line of DT) chart in there over the coming days.

What are people expecting from an "official" chart? Anything you have on your wishlist?

I see https://github.com/evryfs/helm-charts/tree/master/charts/dependency-track is bundling a Postgres instance, is that really necessary? IMO running PostgreSQL in k8s may not be something we should encourage, but that's just an opinion of course.

Personally, I don't think we should add Postgres to the chart. There are many complex ways of managing Postgres in Kubernetes, and it will be hard for the community to agree on it + it will add lots of work for maintainers. I think it's much better to just say that it's up to you as a developer to have a Postgres ready for usage, how you do that is up to you.

Wishlist

Secret KEY management

I think that we should be opinionated that you need to provide a Kubernetes secret for the DT Secret KEY. By default, the helm chart can generate the needed secret, but you should be able to opt out of this and generate this secret on your own. For me personally, I will generate this secret using terraform and get it in to Kubernetes.

Side-cars

I'm in GCP, so I like to use cloud-sql-proxy. I think it's up to me as a user to set this up, but I need possibility to add a side-cars to the DT deployment/statefullset.

[nscuro]

Looks like it's best to not include Postgres then, thanks for your input!

@NissesSenap By default, the helm chart can generate the needed secret, but you should be able to opt out of this and generate this secret on your own. For me personally, I will generate this secret using terraform and get it in to Kubernetes.

Something like this?

• Option in values.yaml: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/values.yaml#L15-L19
• Optional Secret manifest: https://github.com/DependencyTrack/hyades/blob/main/helm-charts/hyades/templates/secret.yaml
• Resolving of secret name: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/templates/_helpers.tpl#L284-L292
• Usage of secret in API server Deployment: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/templates/api-server/deployment.yaml#L112-L116

@NissesSenap [...] I need possibility to add a side-cars to the DT deployment/statefullset.

Do you have an example of how this should look like in an Helm chart to be user friendly?

[heubeck]

Do you have an example of how this should look like in an Helm chart to be user friendly?

I've seen lots of "include the container yaml here" sidecar options. not that user friendly, but otherwise you'll never finish including more and more options for the sidecar.

[nscuro]

@heubeck Honestly that's a pretty good summary of Helm charts in general 😄

Some charts are so configurable you start to wonder why even bother.

[NissesSenap]

Looks like it's best to not include Postgres then, thanks for your input!

@NissesSenap By default, the helm chart can generate the needed secret, but you should be able to opt out of this and generate this secret on your own. For me personally, I will generate this secret using terraform and get it in to Kubernetes.

Something like this?

• Option in values.yaml: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/values.yaml#L15-L19
• Optional Secret manifest: https://github.com/DependencyTrack/hyades/blob/main/helm-charts/hyades/templates/secret.yaml
• Resolving of secret name: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/templates/_helpers.tpl#L284-L292
• Usage of secret in API server Deployment: https://github.com/DependencyTrack/hyades/blob/07794ac90af5b3a05d44135a231ce63864362b7c/helm-charts/hyades/templates/api-server/deployment.yaml#L112-L116

@NissesSenap [...] I need possibility to add a side-cars to the DT deployment/statefullset.

Do you have an example of how this should look like in an Helm chart to be user friendly?

Yes, exactly like that to manage the secret :)

To be able to add side-cars I would just do something like this:

# deployment.yaml
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
        {{- if .Values.extraContainers }}
          {{- toYaml .Values.extraContainers | nindent 8 }}
        {{- end }}
---
# values.yaml
# extraContainers: []

extraContainers:
  - name: sidecar
    image: sidecar
    imagePullPolicy: IfNotPresent
    ports:
      - name: http
        containerPort: 80
        protocol: TCP

I also think it's a good idea if we can help the community to enforce security best practices. For example, set readOnly filesystems, don't get default serviceAccountToken etc. It's enough to just do this in values.yaml file as default, so they can overwrite it if they want to.

I'm personally also a fan on how the grafana helm charts enables you to add extra objects. https://github.com/grafana/helm-charts/blob/e0df642bec4505b1ea617a88e0f9e4aa2ae52d4c/charts/grafana/templates/extra-manifests.yaml

https://github.com/grafana/helm-charts/blob/e0df642bec4505b1ea617a88e0f9e4aa2ae52d4c/charts/grafana/values.yaml#L1296

This makes it possible to add extra objects without having to have a separate helm chart/kustomize to add things like networkPolicies, your own secrets etc.

[nscuro]

I pushed an initial version of the chart here: https://github.com/DependencyTrack/helm-charts/tree/main/charts/dependency-track, including a basic CI pipeline.

Figured it might be the best to just put something out there and then collaboratively working on it, rather than me bottlenecking the effort. So, please if you have experience, feature requests, ideas, or anything else related to Helm Charts, have a look and create issues / raise PRs as you see fit.

[nscuro]

With the Chart repository now being there, and the dependency-track being added, I'll close this issue as completed. Please direct any further requests to https://github.com/DependencyTrack/helm-charts

[Jasper-Ben]

@nscuro it seems the official chart is not published on https://artifacthub.io yet? Since that is the go-to website for many to discover helm charts it would probably not hurt to include it there?

[nscuro]

@Jasper-Ben Sure, let me look into setting that up!

[nscuro]

Now available at https://artifacthub.io/packages/helm/dependencytrack/dependency-track

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.