* fix(Resources): add basic Resource MVC * fix(Resources): implement many-to-many tags via through table * fix(Resources): tsvector & migration migration needs work, need to create a custom django migration field to build the GENERATED ALWAYS column. Without it, django will complain about the ts column not exisiting when we try to create an index. * test(Resources): add tests for /resources views * fix(Resources): get basic test cases to pass need to work on tsvector column and filtering by provider columns like alias, name * fix(Resources): provide way to get tags as dict not a list of ResourceTag models * fix(Resources): annotate with return type * fix(Resources): rename search field to not conflict with filters * fix(Resources): filter by provider.id * fix(Resources): remove filter and sort by provider must use provider_id first * fix(Resources): test adding, clearing tags * fix(Scans): filter by provider_id * fix(Resources): remove FIXME comments * fix(Resources): filter and search on tags * fix(Resources): full text search * fix(Resources): full text search to include both resources and tags and get rid of the distinct() query * fix(Resources): document text search a bit more * fix(Resources): remove TODO comments * fix(Resources): move Resource migrations into 0001_initital * fix(Config): revert to match main * fix(Resources): use Django's default query builder for full text search * Apply suggestions from code review Mostly formatting changes Co-authored-by: Víctor Fernández Poyatos <victor@prowler.com> * fix(Resources): just use text search instead of guessing at allowed split characters for each provider * fix(Resources): remove unused tests these cases are covered in parameterized lists * fix(Resources): set a read-only RLS policy * fix(Resources): rename add_tags to be upsert_or_delete_tags * fix(Resources): include primary key on through table django query builder doesn't like tables without primary keys * fix(Resources): default xx_at filters to date instead of date time * docs(Resources): describe what a Resource is in API docs * chore(Resources): rename file to match others --------- Co-authored-by: Víctor Fernández Poyatos <victor@prowler.com>
Prowler SaaS and Prowler Open Source are as dynamic and adaptable as the environment they’re meant to protect. Trusted by the leaders in security.
Learn more at prowler.com
Description
Prowler is an Open Source security tool to perform AWS, Azure, Google Cloud and Kubernetes security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness, and also remediations! We have Prowler CLI (Command Line Interface) that we call Prowler Open Source and a service on top of it that we call Prowler SaaS.
This repository contains the JSON API and Task Runner components for Prowler, which facilitate a complete backend that interacts with the Prowler SDK and is used by the Prowler UI.
Production deployment
Install all dependencies with Poetry
poetry install
poetry shell
Modify environment variables
Under the root path of the project, you can find a file called .env.example. This file shows all the environment variables that the project uses. You can must create a new file called .env and set the values for the variables.
Keep in mind if you export the .env file to use it with local deployment that you will have to do it within the context of the Poetry interpreter, not before. Otherwise, variables will not be loaded properly.
Run migrations
For migrations, you need to force the admin database router. Assuming you have the correct environment variables and Python virtual environment, run:
python manage.py migrate --database admin
Run the Celery worker
cd src/backend
python -m celery -A config.celery worker -l info -E
Run the Django server with Gunicorn
cd src/backend
gunicorn -c backend/guniconf.py backend.wsgi:application
By default, the Gunicorn server will try to use as many workers as your machine can handle. You can manually change that in the
src/backend/backend/guniconf.pyfile.
💻 Development guide
The Prowler API is composed of the following components:
- The JSON API, which is the main component of the API.
- The Celery worker, which is responsible for executing the background tasks that are defined in the JSON API.
- The PostgreSQL database, which is used to store the data.
- The Valkey database, which is used to manage the background tasks.
Note about Valkey
Valkey is an open source (BSD) high performance key/value datastore.
Valkey exposes a Redis 7.2 compliant API. Any service that exposes the Redis API can be used with Prowler API.
Local deployment
This method requires installing a Python virtual environment and keep dependencies updated.
Clone the repository
# HTTPS
git clone https://github.com/prowler-cloud/api.git
# SSH
git clone git@github.com:prowler-cloud/api.git
Start the PostgreSQL database and Valkey
The PostgreSQL database and Valkey are required for the development environment. To make development easier, we have provided a docker-compose file that will start them for you.
docker compose up postgres valkey -d
Install the Python dependencies
You must have Poetry installed
poetry install
poetry shell
Apply migrations
For migrations, you need to force the admin database router. Assuming you have the correct environment variables and Python virtual environment, run:
python manage.py migrate --database admin
Run the Django development server
cd backend
python manage.py migrate --database admin
python manage.py runserver
You can access the server in http://localhost:8000.
All changes in the code will be automatically reloaded in the server.
Run the Celery worker
python -m celery -A config.celery worker -l info -E
The Celery worker does not detect and reload changes in the code, so you need to restart it manually when you make changes.
Docker deployment
This method requires docker and docker compose.
Clone the repository
# HTTPS
git clone https://github.com/prowler-cloud/api.git
# SSH
git clone git@github.com:prowler-cloud/api.git
Build the base image
docker compose --profile dev build
Run the development service
This command will start the Django development server and the Celery worker and also the Valkey and PostgreSQL databases.
docker compose --profile dev up -d
You can access the server in http://localhost:8080.
All changes in the code will be automatically reloaded in the server.
NOTE: notice how the port is different. When developing using docker, the port will be
8080to prevent conflicts.
View the development server logs
For Django
docker logs -f api-api-dev-1
or for the Celery worker:
docker logs -f api-worker-dev-1
Applying migrations
For migrations, you need to force the admin database router. Assuming you have the correct environment variables and Python virtual environment, run:
poetry shell
python manage.py migrate --database admin
Apply fixtures
Fixtures are used to populate the database with initial development data.
poetry shell
# For dev tenants
python manage.py loaddata api/fixtures/dev_tenants.json --database admin
Run tests
Note that the tests will fail if you use the same .env file as the development environment.
For best results, run in a new shell with no environment variables set.
poetry shell
cd src/backend
pytest

