You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current helm chart is relativly hard to use and misses a bunch of features.
The current containers don't scale independently, if I want a new worker I would have to add it to the same deployment as the API.
There is no difference between configuration and secrets, which makes it hard to read.
You can't differentiate between celery worker and API. My understanding of prowler is that it supports workload identity, this should make it possible to only have the celery SA to actually have access to Kubernetes/Cloud APIs. I haven't looked if the API support workload identity to connect to DB. But it's something that we should solve in the long run.
It's hard to manage multiple helm charts, sure you can do sub charts, but why would you in this case?
There is no release for the helm chart that follows the container tag, which makes it hard to get new
features.
The helm chart don't follow security best practices, which is kind of boring for a security related product.
No documentation at all
Solution Proposed
Remove the helm chart and start from scratch, this will of course not be backwards compatible.
Have the API, UI, celery worker, celery broker in the same helm chart in different deployment with different SA and RBAC.
Make it possible to autoScale the celery workers, for example based on CPU
Don't have valkey or postgres be a part of the helm chart (not that the current one does ether)
Document the helm chart
Come with suggestions on how to deploy postgrs and valkey
Create an automated release flow, that releases when the container is built and store the resulting artifact in github OCI.
Potentially create a DJANGO_SECRETS/DJANGO_TOKEN through a Kubernetes job at initial creation. Here I don't know enough about DJANGO on what is needed, but I can't find any documentation about it when it comes to make prowler production ready. Would love some help from the maintainers, all I see that it's hard coded in a .env files, but I would assume you should generate your own.
Describe alternatives you've considered
N/A
Additional context
No response
The text was updated successfully, but these errors were encountered:
I'm happy to create a PR for this, but It will take a number of hours and I won't start unless I get some kind of maintainer blessing because it will take some time to do it, and to be honest it's not very fun work.
Hi @NissesSenap thanks for your comment and suggestions. So far we have that helm chart as an external contribution that may explain some whys in your comment. However we are open to get your contribution and support it (best effort) moving forward. Your help is very valuable and happy to collaborate on this.
Hi @toniblyx , thanks for your quick response.
I have already started on a PR that I hope will solve most of the things I have pointed out.
My main problem is that I don't know enough about the app itself/how django works.
But I will point out my questions in the PR, some can probably be solved easily, while others probably are separate issues.
New feature motivation
The current helm chart is relativly hard to use and misses a bunch of features.
features.
Solution Proposed
Describe alternatives you've considered
N/A
Additional context
No response
The text was updated successfully, but these errors were encountered: