prowler-api
This skill guides implementation of Prowler's multi-tenant API architecture, covering row-level security enforcement, role-based access control, provider validation, and async task patterns. Learn the 4-database setup, RLS model constraints, M2M through-model requirements, and critical decorator ordering for tenant-isolated operations.
Prowler API provides patterns for implementing row-level security and tenant isolation in Django REST applications.
AI-generated summary based on this skill's SKILL.md
Install
prowler-cloud/prowler/prowler-api · repository language: Python
git clone https://github.com/prowler-cloud/prowler
cp -r prowler/skills/prowler-api ~/.claude/skills/prowler-apinpx skillfed install prowler-cloud/prowler/prowler-apiFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
What are prowler api row level security rls patterns?
Prowler-api enforces RLS through model constraints, database triggers, and context managers. Each query filters by tenant_id via QuerySet.filter() in views, with M2M relationships using through models to maintain isolation. The @set_tenant decorator captures tenant context from request headers, passing it to Celery tasks and database transactions. RLS patterns include: tenant_id on all models, database-level CHECK constraints, and explicit permission checks in serializers before returning provider data across AWS, Azure, and GCP resources.
How do you implement rls transaction in django with prowler-api?
Prowler-api implements RLS transactions by wrapping database operations in context managers that set tenant_id before query execution. Use django.db.transaction.atomic() combined with a custom TenantContext manager that validates the tenant exists and user has access. Within the transaction, all QuerySets automatically filter by the active tenant. For Celery tasks, the @set_tenant decorator must execute before @shared_task to preserve tenant context across async boundaries. Admin bypass uses a separate read replica database configured in settings.DATABASES with a custom router.
How should prowler provider lifecycle validation handle deletion?
Prowler-api provider lifecycle validation uses a @provider_deletion_handler decorator that triggers cascade cleanup: removing associated scans, audit results, and compliance records before soft-deleting the provider. Validation checks provider_uid format (AWS account ID, Azure subscription, GCP project) against cloud provider APIs. The deletion handler must execute within the tenant context to prevent cross-tenant data leakage. Provider state transitions (active→inactive→deleted) are logged with audit trails, and hard deletion is restricted to admin users accessing the bypass database.
What is the prowler 4-database architecture setup?
Prowler-api uses four databases: primary (write operations, tenant data), read replica (analytics queries), admin bypass (cross-tenant operations, compliance reporting), and audit log store (immutable deletion/access records). The router in settings.DATABASES directs tenant queries to primary/replica based on operation type, while admin endpoints route to the bypass database. Read replicas lag by seconds; critical operations use the primary. UUIDv7 partitioned tables on the primary enable efficient tenant-scoped queries. Each database has separate credentials and network isolation.
How do you use celery @set_tenant decorator with prowler-api tasks?
Prowler-api's @set_tenant decorator must wrap @shared_task and execute first in the decorator stack to capture tenant_id from the request context before the task enters the Celery worker. The decorator extracts tenant_id from task kwargs, validates it exists, and sets it in thread-local storage for the task duration. Example: @set_tenant @shared_task def scan_provider(tenant_id, provider_uid). Without proper ordering, tasks lose tenant context and queries fail RLS filters. Use celery.canvas (chain, group) to compose multi-step scans while preserving tenant isolation across task boundaries.
What does prowler-api require for django rbac permissions and role-based provider visibility?
Prowler-api implements RBAC through role-based provider visibility: users with 'viewer' role see read-only provider data, 'operator' role can trigger scans, 'admin' role manages providers and users. Permissions are checked via get_role() helper that queries the user's role and tenant membership. Provider visibility is filtered in ViewSet.get_queryset() by role: viewers see all tenant providers, operators see assigned providers, admins see all. M2M through models link users to providers with explicit permission grants. Serializers validate role before exposing sensitive fields like credentials or compliance scores.
SKILL.md
rendered from the published skill — quoted content, verbatim
When to Use
Use this skill for Prowler-specific patterns: - Row-Level Security (RLS) / tenant isolation - RBAC permissions and role checks - Provider lifecycle and validation - Celery tasks with tenant context - Multi-database architecture (4-database setup)
For generic DRF patterns (ViewSets, Serializers, Filters, JSON:API), use django-drf skill.
Critical Rules
- ALWAYS use
rls_transaction(tenant_id)when querying outside ViewSet context - ALWAYS use
get_role()before checking permissions (returns FIRST role only) - ALWAYS use
@set_tenantthen@handle_provider_deletiondecorator order - ALWAYS use explicit through models for M2M relationships (required for RLS)
- NEVER access
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 7 files
skills/prowler-api/SKILL.md
skills/prowler-api/assets/celery_patterns.py
skills/prowler-api/assets/security_patterns.py
skills/prowler-api/references/configuration.md
skills/prowler-api/references/file-locations.md
skills/prowler-api/references/modeling-decisions.md
skills/prowler-api/references/production-settings.md