-
Notifications
You must be signed in to change notification settings - Fork 2k
Labels
feature-requestNew feature request for Prowler.New feature request for Prowler.not-plannedIssues that are not in the Prowler roadmap.Issues that are not in the Prowler roadmap.
Description
New feature motivation
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
andreyolv
Metadata
Metadata
Assignees
Labels
feature-requestNew feature request for Prowler.New feature request for Prowler.not-plannedIssues that are not in the Prowler roadmap.Issues that are not in the Prowler roadmap.