mirror of
https://github.com/prowler-cloud/prowler.git
synced 2026-07-24 04:51:51 +00:00
docs: migrate to Mintlify (#8894)
This commit is contained in:
Andoni Alonso
@@ -0,0 +1,115 @@
|
||||
# Prowler Multicloud CIS Benchmarks PowerBI Template
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. Install Microsoft PowerBI Desktop
|
||||
|
||||
This report requires the Microsoft PowerBI Desktop software which can be downloaded for free from Microsoft.
|
||||
2. Run compliance scans in Prowler
|
||||
|
||||
The report uses compliance csv outputs from Prowler. Compliance scans be run using either [Prowler CLI](https://docs.prowler.com/projects/prowler-open-source/en/latest/#prowler-cli) or [Prowler Cloud/App](https://cloud.prowler.com/sign-in)
|
||||
1. Prowler CLI -> Run a Prowler scan using the --compliance option
|
||||
2. Prowler Cloud/App -> Navigate to the compliance section to download csv outputs
|
||||
|
||||
|
||||
|
||||
The template supports the following CIS Benchmarks only:
|
||||
|
||||
| Compliance Framework | Version |
|
||||
| ---------------------------------------------- | ------- |
|
||||
| CIS Amazon Web Services Foundations Benchmark | v4.0.1 |
|
||||
| CIS Google Cloud Platform Foundation Benchmark | v3.0.0 |
|
||||
| CIS Microsoft Azure Foundations Benchmark | v3.0.0 |
|
||||
| CIS Kubernetes Benchmark | v1.10.0 |
|
||||
|
||||
Ensure you run or download the correct benchmark versions.
|
||||
3. Create a local directory to store Prowler csvoutputs
|
||||
|
||||
Once downloaded, place your csv outputs in a directory on your local machine. If you rename the files, they must maintain the provider in the filename.
|
||||
|
||||
To use time-series capabilities such as "compliance percent over time" you'll need scans from multiple dates.
|
||||
4. Download and run the PowerBI template file (.pbit)
|
||||
|
||||
Running the .pbit file will open PowerBI Desktop and prompt you for the full filepath to the local directory
|
||||
5. Enter the full filepath to the directory created in step 3
|
||||
|
||||
Provide the full filepath from the root directory.
|
||||
|
||||
Ensure that the filepath is not wrapped in quotation marks (""). If you use Window's "copy as path" feature, it will automatically include quotation marks.
|
||||
6. Save the report as a PowerBI file (.pbix)
|
||||
|
||||
Once the filepath is entered, the template will automatically ingest and populate the report. You can then save this file as a new PowerBI report. If you'd like to generate another report, simply re-run the template file (.pbit) from step 4.
|
||||
|
||||
## Validation
|
||||
|
||||
After setting up your dashboard, you may want to validate the Prowler csv files were ingested correctly. To do this, navigate to the "Configuration" tab.
|
||||
|
||||
The "loaded CIS Benchmarks" table shows the supported benchmarks and versions. This is defined by the template file and not editable by the user. All benchmarks will be loaded regardless of which providers you provided csv outputs for.
|
||||
|
||||
The "Prowler CSV Folder" shows the path to the local directory you provided.
|
||||
|
||||
The "Loaded Prowler Exports" table shows the ingested csv files from the local directory. It will mark files that are treated as the latest assessment with a green checkmark.
|
||||
|
||||
|
||||
|
||||
## Report Sections
|
||||
|
||||
The PowerBI Report is broken into three main report pages
|
||||
|
||||
| Report Page | Description |
|
||||
| ----------- | ----------------------------------------------------------------------------------- |
|
||||
| Overview | Provides general CIS Benchmark overview across both AWS, Azure, GCP, and Kubernetes |
|
||||
| Benchmark | Provides overview of a single CIS Benchmark |
|
||||
| Requirement | Drill-through page to view details of a single requirement |
|
||||
|
||||
|
||||
### Overview Page
|
||||
|
||||
The overview page is a general CIS Benchmark overview across both AWS, Azure, GCP, and Kubernetes.
|
||||
|
||||
|
||||
|
||||
The page has the following components:
|
||||
|
||||
| Component | Description |
|
||||
| ---------------------------------------- | ------------------------------------------------------------------------ |
|
||||
| CIS Benchmark Overview | Table with benchmark name, Version, and overall compliance percentage |
|
||||
| Provider by Requirement Status | Bar chart showing benchmark requirements by status by provider |
|
||||
| Compliance Percent Heatmap | Heatmap showing compliance percent by benchmark and profile level |
|
||||
| Profile level by Requirement Status | Bar chart showing requirements by status and profile level |
|
||||
| Compliance Percent Over Time by Provider | Line chart showing overall compliance perecentage over time by provider. |
|
||||
|
||||
### Benchmark Page
|
||||
|
||||
The benchmark page provides an overview of a single CIS Benchmark. You can select the benchmark from the dropdown as well as scope down to specific profile levels or regions.
|
||||
|
||||
|
||||
|
||||
The page has the following components:
|
||||
|
||||
| Component | Description |
|
||||
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Compliance Percent Heatmap | Heatmap showing compliance percent by region and profile level |
|
||||
| Benchmark Section by Requirement Status | Bar chart showing benchmark requirements by bennchmark section and status |
|
||||
| Compliance percent Over Time by Region | Line chart showing overall compliance percentage over time by region |
|
||||
| Benchmark Requirements | Table showing requirement section, requirement number, reuqirement title, number of resources tested, status, and number of failing checks |
|
||||
|
||||
### Requirement Page
|
||||
|
||||
The requirement page is a drill-through page to view details of a single requirement. To populate the requirement page right click on a requiement from the "Benchmark Requirements" table on the benchmark page and select "Drill through" -> "Requirement".
|
||||
|
||||
|
||||
|
||||
The requirement page has the following components:
|
||||
|
||||
| Component | Description |
|
||||
| ------------------------------------------ | --------------------------------------------------------------------------------- |
|
||||
| Title | Title of the requirement |
|
||||
| Rationale | Rationale of the requirement |
|
||||
| Remediation | Remedation guidance for the requirement |
|
||||
| Region by Check Status | Bar chart showing Prowler checks by region and status |
|
||||
| Resource Checks for Benchmark Requirements | Table showing Resource ID, Resource Name, Status, Description, and Prowler Checkl |
|
||||
|
||||
## Walkthrough Video
|
||||
[](https://www.youtube.com/watch?v=lfKFkTqBxjU)
|
||||
@@ -0,0 +1,369 @@
|
||||
---
|
||||
title: 'Bulk Provider Provisioning in Prowler'
|
||||
---
|
||||
|
||||
Prowler enables automated provisioning of multiple cloud providers through the Bulk Provider Provisioning tool. This approach streamlines the onboarding process for organizations managing numerous cloud accounts, subscriptions, and projects across AWS, Azure, GCP, Kubernetes, Microsoft 365, and GitHub.
|
||||
|
||||
The tool is available in the Prowler repository at: [util/prowler-bulk-provisioning](https://github.com/prowler-cloud/prowler/tree/master/util/prowler-bulk-provisioning)
|
||||
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
The Bulk Provider Provisioning tool automates the creation of cloud providers in Prowler App or Prowler Cloud by:
|
||||
|
||||
* Reading provider configurations from YAML files
|
||||
* Creating providers with appropriate authentication credentials
|
||||
* Testing connections to verify successful authentication
|
||||
* Processing multiple providers concurrently for efficiency
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Requirements
|
||||
|
||||
* Python 3.7 or higher
|
||||
* Prowler API token (from Prowler Cloud or self-hosted Prowler App)
|
||||
* For self-hosted Prowler App, remember to [point to your API base URL](#custom-api-endpoints)
|
||||
* Authentication credentials for target cloud providers
|
||||
|
||||
### Installation
|
||||
|
||||
Clone the repository and install the required dependencies:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/prowler-cloud/prowler.git
|
||||
cd prowler/util/prowler-bulk-provisioning
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
### Authentication Setup
|
||||
|
||||
Configure your Prowler API token:
|
||||
|
||||
```bash
|
||||
export PROWLER_API_TOKEN="your-prowler-api-token"
|
||||
```
|
||||
|
||||
To obtain an API token programmatically:
|
||||
|
||||
```bash
|
||||
export PROWLER_API_TOKEN=$(curl --location 'https://api.prowler.com/api/v1/tokens' \
|
||||
--header 'Content-Type: application/vnd.api+json' \
|
||||
--header 'Accept: application/vnd.api+json' \
|
||||
--data-raw '{
|
||||
"data": {
|
||||
"type": "tokens",
|
||||
"attributes": {
|
||||
"email": "your@email.com",
|
||||
"password": "your-password"
|
||||
}
|
||||
}
|
||||
}' | jq -r .data.attributes.access)
|
||||
```
|
||||
|
||||
## Configuration File Structure
|
||||
|
||||
Create a YAML file listing your cloud providers and credentials:
|
||||
|
||||
```yaml
|
||||
# providers.yaml
|
||||
- provider: aws
|
||||
uid: "123456789012" # AWS Account ID
|
||||
alias: "production-account"
|
||||
auth_method: role
|
||||
credentials:
|
||||
role_arn: "arn:aws:iam::123456789012:role/ProwlerScanRole"
|
||||
external_id: "prowler-external-id"
|
||||
|
||||
- provider: azure
|
||||
uid: "00000000-1111-2222-3333-444444444444" # Subscription ID
|
||||
alias: "azure-production"
|
||||
auth_method: service_principal
|
||||
credentials:
|
||||
tenant_id: "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
|
||||
client_id: "ffffffff-1111-2222-3333-444444444444"
|
||||
client_secret: "your-client-secret"
|
||||
|
||||
- provider: gcp
|
||||
uid: "my-gcp-project" # Project ID
|
||||
alias: "gcp-production"
|
||||
auth_method: service_account
|
||||
credentials:
|
||||
service_account_key_json_path: "./service-account.json"
|
||||
```
|
||||
|
||||
## Running the Bulk Provisioning Tool
|
||||
|
||||
### Basic Usage
|
||||
|
||||
To provision all providers from your configuration file:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml
|
||||
```
|
||||
|
||||
The tool automatically tests each provider connection after creation (enabled by default).
|
||||
|
||||
### Dry Run Mode
|
||||
|
||||
Test your configuration without making API calls:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml --dry-run
|
||||
```
|
||||
|
||||
### Skip Connection Testing
|
||||
|
||||
To provision providers without testing connections:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml --test-provider false
|
||||
```
|
||||
|
||||
### Test Existing Providers Only
|
||||
|
||||
To verify connections for already provisioned providers:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml --test-provider-only
|
||||
```
|
||||
|
||||
## Provider-Specific Configuration
|
||||
|
||||
### AWS Provider Configuration
|
||||
|
||||
#### Using IAM Role (Recommended)
|
||||
|
||||
```yaml
|
||||
- provider: aws
|
||||
uid: "123456789012"
|
||||
alias: "aws-production"
|
||||
auth_method: role
|
||||
credentials:
|
||||
role_arn: "arn:aws:iam::123456789012:role/ProwlerScanRole"
|
||||
external_id: "optional-external-id"
|
||||
session_name: "prowler-scan-session" # optional
|
||||
duration_seconds: 3600 # optional
|
||||
```
|
||||
|
||||
#### Using Access Keys
|
||||
|
||||
```yaml
|
||||
- provider: aws
|
||||
uid: "123456789012"
|
||||
alias: "aws-development"
|
||||
auth_method: credentials
|
||||
credentials:
|
||||
access_key_id: "AKIA..."
|
||||
secret_access_key: "..."
|
||||
session_token: "..." # optional for temporary credentials
|
||||
```
|
||||
|
||||
### Azure Provider Configuration
|
||||
|
||||
```yaml
|
||||
- provider: azure
|
||||
uid: "subscription-uuid"
|
||||
alias: "azure-production"
|
||||
auth_method: service_principal
|
||||
credentials:
|
||||
tenant_id: "tenant-uuid"
|
||||
client_id: "client-uuid"
|
||||
client_secret: "client-secret"
|
||||
```
|
||||
|
||||
### GCP Provider Configuration
|
||||
|
||||
#### Using Service Account JSON
|
||||
|
||||
```yaml
|
||||
- provider: gcp
|
||||
uid: "project-id"
|
||||
alias: "gcp-production"
|
||||
auth_method: service_account
|
||||
credentials:
|
||||
service_account_key_json_path: "/path/to/key.json"
|
||||
```
|
||||
|
||||
#### Using OAuth2 Credentials
|
||||
|
||||
```yaml
|
||||
- provider: gcp
|
||||
uid: "project-id"
|
||||
alias: "gcp-production"
|
||||
auth_method: oauth2
|
||||
credentials:
|
||||
client_id: "123456789.apps.googleusercontent.com"
|
||||
client_secret: "GOCSPX-xxxx"
|
||||
refresh_token: "1//0exxxxxx"
|
||||
```
|
||||
|
||||
### Kubernetes Provider Configuration
|
||||
|
||||
```yaml
|
||||
- provider: kubernetes
|
||||
uid: "context-name"
|
||||
alias: "eks-production"
|
||||
auth_method: kubeconfig
|
||||
credentials:
|
||||
kubeconfig_path: "~/.kube/config"
|
||||
# OR inline configuration:
|
||||
# kubeconfig_inline: |
|
||||
# apiVersion: v1
|
||||
# clusters: ...
|
||||
```
|
||||
|
||||
### Microsoft 365 Provider Configuration
|
||||
|
||||
```yaml
|
||||
- provider: m365
|
||||
uid: "domain.onmicrosoft.com"
|
||||
alias: "m365-tenant"
|
||||
auth_method: service_principal
|
||||
credentials:
|
||||
tenant_id: "tenant-uuid"
|
||||
client_id: "client-uuid"
|
||||
client_secret: "client-secret"
|
||||
```
|
||||
|
||||
### GitHub Provider Configuration
|
||||
|
||||
#### Using Personal Access Token
|
||||
|
||||
```yaml
|
||||
- provider: github
|
||||
uid: "organization-name"
|
||||
alias: "github-org"
|
||||
auth_method: personal_access_token
|
||||
credentials:
|
||||
token: "ghp_..."
|
||||
```
|
||||
|
||||
#### Using GitHub App
|
||||
|
||||
```yaml
|
||||
- provider: github
|
||||
uid: "organization-name"
|
||||
alias: "github-org"
|
||||
auth_method: github_app
|
||||
credentials:
|
||||
app_id: "123456"
|
||||
private_key_path: "/path/to/private-key.pem"
|
||||
```
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
### Concurrent Processing
|
||||
|
||||
Adjust the number of concurrent provider creations:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml --concurrency 10
|
||||
```
|
||||
|
||||
### Custom API Endpoints
|
||||
|
||||
For self-hosted Prowler App installations:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml \
|
||||
--base-url http://localhost:8080/api/v1
|
||||
```
|
||||
|
||||
### Timeout Configuration
|
||||
|
||||
Set custom timeout for API requests:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml --timeout 120
|
||||
```
|
||||
|
||||
## Bulk Provider Management
|
||||
|
||||
### Deleting Multiple Providers
|
||||
|
||||
To remove all providers from your Prowler account:
|
||||
|
||||
```bash
|
||||
python nuke_providers.py --confirm
|
||||
```
|
||||
|
||||
Filter deletions by provider type:
|
||||
|
||||
```bash
|
||||
python nuke_providers.py --confirm --filter-provider aws
|
||||
```
|
||||
|
||||
Filter deletions by alias pattern:
|
||||
|
||||
```bash
|
||||
python nuke_providers.py --confirm --filter-alias "test-*"
|
||||
```
|
||||
|
||||
## Configuration File Format
|
||||
|
||||
The tool uses YAML format for provider configuration files. Each provider entry requires:
|
||||
|
||||
* `provider`: The cloud provider type (aws, azure, gcp, kubernetes, m365, github)
|
||||
* `uid`: Unique identifier for the provider (account ID, subscription ID, project ID, etc.)
|
||||
* `alias`: A friendly name for the provider
|
||||
* `auth_method`: Authentication method to use
|
||||
* `credentials`: Authentication credentials specific to the provider and method
|
||||
|
||||
Example YAML structure:
|
||||
|
||||
```yaml
|
||||
- provider: aws
|
||||
uid: "123456789012"
|
||||
alias: "production"
|
||||
auth_method: role
|
||||
credentials:
|
||||
role_arn: "arn:aws:iam::123456789012:role/ProwlerScan"
|
||||
```
|
||||
|
||||
## Example Output
|
||||
|
||||
Successful provider provisioning:
|
||||
|
||||
```
|
||||
[1] ✅ Created provider (id=db9a8985-f9ec-4dd8-b5a0-e05ab3880bed)
|
||||
[1] ✅ Created secret (id=466f76c6-5878-4602-a4bc-13f9522c1fd2)
|
||||
[1] ✅ Connection test: Connected
|
||||
|
||||
[2] ✅ Created provider (id=7a99f789-0cf5-4329-8279-2d443a962676)
|
||||
[2] ✅ Created secret (id=c5702180-f7c4-40fd-be0e-f6433479b126)
|
||||
[2] ⚠️ Connection test: Not connected
|
||||
|
||||
Done. Success: 2 Failures: 0
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Invalid API Token
|
||||
|
||||
```
|
||||
Error: 401 Unauthorized
|
||||
Solution: Verify your PROWLER_API_TOKEN or --token parameter
|
||||
```
|
||||
|
||||
### Network Timeouts
|
||||
|
||||
```
|
||||
Error: Connection timeout
|
||||
Solution: Increase timeout with --timeout 120
|
||||
```
|
||||
|
||||
### Provider Already Exists
|
||||
|
||||
```
|
||||
Error: Provider with this UID already exists
|
||||
Solution: Use different UID or delete existing provider first
|
||||
```
|
||||
|
||||
### Authentication Failures
|
||||
|
||||
```
|
||||
Connection test: Not connected
|
||||
Solution: Verify credentials and IAM permissions
|
||||
```
|
||||
@@ -0,0 +1,198 @@
|
||||
---
|
||||
title: "Jira Integration"
|
||||
---
|
||||
|
||||
Prowler App enables automatic export of security findings to Jira, providing seamless integration with Atlassian's work item tracking and project management platform. This comprehensive guide demonstrates how to configure and manage Jira integrations to streamline security incident management and enhance team collaboration across security workflows.
|
||||
|
||||
Integrating Prowler App with Jira provides:
|
||||
|
||||
* **Streamlined management:** Convert security findings directly into actionable Jira work items
|
||||
* **Enhanced team collaboration:** Leverage existing project management workflows for security remediation
|
||||
* **Automated ticket creation:** Reduce manual effort in tracking and assigning security work items
|
||||
|
||||
## How It Works
|
||||
|
||||
When enabled and configured:
|
||||
|
||||
1. Security findings can be manually sent to Jira from the Findings table.
|
||||
2. Each finding creates a Jira work item with all the check's metadata, including guidance on how to remediate it.
|
||||
|
||||
## Configuration
|
||||
|
||||
To configure Jira integration in Prowler App:
|
||||
|
||||
1. Navigate to **Integrations** in the Prowler App interface
|
||||
2. Locate the **Jira** card and click **Manage**, then select **Add integration**
|
||||
|
||||
|
||||
|
||||
3. Complete the integration settings:
|
||||
* **Jira domain:** Enter the Jira domain (e.g., from `https://your-domain.atlassian.net` -> `your-domain`)
|
||||
* **Email:** Your Jira account email
|
||||
* **API Token:** API token with the following scopes: `read:jira-user`, `read:jira-work`, `write:jira-work`
|
||||
|
||||
|
||||
<Note>
|
||||
**Generate Jira API Token**
|
||||
|
||||
To generate a Jira API token, visit: https://id.atlassian.com/manage-profile/security/api-tokens
|
||||
|
||||
</Note>
|
||||
|
||||
Once configured successfully, the integration is ready to send findings to Jira.
|
||||
|
||||
## Sending Findings to Jira
|
||||
|
||||
### Manual Export
|
||||
|
||||
To manually send individual findings to Jira:
|
||||
|
||||
1. Navigate to the **Findings** section in Prowler App
|
||||
2. Select one finding you want to export
|
||||
3. Click the action button on the table row and select **Send to Jira**
|
||||
4. Select the Jira integration and project
|
||||
5. Click **Send to Jira**
|
||||
|
||||
|
||||
|
||||
## Integration Status
|
||||
|
||||
Monitor and manage your Jira integrations through the management interface:
|
||||
|
||||
1. Review configured integrations in the integrations dashboard
|
||||
2. Each integration displays:
|
||||
|
||||
- **Connection Status:** Connected or Disconnected indicator
|
||||
- **Instance Information:** Jira domain and last checked timestamp
|
||||
|
||||
### Actions
|
||||
|
||||
Each Jira integration provides management actions through dedicated buttons:
|
||||
|
||||
| Button | Purpose | Available Actions | Notes |
|
||||
|--------|---------|------------------|-------|
|
||||
| **Test** | Verify integration connectivity | • Test Jira API access<br/>• Validate credentials<br/>• Check project permissions<br/>• Verify work item creation capability | Results displayed in notification message |
|
||||
| **Credentials** | Update authentication settings | • Change API token<br/>• Update email<br/>• Update Jira domain | Click "Update Credentials" to save changes |
|
||||
| **Enable/Disable** | Toggle integration status | • Enable or disable integration<br/>| Status change takes effect immediately |
|
||||
| **Delete** | Remove integration permanently | • Permanently delete integration<br/>• Remove all configuration data | ⚠️ **Cannot be undone** - confirm before deleting |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Connection test fails
|
||||
|
||||
- Verify Jira instance domain is correct and accessible
|
||||
- Confirm API token or credentials are valid
|
||||
- Ensure API access is enabled in Jira settings and the needed scopes are granted
|
||||
|
||||
### Check task status (API)
|
||||
|
||||
If the Jira issue does not appear in your Jira project, follow these steps to verify the export task status via the API.
|
||||
|
||||
<Note>
|
||||
Replace `http://localhost:8080` with the base URL where your Prowler API is accessible (for example, `https://api.yourdomain.com`).
|
||||
|
||||
</Note>
|
||||
|
||||
1) Get an access token (replace email and password):
|
||||
|
||||
```
|
||||
curl --location 'http://localhost:8080/api/v1/tokens' \
|
||||
--header 'Content-Type: application/vnd.api+json' \
|
||||
--header 'Accept: application/vnd.api+json' \
|
||||
--data-raw '{
|
||||
"data": {
|
||||
"type": "tokens",
|
||||
"attributes": {
|
||||
"email": "YOUR_USER_EMAIL",
|
||||
"password": "YOUR_USER_PASSWORD"
|
||||
}
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
2) List tasks filtered by the Jira task (`integration-jira`) using the access token:
|
||||
|
||||
```
|
||||
curl --location --globoff 'http://localhost:8080/api/v1/tasks?filter[name]=integration-jira' \
|
||||
--header 'Accept: application/vnd.api+json' \
|
||||
--header 'Authorization: Bearer ACCESS_TOKEN' | jq
|
||||
```
|
||||
|
||||
<Note>
|
||||
If you don't have `jq` installed, run the command without `| jq`.
|
||||
|
||||
</Note>
|
||||
|
||||
3) Share the output so we can help. A typical result will look like:
|
||||
|
||||
```
|
||||
{
|
||||
"links": {
|
||||
"first": "https://api.dev.prowler.com/api/v1/tasks?page%5Bnumber%5D=1",
|
||||
"last": "https://api.dev.prowler.com/api/v1/tasks?page%5Bnumber%5D=122",
|
||||
"next": "https://api.dev.prowler.com/api/v1/tasks?page%5Bnumber%5D=2",
|
||||
"prev": null
|
||||
},
|
||||
"data": [
|
||||
{
|
||||
"type": "tasks",
|
||||
"id": "9a79ab21-39ae-4161-9f6e-2844eb0da0fb",
|
||||
"attributes": {
|
||||
"inserted_at": "2025-09-09T08:11:38.643620Z",
|
||||
"completed_at": "2025-09-09T08:11:41.264285Z",
|
||||
"name": "integration-jira",
|
||||
"state": "completed",
|
||||
"result": {
|
||||
"created_count": 0,
|
||||
"failed_count": 1
|
||||
},
|
||||
"task_args": {
|
||||
"integration_id": "a476c2c0-0a00-4720-bfb9-286e9eb5c7bd",
|
||||
"project_key": "PRWLR",
|
||||
"issue_type": "Task",
|
||||
"finding_ids": [
|
||||
"01992d53-3af7-7759-be48-68fc405391e6"
|
||||
]
|
||||
},
|
||||
"metadata": {}
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "tasks",
|
||||
"id": "5f525135-9d37-4b01-9ac8-afeaf8793eac",
|
||||
"attributes": {
|
||||
"inserted_at": "2025-09-09T08:07:22.184164Z",
|
||||
"completed_at": "2025-09-09T08:07:24.909185Z",
|
||||
"name": "integration-jira",
|
||||
"state": "completed",
|
||||
"result": {
|
||||
"created_count": 1,
|
||||
"failed_count": 0
|
||||
},
|
||||
"task_args": {
|
||||
"integration_id": "a476c2c0-0a00-4720-bfb9-286e9eb5c7bd",
|
||||
"project_key": "JIRA",
|
||||
"issue_type": "Task",
|
||||
"finding_ids": [
|
||||
"0198f018-8b7b-7154-a509-1a2b1ffba02d"
|
||||
]
|
||||
},
|
||||
"metadata": {}
|
||||
}
|
||||
}
|
||||
],
|
||||
"meta": {
|
||||
"pagination": {
|
||||
"page": 1,
|
||||
"pages": 122,
|
||||
"count": 1214
|
||||
},
|
||||
"version": "v1"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
How to read it:
|
||||
|
||||
- "created_count": number of Jira issues successfully created.
|
||||
- "failed_count": number of Jira issues that could not be created. If `failed_count > 0` or the issue does not appear in Jira, please contact us so we can assist while detailed logs are not available through the UI.
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
title: 'Prowler Lighthouse AI'
|
||||
---
|
||||
|
||||
Prowler Lighthouse AI is a Cloud Security Analyst chatbot that helps you understand, prioritize, and remediate security findings in your cloud environments. It's designed to provide security expertise for teams without dedicated resources, acting as your 24/7 virtual cloud security analyst.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-intro.png" alt="Prowler Lighthouse" />
|
||||
|
||||
## How It Works
|
||||
|
||||
Prowler Lighthouse AI uses OpenAI's language models and integrates with your Prowler security findings data.
|
||||
|
||||
Here's what's happening behind the scenes:
|
||||
|
||||
- The system uses a multi-agent architecture built with [LanggraphJS](https://github.com/langchain-ai/langgraphjs) for LLM logic and [Vercel AI SDK UI](https://sdk.vercel.ai/docs/ai-sdk-ui/overview) for frontend chatbot.
|
||||
- It uses a ["supervisor" architecture](https://langchain-ai.lang.chat/langgraphjs/tutorials/multi_agent/agent_supervisor/) that interacts with different agents for specialized tasks. For example, `findings_agent` can analyze detected security findings, while `overview_agent` provides a summary of connected cloud accounts.
|
||||
- The system connects to OpenAI models to understand, fetch the right data, and respond to the user's query.
|
||||
<Note>
|
||||
Lighthouse AI is tested against `gpt-4o` and `gpt-4o-mini` OpenAI models.
|
||||
</Note>
|
||||
- The supervisor agent is the main contact point. It is what users interact with directly from the chat interface. It coordinates with other agents to answer users' questions comprehensively.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-architecture.png" alt="Lighthouse AI Architecture" />
|
||||
|
||||
<Note>
|
||||
All agents can only read relevant security data. They cannot modify your data or access sensitive information like configured secrets or tenant details.
|
||||
|
||||
</Note>
|
||||
## Set up
|
||||
|
||||
Getting started with Prowler Lighthouse AI is easy:
|
||||
|
||||
1. Go to the configuration page in your Prowler dashboard.
|
||||
2. Enter your OpenAI API key.
|
||||
3. Select your preferred model. The recommended one for best results is `gpt-4o`.
|
||||
4. (Optional) Add business context to improve response quality and prioritization.
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-config.png" alt="Lighthouse AI Configuration" />
|
||||
|
||||
### Adding Business Context
|
||||
|
||||
The optional business context field lets you provide additional information to help Lighthouse AI understand your environment and priorities, including:
|
||||
|
||||
- Your organization's cloud security goals
|
||||
- Information about account owners or responsible teams
|
||||
- Compliance requirements for your organization
|
||||
- Current security initiatives or focus areas
|
||||
|
||||
Better context leads to more relevant responses and prioritization that aligns with your needs.
|
||||
|
||||
## Capabilities
|
||||
|
||||
Prowler Lighthouse AI is designed to be your AI security team member, with capabilities including:
|
||||
|
||||
### Natural Language Querying
|
||||
|
||||
Ask questions in plain English about your security findings. Examples:
|
||||
|
||||
- "What are my highest risk findings?"
|
||||
- "Show me all S3 buckets with public access."
|
||||
- "What security issues were found in my production accounts?"
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-feature1.png" alt="Natural language querying" />
|
||||
|
||||
### Detailed Remediation Guidance
|
||||
|
||||
Get tailored step-by-step instructions for fixing security issues:
|
||||
|
||||
- Clear explanations of the problem and its impact
|
||||
- Commands or console steps to implement fixes
|
||||
- Alternative approaches with different solutions
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-feature2.png" alt="Detailed Remediation" />
|
||||
|
||||
### Enhanced Context and Analysis
|
||||
|
||||
Lighthouse AI can provide additional context to help you understand the findings:
|
||||
|
||||
- Explain security concepts related to findings in simple terms
|
||||
- Provide risk assessments based on your environment and context
|
||||
- Connect related findings to show broader security patterns
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-config.png" alt="Business Context" />
|
||||
|
||||
<img src="/images/prowler-app/lighthouse-feature3.png" alt="Contextual Responses" />
|
||||
|
||||
## Important Notes
|
||||
|
||||
Prowler Lighthouse AI is powerful, but there are limitations:
|
||||
|
||||
- **Continuous improvement**: Please report any issues, as the feature may make mistakes or encounter errors, despite extensive testing.
|
||||
- **Access limitations**: Lighthouse AI can only access data the logged-in user can view. If you can't see certain information, Lighthouse AI can't see it either.
|
||||
- **NextJS session dependence**: If your Prowler application session expires or logs out, Lighthouse AI will error out. Refresh and log back in to continue.
|
||||
- **Response quality**: The response quality depends on the selected OpenAI model. For best results, use gpt-4o.
|
||||
|
||||
### Getting Help
|
||||
|
||||
If you encounter issues with Prowler Lighthouse AI or have suggestions for improvements, please [reach out through our Slack channel](https://goto.prowler.com/slack).
|
||||
|
||||
### What Data Is Shared to OpenAI?
|
||||
|
||||
The following API endpoints are accessible to Prowler Lighthouse AI. Data from the following API endpoints could be shared with OpenAI depending on the scope of user's query:
|
||||
|
||||
#### Accessible API Endpoints
|
||||
|
||||
**User Management:**
|
||||
|
||||
- List all users - `/api/v1/users`
|
||||
- Retrieve the current user's information - `/api/v1/users/me`
|
||||
|
||||
**Provider Management:**
|
||||
|
||||
- List all providers - `/api/v1/providers`
|
||||
- Retrieve data from a provider - `/api/v1/providers/{id}`
|
||||
|
||||
**Scan Management:**
|
||||
|
||||
- List all scans - `/api/v1/scans`
|
||||
- Retrieve data from a specific scan - `/api/v1/scans/{id}`
|
||||
|
||||
**Resource Management:**
|
||||
|
||||
- List all resources - `/api/v1/resources`
|
||||
- Retrieve data for a resource - `/api/v1/resources/{id}`
|
||||
|
||||
**Findings Management:**
|
||||
|
||||
- List all findings - `/api/v1/findings`
|
||||
- Retrieve data from a specific finding - `/api/v1/findings/{id}`
|
||||
- Retrieve metadata values from findings - `/api/v1/findings/metadata`
|
||||
|
||||
**Overview Data:**
|
||||
|
||||
- Get aggregated findings data - `/api/v1/overviews/findings`
|
||||
- Get findings data by severity - `/api/v1/overviews/findings_severity`
|
||||
- Get aggregated provider data - `/api/v1/overviews/providers`
|
||||
- Get findings data by service - `/api/v1/overviews/services`
|
||||
|
||||
**Compliance Management:**
|
||||
|
||||
- List compliance overviews for a scan - `/api/v1/compliance-overviews`
|
||||
- Retrieve data from a specific compliance overview - `/api/v1/compliance-overviews/{id}`
|
||||
|
||||
#### Excluded API Endpoints
|
||||
|
||||
Not all Prowler API endpoints are integrated with Lighthouse AI. They are intentionally excluded for the following reasons:
|
||||
|
||||
- OpenAI/other LLM providers shouldn't have access to sensitive data (like fetching provider secrets and other sensitive config)
|
||||
- Users queries don't need responses from those API endpoints (ex: tasks, tenant details, downloading zip file, etc.)
|
||||
|
||||
**Excluded Endpoints:**
|
||||
|
||||
**User Management:**
|
||||
|
||||
- List specific users information - `/api/v1/users/{id}`
|
||||
- List user memberships - `/api/v1/users/{user_pk}/memberships`
|
||||
- Retrieve membership data from the user - `/api/v1/users/{user_pk}/memberships/{id}`
|
||||
|
||||
**Tenant Management:**
|
||||
|
||||
- List all tenants - `/api/v1/tenants`
|
||||
- Retrieve data from a tenant - `/api/v1/tenants/{id}`
|
||||
- List tenant memberships - `/api/v1/tenants/{tenant_pk}/memberships`
|
||||
- List all invitations - `/api/v1/tenants/invitations`
|
||||
- Retrieve data from tenant invitation - `/api/v1/tenants/invitations/{id}`
|
||||
|
||||
**Security and Configuration:**
|
||||
|
||||
- List all secrets - `/api/v1/providers/secrets`
|
||||
- Retrieve data from a secret - `/api/v1/providers/secrets/{id}`
|
||||
- List all provider groups - `/api/v1/provider-groups`
|
||||
- Retrieve data from a provider group - `/api/v1/provider-groups/{id}`
|
||||
|
||||
**Reports and Tasks:**
|
||||
|
||||
- Download zip report - `/api/v1/scans/{v1}/report`
|
||||
- List all tasks - `/api/v1/tasks`
|
||||
- Retrieve data from a specific task - `/api/v1/tasks/{id}`
|
||||
|
||||
**Lighthouse AI Configuration:**
|
||||
|
||||
- List OpenAI configuration - `/api/v1/lighthouse-config`
|
||||
- Retrieve OpenAI key and configuration - `/api/v1/lighthouse-config/{id}`
|
||||
|
||||
<Note>
|
||||
Agents only have access to hit GET endpoints. They don't have access to other HTTP methods.
|
||||
|
||||
</Note>
|
||||
## FAQs
|
||||
|
||||
**1. Why only OpenAI models?**
|
||||
|
||||
During feature development, we evaluated other LLM models.
|
||||
|
||||
- **Claude AI** - Claude models have [tier-based ratelimits](https://docs.anthropic.com/en/api/rate-limits#requirements-to-advance-tier). For Lighthouse AI to answer slightly complex questions, there are a handful of API calls to the LLM provider within few seconds. With Claude's tiering system, users must purchase $400 credits or convert their subscription to monthly invoicing after talking to their sales team. This pricing may not suit all Prowler users.
|
||||
- **Gemini Models** - Gemini lacks a solid tool calling feature like OpenAI. It calls functions recursively until exceeding limits. Gemini-2.5-Pro-Experimental is better than previous models regarding tool calling and responding, but it's still experimental.
|
||||
- **Deepseek V3** - Doesn't support system prompt messages.
|
||||
|
||||
**2. Why a multi-agent supervisor model?**
|
||||
|
||||
Context windows are limited. While demo data fits inside the context window, querying real-world data often exceeds it. A multi-agent architecture is used so different agents fetch different sizes of data and respond with the minimum required data to the supervisor. This spreads the context window usage across agents.
|
||||
|
||||
**3. Is my security data shared with OpenAI?**
|
||||
|
||||
Minimal data is shared to generate useful responses. Agents can access security findings and remediation details when needed. Provider secrets are protected by design and cannot be read. The OpenAI key configured with Lighthouse AI is only accessible to our NextJS server and is never sent to LLMs. Resource metadata (names, tags, account/project IDs, etc) may be shared with OpenAI based on your query requirements.
|
||||
|
||||
**4. Can the Lighthouse AI change my cloud environment?**
|
||||
|
||||
No. The agent doesn't have the tools to make the changes, even if the configured cloud provider API keys contain permissions to modify resources.
|
||||
@@ -0,0 +1,421 @@
|
||||
---
|
||||
title: 'Mute Findings (Mutelist)'
|
||||
---
|
||||
|
||||
Prowler App allows users to mute specific findings to focus on the most critical security issues. This comprehensive guide demonstrates how to effectively use the Mutelist feature to manage and prioritize security findings.
|
||||
|
||||
## What Is the Mutelist Feature?
|
||||
|
||||
The Mutelist feature enables users to:
|
||||
|
||||
- **Suppress specific findings** from appearing in future scans
|
||||
- **Focus on critical issues** by hiding resolved or accepted risks
|
||||
- **Maintain audit trails** of muted findings for compliance purposes
|
||||
- **Streamline security workflows** by reducing noise from non-critical findings
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before muting findings, ensure:
|
||||
|
||||
- Valid access to Prowler App with appropriate permissions
|
||||
- A provider added to the Prowler App
|
||||
- Understanding of the security implications of muting specific findings
|
||||
|
||||
<Warning>
|
||||
Muting findings does not resolve underlying security issues. Review each finding carefully before muting to ensure it represents an acceptable risk or has been properly addressed.
|
||||
|
||||
</Warning>
|
||||
## Step 1: Add a provider
|
||||
|
||||
To configure Mutelist:
|
||||
|
||||
1. Log into Prowler App
|
||||
2. Navigate to the providers page
|
||||
|
||||
3. Add a provider, then "Configure Muted Findings" button will be enabled in providers page and scans page
|
||||
|
||||
|
||||
|
||||
|
||||
## Step 2: Configure Mutelist
|
||||
|
||||
1. Open the modal by clicking "Configure Muted Findings" button
|
||||
|
||||
1. Provide a valid Mutelist in `YAML` format. More details about Mutelist [here](/user-guide/cli/tutorials/mutelist)
|
||||
|
||||
If the YAML configuration is invalid, an error message will be displayed
|
||||
|
||||
|
||||
|
||||
## Step 3: Review the Mutelist
|
||||
|
||||
1. Once added, the configuration can be removed or updated
|
||||
|
||||
|
||||
## Step 4: Check muted findings in the scan results
|
||||
|
||||
1. Run a new scan
|
||||
2. Check the muted findings in the scan results
|
||||
|
||||
|
||||
<Note>
|
||||
The Mutelist configuration takes effect on the next scans.
|
||||
|
||||
</Note>
|
||||
## Mutelist Ready To Use Examples
|
||||
|
||||
Below are examples for different cloud providers supported by Prowler App. Check how the mutelist works [here](https://docs.prowler.com/projects/prowler-open-source/en/latest/tutorials/mutelist/#how-the-mutelist-works).
|
||||
|
||||
### AWS Provider
|
||||
|
||||
#### Basic AWS Mutelist
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"123456789012":
|
||||
Checks:
|
||||
"iam_user_hardware_mfa_enabled":
|
||||
Regions:
|
||||
- "us-east-1"
|
||||
Resources:
|
||||
- "user-1"
|
||||
- "user-2"
|
||||
Description: "Mute MFA findings for specific users in us-east-1"
|
||||
"s3_bucket_public_access":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "public-website-bucket"
|
||||
Description: "Mute public access findings for website bucket"
|
||||
```
|
||||
|
||||
#### AWS Service-Wide Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"ec2_*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Description: "Mute all EC2-related findings across all accounts and regions"
|
||||
```
|
||||
|
||||
#### AWS Tag-Based Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Tags:
|
||||
- "environment=dev"
|
||||
- "project=test"
|
||||
Description: "Mute all findings for resources tagged with environment=dev or project=test"
|
||||
```
|
||||
|
||||
### Azure Provider
|
||||
|
||||
<Note>
|
||||
For Azure provider, the Account ID is the Subscription Name and the Region is the Location.
|
||||
|
||||
</Note>
|
||||
#### Basic Azure Mutelist
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"MySubscription":
|
||||
Checks:
|
||||
"storage_blob_public_access_level_is_disabled":
|
||||
Regions:
|
||||
- "East US"
|
||||
- "West US"
|
||||
Resources:
|
||||
- "publicstorageblob"
|
||||
Description: "Mute public access findings for specific blob storage resource"
|
||||
"app_function_vnet_integration_enabled":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "app-vnet-peering-*"
|
||||
Description: "Mute App Function Vnet findings related with the reources pattern"
|
||||
```
|
||||
|
||||
#### Azure Resource Group Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "rg-dev-*"
|
||||
- "rg-test-*"
|
||||
Tags:
|
||||
- "environment=development"
|
||||
Description: "Mute all findings for development resource groups"
|
||||
```
|
||||
|
||||
### GCP Provider
|
||||
|
||||
<Note>
|
||||
For GCP provider, the Account ID is the Project ID and the Region is the Zone.
|
||||
|
||||
</Note>
|
||||
#### Basic GCP Mutelist
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"my-gcp-project":
|
||||
Checks:
|
||||
"cloudstorage_bucket_public_access":
|
||||
Regions:
|
||||
- "us-central1"
|
||||
- "us-east1"
|
||||
Resources:
|
||||
- "public-bucket-*"
|
||||
Description: "Mute public access findings for specific bucket pattern"
|
||||
"compute_instance_public_ip":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "public-instance"
|
||||
Description: "Mute public access findings for specific compute instance"
|
||||
```
|
||||
|
||||
#### GCP Project-Wide Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Tags:
|
||||
- "environment=staging"
|
||||
Description: "Mute all GCP findings for staging environment"
|
||||
```
|
||||
### Kubernetes Provider
|
||||
|
||||
<Note>
|
||||
For Kubernetes provider, the Account ID is the Cluster Name and the Region is the Namespace.
|
||||
|
||||
</Note>
|
||||
#### Basic Kubernetes Mutelist
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"my-cluster":
|
||||
Checks:
|
||||
"etcd_client_cert_auth":
|
||||
Regions:
|
||||
- "default"
|
||||
- "kube-system"
|
||||
Resources:
|
||||
- "system-pod-*"
|
||||
Description: "Mute etcd cert authorization findings for the matching resources"
|
||||
"kubelet_tls_cert_and_key":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Description: "Mute kubelet tls findings across all namespaces"
|
||||
```
|
||||
|
||||
#### Kubernetes Namespace Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "monitoring"
|
||||
- "logging"
|
||||
Resources:
|
||||
- "*"
|
||||
Description: "Mute all findings for monitoring and logging namespaces"
|
||||
```
|
||||
|
||||
### Microsoft 365 Provider
|
||||
|
||||
#### Basic Microsoft 365 Mutelist
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"my-tenant.onmicrosoft.com":
|
||||
Checks:
|
||||
"entra_admin_portals_access_restriction":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "test-user"
|
||||
Description: "Mute findings related with administrative roles access for test-user"
|
||||
"sharepoint_external_sharing_managed":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "public-site-*"
|
||||
Description: "Mute external sharing findings for public sites"
|
||||
```
|
||||
|
||||
#### Microsoft 365 Tenant-Wide Muting
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Tags:
|
||||
- "department=IT"
|
||||
Description: "Mute all M365 findings for IT department resources"
|
||||
```
|
||||
|
||||
### Multi-Cloud Mutelist
|
||||
|
||||
You can combine multiple providers in a single mutelist configuration:
|
||||
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
# AWS Account
|
||||
"123456789012":
|
||||
Checks:
|
||||
"s3_bucket_public_access":
|
||||
Regions:
|
||||
- "us-east-1"
|
||||
Resources:
|
||||
- "public-website"
|
||||
Description: "Mute public access findings for AWS website bucket"
|
||||
|
||||
# Azure Subscription
|
||||
"MyAzureSubscription":
|
||||
Checks:
|
||||
"storage_blob_public_access_level_is_disabled":
|
||||
Regions:
|
||||
- "East US"
|
||||
Resources:
|
||||
- "public-storage"
|
||||
Description: "Mute public access findings for Azure storage account"
|
||||
|
||||
# GCP Project
|
||||
"my-gcp-project":
|
||||
Checks:
|
||||
"cloudstorage_bucket_public_access":
|
||||
Regions:
|
||||
- "us-central1"
|
||||
Resources:
|
||||
- "public-bucket"
|
||||
Description: "Mute public access findings for GCP storage bucket"
|
||||
|
||||
# Kubernetes Cluster
|
||||
"my-k8s-cluster":
|
||||
Checks:
|
||||
"kubelet_tls_cert_and_key":
|
||||
Regions:
|
||||
- "default"
|
||||
Resources:
|
||||
- "kubelet-test"
|
||||
Description: "Mute kubelet tls findings related with kubelet-test"
|
||||
|
||||
# Microsoft 365 Tenant
|
||||
"my-tenant.onmicrosoft.com":
|
||||
Checks:
|
||||
"sharepoint_external_sharing_managed":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "public-site"
|
||||
Description: "Mute external sharing findings for public SharePoint site"
|
||||
```
|
||||
|
||||
### Advanced Mutelist Features
|
||||
|
||||
#### Using Regular Expressions
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- ".*-test-.*" # Matches any resource containing "-test-"
|
||||
- "dev-.*" # Matches resources starting with "dev-"
|
||||
- ".*-prod$" # Matches resources ending with "-prod"
|
||||
Description: "Mute findings for test and development resources using regex"
|
||||
```
|
||||
|
||||
#### Using Exceptions
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Exceptions:
|
||||
Accounts:
|
||||
- "987654321098"
|
||||
Regions:
|
||||
- "us-west-2"
|
||||
Resources:
|
||||
- "critical-resource"
|
||||
Tags:
|
||||
- "environment=production"
|
||||
Description: "Mute all findings except for critical production resources"
|
||||
```
|
||||
|
||||
#### Tag-Based Logic
|
||||
```yaml
|
||||
Mutelist:
|
||||
Accounts:
|
||||
"*":
|
||||
Checks:
|
||||
"*":
|
||||
Regions:
|
||||
- "*"
|
||||
Resources:
|
||||
- "*"
|
||||
Tags:
|
||||
- "environment=dev | environment=test" # OR logic
|
||||
- "project=alpha" # AND logic
|
||||
Description: "Mute findings for dev/test environments in alpha project"
|
||||
```
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. **Start Small**: Begin with specific resources and gradually expand
|
||||
2. **Document Reasons**: Always include descriptions for audit trails
|
||||
3. **Regular Reviews**: Periodically review muted findings
|
||||
4. **Use Tags**: Leverage resource tags for better organization
|
||||
5. **Test Changes**: Validate mutelist changes in non-production environments
|
||||
6. **Monitor Impact**: Track how muting affects your security posture
|
||||
|
||||
### Validation
|
||||
|
||||
Prowler App validates your mutelist configuration and will display errors for:
|
||||
|
||||
- Invalid YAML syntax
|
||||
- Missing required fields
|
||||
- Invalid regular expressions
|
||||
- Unsupported provider-specific configurations
|
||||
@@ -0,0 +1,223 @@
|
||||
---
|
||||
title: 'Managing Users and Role-Based Access Control (RBAC)'
|
||||
---
|
||||
|
||||
**Prowler App** supports multiple users within a single tenant, enabling seamless collaboration by allowing team members to easily share insights and manage security findings.
|
||||
|
||||
[Roles](#roles) help you control user permissions, determining what actions each user can perform and the data they can access within Prowler. By default, each account includes an immutable **admin** role, ensuring that your account always retains administrative access.
|
||||
|
||||
<Note>
|
||||
If the account is created without an invitation, a new tenant will be provisioned for it. However, if the account is created through an invitation, the user will join the inviter’s tenant.
|
||||
|
||||
</Note>
|
||||
## Membership
|
||||
|
||||
To get to User-Invitation Management we will focus on the Membership section.
|
||||
|
||||
<Note>
|
||||
**Only users that have the _Invite and Manage Users_ or _admin_ permission can access this section.**
|
||||
|
||||
</Note>
|
||||
<img src="/images/prowler-app/rbac/membership.png" alt="Membership tab" width="700" />
|
||||
|
||||
### Users
|
||||
|
||||
#### Editing a User
|
||||
|
||||
Follow these steps to edit a user of your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
|
||||
2. Click the edit button of the user you want to modify.
|
||||
|
||||
<img src="/images/prowler-app/rbac/user_edit.png" alt="Edit User" width="700" />
|
||||
|
||||
3. Edit the user fields you need and save your changes.
|
||||
|
||||
<img src="/images/prowler-app/rbac/user_edit_details.png" alt="Edit User Details" width="700" />
|
||||
|
||||
#### Removing a User
|
||||
|
||||
Follow these steps to remove a user of your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
2. Click the delete button of your current user.
|
||||
|
||||
> **Note: Each user will be able to delete himself and not others, regardless of his permissions.**
|
||||
|
||||
<img src="/images/prowler-app/rbac/user_remove.png" alt="Remove User" width="700" />
|
||||
|
||||
### Invitations
|
||||
|
||||
#### Inviting Users
|
||||
|
||||
<Note>
|
||||
Please be aware that at this time, an email address can only be associated with a single Prowler account_.
|
||||
|
||||
</Note>
|
||||
Follow these steps to invite a user to your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
|
||||
2. Click the **Invite User** button on the top right-hand corner of the screen.
|
||||
|
||||
<img src="/images/prowler-app/rbac/invite.png" alt="Invite User" width="700" />
|
||||
|
||||
3. In the Invite User screen, enter the email address of the user you want to invite.
|
||||
|
||||
4. Pick a Role for the user. You can also change the roles for users and pending invites later. To learn more about the roles and what they can do, see [Roles](#roles).
|
||||
|
||||
<img src="/images/prowler-app/rbac/invitation_info.png" alt="Invitation info" width="700" />
|
||||
|
||||
5. Click the **Send Invitation** button to send the invitation to the user.
|
||||
|
||||
6. After clicking you will see a summary of the status of the invitation. You could access this view again from the invitation menu.
|
||||
|
||||
<img src="/images/prowler-app/rbac/invitation_details.png" alt="Invitation details" width="700" />
|
||||
<img src="/images/prowler-app/rbac/invitation_details_1.png" alt="Invitation button" width="700" />
|
||||
|
||||
7. To allow the user to join your Prowler account you will need to share the link with the user. They will only need to access this URL and follow the steps to create a user and complete their registration. **Note: Invitations will expire after 7 days.**
|
||||
|
||||
<img src="/images/prowler-app/rbac/invitation_sign-up.png" alt="Invitation sign-up" width="700" />
|
||||
|
||||
<Note>
|
||||
If you are a [Prowler Cloud](https://cloud.prowler.com/sign-in) user, the invited user will receive an email with the link to accept the invitation.
|
||||
|
||||
</Note>
|
||||
#### Editing Invitation
|
||||
|
||||
Follow these steps to edit an invitation:
|
||||
|
||||
1. Navigate to **Invitations** from the side menu.
|
||||
|
||||
2. Click the edit button of the invitation and modify the email, the role or both. **Note: Editing an invitation will not reset its expiration time.**
|
||||
|
||||
<img src="/images/prowler-app/rbac/invitation_edit.png" alt="Invitation edit" width="700" />
|
||||
<img src="/images/prowler-app/rbac/invitation_edit_1.png" alt="Invitation edit details" width="700" />
|
||||
|
||||
#### Cancelling Invitation
|
||||
|
||||
Follow these steps to cancel an invitation:
|
||||
|
||||
1. Navigate to **Invitations** from the side menu.
|
||||
|
||||
2. Click the revoke button of the invitation.
|
||||
|
||||
<img src="/images/prowler-app/rbac/invitation_revoke.png" alt="Invitation revoke" width="700" />
|
||||
|
||||
#### Sending an Invitation Again
|
||||
|
||||
To resend the invitation to the user, it is necessary to explicitly **delete the previous invitation and create a new one**.
|
||||
|
||||
## Managing Groups and Roles
|
||||
|
||||
The Roles section in Prowler is designed to facilitate the assignment of custom user privileges. This section allows administrators to define roles with specific permissions for Prowler administrative tasks and Account visibility.
|
||||
|
||||
<Note>
|
||||
**Only users that have the _Manage Account_ or _admin_ permission can access this section.**
|
||||
|
||||
</Note>
|
||||
### Provider Groups
|
||||
|
||||
Provider Groups control visibility across specific providers. When creating a new role, you can assign specific groups to define their Cloud Provider visibility. This ensures that users with that role have access only to the Cloud Providers that are required.
|
||||
|
||||
By default, a new user role does not have visibility into any group.
|
||||
|
||||
Alternatively, to grant the role unlimited visibility across all providers, check the Grant Unlimited Visibility checkbox.
|
||||
|
||||
#### Creating a Provider Group
|
||||
|
||||
Follow these steps to create a provider group in your account:
|
||||
|
||||
1. Navigate to **Provider Groups** from the side menu..
|
||||
|
||||
2. In this view you can select the provider groups you want to assign to one or more roles.
|
||||
|
||||
3. Click the **Create Group** button on the center of the screen.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group.png" alt="Create Provider Group" width="700" />
|
||||
|
||||
#### Editing a Provider Group
|
||||
|
||||
Follow these steps to edit a provider group on your account:
|
||||
|
||||
1. Navigate to **Provider Groups** from the side menu.
|
||||
|
||||
2. Click the edit button of the provider group you want to modify.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit.png" alt="Edit Provider Group" width="700" />
|
||||
|
||||
3. Change the provider group parameters you need and save the changes.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit_1.png" alt="Edit Provider Group Details" width="700" />
|
||||
|
||||
#### Removing a Provider Group
|
||||
|
||||
Follow these steps to remove a provider group of your account:
|
||||
|
||||
1. Navigate to **Provider Groups** from the side menu.
|
||||
|
||||
2. Click on the delete button of the provider group you want to remove.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_remove.png" alt="Remove Provider Group" width="700" />
|
||||
|
||||
### Roles
|
||||
|
||||
#### Creating a Role
|
||||
|
||||
Follow these steps to create a role for your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the **Add Role** button on the top right-hand corner of the screen.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_create.png" alt="Create Role" width="700" />
|
||||
|
||||
3. In the Add Role screen, enter the role name, the administration permissions and the groups of providers to which the Role will have access to.
|
||||
|
||||
4. In the Groups and Account Visibility section, you will see a list of available groups with checkboxes next to them. To assign a group to the user role, simply click the checkbox next to the group name. If you need to assign multiple groups, repeat the process for each group you wish to add.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_create_1.png" alt="Role parameters" width="700" />
|
||||
|
||||
|
||||
<Note>
|
||||
To assign read-only access, select only the `Unlimited Visibility` permission when creating the role. Then, go to the Users page and assign this role to the appropriate user.
|
||||
|
||||
</Note>
|
||||
#### Editing a Role
|
||||
|
||||
Follow these steps to edit a role on your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the edit button of the role you want to modify.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_edit.png" alt="Edit Role" width="700" />
|
||||
|
||||
3. Adjust the settings as needed and save the changes.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_edit_details.png" alt="Edit Role Details" width="700" />
|
||||
|
||||
|
||||
#### Removing a Role
|
||||
|
||||
Follow these steps to remove a role of your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the delete button of the role you want to remove.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_remove.png" alt="Remove Role" width="700" />
|
||||
|
||||
|
||||
## RBAC Administrative Permissions
|
||||
|
||||
Assign administrative permissions by selecting from the following options:
|
||||
|
||||
**Invite and Manage Users:** Invite new users and manage existing ones.<br />
|
||||
**Manage Account:** Adjust account settings, delete users and read/manage users permissions.<br />
|
||||
**Manage Scans:** Run and review scans.<br />
|
||||
**Manage Cloud Providers:** Add or modify connected cloud providers.<br />
|
||||
**Manage Integrations:** Add or modify the Prowler Integrations.
|
||||
|
||||
To grant all administrative permissions, select the **Grant all admin permissions** option.
|
||||
@@ -0,0 +1,426 @@
|
||||
---
|
||||
title: 'Amazon S3 Integration'
|
||||
---
|
||||
|
||||
**Prowler App** allows automatic export of scan results to Amazon S3 buckets, providing seamless integration with existing data workflows and storage infrastructure. This comprehensive guide demonstrates configuration and management of Amazon S3 integrations to streamline security finding management and reporting.
|
||||
|
||||
When enabled and configured, scan results are automatically stored in the configured bucket. Results are provided in `csv`, `html` and `json-ocsf` formats, offering flexibility for custom integrations:
|
||||
|
||||
{/* TODO: remove the comment once the AWS Security Hub integration is completed */}
|
||||
{/* - json-asff */}
|
||||
{/*
|
||||
<Note>
|
||||
The `json-asff` file will be only present in your configured Amazon S3 Bucket if you have the AWS Security Hub integration enabled. You can get more information about that integration here.
|
||||
</Note>
|
||||
*/}
|
||||
|
||||
<Note>
|
||||
Enabling this integration incurs costs in Amazon S3. Refer to [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/) for more information.
|
||||
|
||||
|
||||
</Note>
|
||||
The Amazon S3 Integration provides the following capabilities:
|
||||
|
||||
- **Automate scan result exports** to designated S3 buckets after each scan
|
||||
|
||||
- **Configure separate bucket destinations** for different cloud providers or use cases
|
||||
|
||||
- **Customize export paths** within buckets for organized storage
|
||||
|
||||
- **Support multiple authentication methods** including IAM roles and static credentials
|
||||
|
||||
- **Verify connection reliability** through built-in connection testing
|
||||
|
||||
- **Manage integrations independently** with separate configuration and credential controls
|
||||
|
||||
|
||||
## Required Permissions
|
||||
|
||||
Before configuring the Amazon S3 Integration, ensure that AWS credentials and optionally the IAM Role used for S3 access have the necessary permissions to write scan results to the designated S3 bucket. This requirement applies when using static credentials, session credentials, or an IAM role (either self-created or generated using [Prowler's permissions templates](#available-templates)).
|
||||
|
||||
### IAM Policy
|
||||
|
||||
The S3 integration requires the following permissions. Add these to the IAM role policy, or ensure AWS credentials have these permissions:
|
||||
|
||||
```json title="s3:DeleteObject"
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"s3:ResourceAccount": "<BUCKET AWS ACCOUNT NUMBER>"
|
||||
}
|
||||
},
|
||||
"Action": [
|
||||
"s3:DeleteObject"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::<BUCKET NAME>/*test-prowler-connection.txt"
|
||||
],
|
||||
"Effect": "Allow"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`s3:DeleteObject` permission is required for connection testing. When testing the S3 integration, Prowler creates a temporary beacon file, `test-prowler-connection.txt`, to verify write permissions, then deletes it to confirm the connection is working properly.
|
||||
|
||||
```json title="s3:PutObject"
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"s3:ResourceAccount": "<BUCKET AWS ACCOUNT NUMBER>"
|
||||
}
|
||||
},
|
||||
"Action": [
|
||||
"s3:PutObject"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::<BUCKET NAME>/*"
|
||||
],
|
||||
"Effect": "Allow"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```json title="s3:ListBucket"
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"s3:ResourceAccount": "<BUCKET AWS ACCOUNT NUMBER>"
|
||||
}
|
||||
},
|
||||
"Action": [
|
||||
"s3:ListBucket"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::<BUCKET NAME>"
|
||||
],
|
||||
"Effect": "Allow"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `<BUCKET AWS ACCOUNT NUMBER>` with the AWS account ID that owns the destination S3 bucket, and `<BUCKET NAME>` with the actual bucket name.
|
||||
|
||||
</Note>
|
||||
### Cross-Account S3 Bucket
|
||||
|
||||
If the S3 destination bucket is in a different AWS account than the one providing the credentials for S3 access, configure a bucket policy on the destination bucket to allow cross-account access.
|
||||
|
||||
The following diagrams illustrate the three common S3 integration scenarios:
|
||||
|
||||
##### Same Account Setup (No Bucket Policy Required)
|
||||
|
||||
When both the IAM credentials and destination S3 bucket are in the same AWS account, no additional bucket policy is required.
|
||||
|
||||
|
||||
|
||||
##### Cross-Account Setup (Bucket Policy Required)
|
||||
|
||||
When the S3 bucket is in a different AWS account, you must configure a bucket policy to allow cross-account access.
|
||||
|
||||
|
||||
|
||||
##### Multi-Account Setup (Multiple Principals in Bucket Policy)
|
||||
|
||||
When multiple AWS accounts need to write to the same destination bucket, configure the bucket policy with multiple principals.
|
||||
|
||||
|
||||
|
||||
#### S3 Bucket Policy
|
||||
|
||||
Apply the following bucket policy to the destination S3 bucket:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<SOURCE ACCOUNT ID>:role/ProwlerScan"
|
||||
},
|
||||
"Action": "s3:PutObject",
|
||||
"Resource": "arn:aws:s3:::<BUCKET NAME>/*"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<SOURCE ACCOUNT ID>:role/ProwlerScan"
|
||||
},
|
||||
"Action": "s3:DeleteObject",
|
||||
"Resource": "arn:aws:s3:::<BUCKET NAME>/*test-prowler-connection.txt"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::<SOURCE ACCOUNT ID>:role/ProwlerScan"
|
||||
},
|
||||
"Action": "s3:ListBucket",
|
||||
"Resource": "arn:aws:s3:::<BUCKET NAME>"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `<SOURCE ACCOUNT ID>` with the AWS account ID that contains the IAM role and `<BUCKET NAME>` with the destination bucket name. The role name `ProwlerScan` is the default name when using Prowler's permissions templates. If using a custom IAM role or different authentication method, replace `ProwlerScan` with the actual role name.
|
||||
|
||||
</Note>
|
||||
##### Multi-Account Configuration
|
||||
|
||||
For multiple AWS accounts, modify the `Principal` field to an array:
|
||||
|
||||
```json
|
||||
"Principal": {
|
||||
"AWS": [
|
||||
"arn:aws:iam::<SOURCE ACCOUNT ID 1>:role/ProwlerScan",
|
||||
"arn:aws:iam::<SOURCE ACCOUNT ID 2>:role/ProwlerScan"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Replace `<SOURCE ACCOUNT ID>` with the AWS account ID that contains the IAM role and `<BUCKET NAME>` with the destination bucket name. The role name `ProwlerScan` is the default name when using Prowler's permissions templates. If using a custom IAM role or different authentication method, replace `ProwlerScan` with the actual role name.
|
||||
|
||||
</Note>
|
||||
### Available Templates
|
||||
|
||||
**Prowler App** provides Infrastructure as Code (IaC) templates to automate IAM role setup with S3 integration permissions.
|
||||
|
||||
<Note>
|
||||
Templates are optional. Custom IAM roles or static credentials can be used instead.
|
||||
|
||||
</Note>
|
||||
Choose from the following deployment options:
|
||||
|
||||
- [CloudFormation](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml)
|
||||
- [Terraform](https://github.com/prowler-cloud/prowler/tree/master/permissions/templates/terraform)
|
||||
|
||||
#### CloudFormation
|
||||
|
||||
##### AWS CLI
|
||||
|
||||
When using Prowler's CloudFormation template, execute the following command to update the existing Prowler stack:
|
||||
|
||||
```bash
|
||||
aws cloudformation update-stack \
|
||||
--capabilities CAPABILITY_IAM --capabilities CAPABILITY_NAMED_IAM \
|
||||
--stack-name "Prowler" \
|
||||
--template-url "https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml" \
|
||||
--parameters \
|
||||
ParameterKey=EnableS3Integration,ParameterValue="true" \
|
||||
ParameterKey=ExternalId,ParameterValue="your-external-id" \
|
||||
ParameterKey=S3IntegrationBucketName,ParameterValue="your-bucket-name" \
|
||||
ParameterKey=S3IntegrationBucketAccountId,ParameterValue="your-bucket-aws-account-id-owner"
|
||||
```
|
||||
|
||||
Alternatively, if you don't have the `ProwlerScan` IAM Role, execute the following command to create the CloudFormation stack:
|
||||
|
||||
```bash
|
||||
aws cloudformation create-stack \
|
||||
--capabilities CAPABILITY_IAM --capabilities CAPABILITY_NAMED_IAM \
|
||||
--stack-name "Prowler" \
|
||||
--template-url "https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml" \
|
||||
--parameters \
|
||||
ParameterKey=EnableS3Integration,ParameterValue="true" \
|
||||
ParameterKey=ExternalId,ParameterValue="your-external-id" \
|
||||
ParameterKey=S3IntegrationBucketName,ParameterValue="your-bucket-name" \
|
||||
ParameterKey=S3IntegrationBucketAccountId,ParameterValue="your-bucket-aws-account-id-owner"
|
||||
```
|
||||
|
||||
A CloudFormation Quick Link is also available [here](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https%3A%2F%2Fprowler-cloud-public.s3.eu-west-1.amazonaws.com%2Fpermissions%2Ftemplates%2Faws%2Fcloudformation%2Fprowler-scan-role.yml&stackName=Prowler¶m_EnableS3Integration=true)
|
||||
|
||||
##### AWS Console
|
||||
|
||||
If using Prowler's CloudFormation template, execute the following command to update the existing Prowler stack:
|
||||
|
||||
|
||||
1. Navigate to CloudFormation service in the AWS region you are using
|
||||
2. Select "ProwlerScan", click "Update" and then "Make a direct update"
|
||||
3. Replace template, uploading the [CloudFormation template](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml)
|
||||
4. Configure parameters:
|
||||
- `ExternalId`: Keep existing value
|
||||
- `EnableS3Integration`: Select "true"
|
||||
- `S3IntegrationBucketName`: Your bucket name
|
||||
- `S3IntegrationBucketAccountId`: Bucket owner's AWS account ID
|
||||
5. In the "Configure stack options" screen, again, leave everything as it is and click on "Next"
|
||||
6. Finally, under "Review Prowler", at the bottom click on "Submit"
|
||||
|
||||
#### Terraform
|
||||
|
||||
1. Download the Terraform code:
|
||||
```bash
|
||||
# Clone or download from GitHub
|
||||
git clone https://github.com/prowler-cloud/prowler.git
|
||||
cd prowler/permissions/templates/terraform
|
||||
```
|
||||
|
||||
2. Configure your variables:
|
||||
```bash
|
||||
cp terraform.tfvars.example terraform.tfvars
|
||||
```
|
||||
|
||||
3. Edit `terraform.tfvars` with your specific values:
|
||||
```hcl
|
||||
# Required: External ID from Prowler App
|
||||
external_id = "your-unique-external-id-here"
|
||||
|
||||
# S3 Integration Configuration
|
||||
enable_s3_integration = true
|
||||
s3_integration_bucket_name = "your-s3-bucket-name"
|
||||
s3_integration_bucket_account_id = "123456789012" # Bucket owner's AWS Account ID
|
||||
```
|
||||
|
||||
4. Deploy the infrastructure:
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan # Review the planned changes
|
||||
terraform apply # Type 'yes' when prompted
|
||||
```
|
||||
|
||||
5. After successful deployment, Terraform will display important values:
|
||||
```
|
||||
Outputs:
|
||||
prowler_role_arn = "arn:aws:iam::123456789012:role/ProwlerScan"
|
||||
prowler_role_name = "ProwlerScan"
|
||||
s3_integration_enabled = "true"
|
||||
```
|
||||
|
||||
6. Copy the `prowler_role_arn`, as it's required to complete the S3 integration credentials configuration.
|
||||
|
||||
For detailed information, refer to the [Terraform README](https://github.com/prowler-cloud/prowler/blob/master/permissions/templates/terraform/README.md).
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
Once the required permissions are set up, proceed to configure the S3 integration in **Prowler App**.
|
||||
|
||||
1. Navigate to "Integrations"
|
||||
|
||||
2. Locate the Amazon S3 Integration card and click on the "Configure" button
|
||||
|
||||
3. Click the "Add Integration" button
|
||||
|
||||
4. Complete the configuration form with the following details:
|
||||
|
||||
- **Cloud Providers:** Select the providers whose scan results should be exported to this S3 bucket
|
||||
- **Bucket Name:** Enter the name of the target S3 bucket (e.g., `my-security-findings-bucket`)
|
||||
- **Output Directory:** Specify the directory path within the bucket (e.g., `/prowler-findings/`, defaults to `output`)
|
||||
|
||||
|
||||
|
||||
6. Click "Next" to configure credentials
|
||||
7. Configure AWS authentication using one of the supported methods:
|
||||
|
||||
- **AWS SDK Default:** Use default AWS credentials from the environment. For Prowler Cloud users, this is the recommended option as the service has AWS credentials to assume IAM roles with ARNs matching `arn:aws:iam::*:role/Prowler*` or `arn:aws:iam::*:role/prowler*`
|
||||
- **Access Keys:** Provide AWS access key ID and secret access key
|
||||
- **IAM Role (optional):** Specify the IAM Role ARN, external ID, and optional session parameters
|
||||
|
||||
|
||||
|
||||
8. Optional - For IAM role authentication, complete the required fields:
|
||||
|
||||
- **Role ARN:** The Amazon Resource Name of the IAM role
|
||||
- **External ID:** Unique identifier for additional security (defaults to Tenant/Organization ID) - mandatory and automatically filled
|
||||
- **Role Session Name:** Optional - name for the assumed role session
|
||||
- **Session Duration:** Optional - duration in seconds for the session
|
||||
|
||||
9. Click "Create Integration" to verify the connection and complete the setup
|
||||
|
||||
<Check>
|
||||
Once credentials are configured and the connection test passes, the S3 integration will be active. Scan results will automatically be exported to the specified bucket after each scan completes. Run a new scan and check the S3 bucket to verify the integration is working.
|
||||
|
||||
</Check>
|
||||
<Note>
|
||||
Scan outputs are processed after scan completion. Depending on scan size and network conditions, exports may take a few minutes to appear in the S3 bucket.
|
||||
</Note>
|
||||
---
|
||||
|
||||
|
||||
### Integration Status
|
||||
|
||||
Once the integration is active, monitor its status and make adjustments as needed through the integrations management interface.
|
||||
|
||||
1. Review configured integrations in the management interface
|
||||
2. Each integration displays:
|
||||
|
||||
- **Connection Status:** Connected or Disconnected indicator
|
||||
- **Bucket Information:** Bucket name and output directory
|
||||
- **Last Checked:** Timestamp of the most recent connection test
|
||||
|
||||
|
||||
|
||||
#### Actions
|
||||
|
||||
|
||||
|
||||
Each S3 integration provides several management actions accessible through dedicated buttons:
|
||||
|
||||
| Button | Purpose | Available Actions | Notes |
|
||||
|--------|---------|------------------|-------|
|
||||
| **Test** | Verify integration connectivity | • Test AWS credential validity<br/>• Check S3 bucket accessibility<br/>• Verify write permissions<br/>• Validate connection setup | Results displayed in notification message |
|
||||
| **Config** | Modify integration settings | • Update selected cloud providers<br/>• Change bucket name<br/>• Modify output directory path | Click "Update Configuration" to save changes |
|
||||
| **Credentials** | Update authentication settings | • Modify AWS access keys<br/>• Update IAM role configuration<br/>• Change authentication method | Click "Update Credentials" to save changes |
|
||||
| **Enable/Disable** | Toggle integration status | • Enable integration to start exporting results<br/>• Disable integration to pause exports | Status change takes effect immediately |
|
||||
| **Delete** | Remove integration permanently | • Permanently delete integration<br/>• Remove all configuration data | ⚠️ **Cannot be undone** - confirm before deleting |
|
||||
|
||||
<Tip>
|
||||
**Management Best Practices**
|
||||
|
||||
- Test the integration after any configuration changes
|
||||
- Use the Enable/Disable toggle for temporary changes instead of deleting
|
||||
|
||||
|
||||
</Tip>
|
||||
---
|
||||
|
||||
## Understanding S3 Export Structure
|
||||
|
||||
When the S3 integration is enabled and a scan completes, Prowler creates a folder inside the specified bucket path (using `output` as the default folder name) with subfolders for each output format:
|
||||
|
||||
- Regular: `prowler-output-{provider-uid}-{timestamp}.{extension}`
|
||||
- Compliance: `prowler-output-{provider-uid}-{timestamp}_{compliance_framework}.{extension}`
|
||||
|
||||
```
|
||||
output/
|
||||
├── compliance/
|
||||
│ └── prowler-output-111122223333-20250805120000_cis_5.0_aws.csv
|
||||
├── csv/
|
||||
│ └── prowler-output-111122223333-20250805120000.csv
|
||||
├── html/
|
||||
│ └── prowler-output-111122223333-20250805120000.html
|
||||
└── json-ocsf/
|
||||
└── prowler-output-111122223333-20250805120000.ocsf.json
|
||||
```
|
||||
|
||||
|
||||
|
||||
For detailed information about Prowler's reporting formats, refer to the [Prowler reporting documentation](https://docs.prowler.com/projects/prowler-open-source/en/latest/tutorials/reporting/).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Connection test fails:**
|
||||
|
||||
- Check AWS credentials are valid
|
||||
- If using IAM Role, check its permissions
|
||||
- Verify bucket permissions and region
|
||||
- Confirm network access to S3
|
||||
|
||||
**No scan results in bucket:**
|
||||
|
||||
- Ensure integration shows "Connected"
|
||||
- Check that provider is associated with integration
|
||||
- Verify bucket policies allow writes
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
title: "AWS Security Hub Integration"
|
||||
---
|
||||
|
||||
Prowler App enables automatic export of security findings to AWS Security Hub, providing seamless integration with AWS's native security and compliance service. This comprehensive guide demonstrates how to configure and manage AWS Security Hub integrations to centralize security findings and enhance compliance tracking across AWS environments.
|
||||
|
||||
Integrating Prowler App with AWS Security Hub provides:
|
||||
|
||||
* **Centralized security visibility:** Consolidate findings from multiple AWS accounts and regions
|
||||
* **Native AWS integration:** Leverage existing AWS security workflows and compliance frameworks
|
||||
* **Automated finding management:** Archive resolved findings and filter results based on severity
|
||||
* **Cost optimization:** Send only failed findings to reduce AWS Security Hub costs
|
||||
* **Real-time updates:** Automatically export findings after each scan completion
|
||||
|
||||
## How It Works
|
||||
|
||||
When enabled and configured:
|
||||
|
||||
1. Scan results are automatically sent to AWS Security Hub after each scan completes
|
||||
2. Findings are formatted in [AWS Security Finding Format](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) (ASFF)
|
||||
3. The integration automatically detects new AWS regions to send findings if the Prowler partner integration is enabled
|
||||
4. Previously resolved findings are archived to maintain clean Security Hub dashboards
|
||||
|
||||
<Note>
|
||||
Refer to [AWS Security Hub pricing](https://aws.amazon.com/security-hub/pricing/) for cost information.
|
||||
|
||||
</Note>
|
||||
## Prerequisites
|
||||
|
||||
Before configuring AWS Security Hub Integration in Prowler App, complete these steps:
|
||||
|
||||
### AWS Security Hub Setup
|
||||
|
||||
Enable the Prowler partner integration in AWS Security Hub by following the [AWS Security Hub setup documentation](/user-guide/providers/aws/securityhub#enabling-aws-security-hub-for-prowler-integration).
|
||||
|
||||
### AWS Authentication
|
||||
|
||||
Configure AWS credentials by following the [AWS authentication setup guide](/user-guide/providers/aws/getting-started-aws#step-3-set-up-aws-authentication).
|
||||
|
||||
## Configuration
|
||||
|
||||
To configure AWS Security Hub integration in Prowler App:
|
||||
|
||||
1. Navigate to **Integrations** in the Prowler App interface
|
||||
2. Locate the **AWS Security Hub** card and click **Manage**, then select **Add integration**
|
||||
|
||||
|
||||
|
||||
3. Complete the integration settings
|
||||
|
||||
* **AWS Provider:** Select the AWS provider whose findings should be exported to Security Hub
|
||||
* **Send Only Failed Findings:** Filter out `PASS` findings to reduce AWS Security Hub costs (enabled by default)
|
||||
* **Archive Previous Findings:** Automatically archive findings resolved since the last scan to maintain clean Security Hub dashboards
|
||||
|
||||
|
||||
|
||||
4. Configure authentication:
|
||||
|
||||
Choose the appropriate authentication method:
|
||||
|
||||
* **Use Provider Credentials** (recommended): Leverages the AWS provider's existing credentials
|
||||
|
||||
<Tip>
|
||||
**Simplified Credential Management**
|
||||
|
||||
Using provider credentials reduces administrative complexity by managing a single set of credentials instead of maintaining separate authentication mechanisms. This approach minimizes security risks and provides the most efficient integration path when the AWS account has sufficient permissions to export findings to Security Hub.
|
||||
|
||||
</Tip>
|
||||
* **Custom Credentials:** Configure separate credentials specifically for Security Hub access
|
||||
|
||||
|
||||
5. Click **Create integration** to enable the integration
|
||||
|
||||
|
||||
|
||||
Once configured successfully, findings from subsequent scans will automatically appear in AWS Security Hub.
|
||||
|
||||
### Integration Status
|
||||
|
||||
Once the integration is active, monitor its status and make adjustments as needed through the integrations management interface.
|
||||
|
||||
1. Review configured integrations in the management interface
|
||||
2. Each integration displays:
|
||||
|
||||
- **Connection Status:** Connected or Disconnected indicator.
|
||||
- **Provider Information:** Selected AWS provider name.
|
||||
- **Finding Filters:** Status of failed-only and archive settings.
|
||||
- **Last Checked:** Timestamp of the most recent connection test.
|
||||
- **Regions:** List of regions where the integration is active.
|
||||
|
||||
#### Actions
|
||||
|
||||
Each Security Hub integration provides several management actions accessible through dedicated buttons:
|
||||
|
||||
| Button | Purpose | Available Actions | Notes |
|
||||
|--------|---------|------------------|-------|
|
||||
| **Test** | Verify integration connectivity | • Test AWS credential validity<br/>• Check Security Hub accessibility<br/>• Detect enabled regions automatically<br/>• Validate finding export capability | Results displayed in notification message |
|
||||
| **Config** | Modify integration settings | • Update AWS provider selection<br/>• Change finding filter settings<br/>• Modify archive preferences | Click "Update Configuration" to save changes |
|
||||
| **Credentials** | Update authentication settings | • Switch between provider/custom credentials<br/>• Update AWS access keys<br/>• Change IAM role configuration | Click "Update Credentials" to save changes |
|
||||
| **Enable/Disable** | Toggle integration status | • Enable integration to start exporting findings<br/>• Disable integration to pause exports | Status change takes effect immediately |
|
||||
| **Delete** | Remove integration permanently | • Permanently delete integration<br/>• Remove all configuration data | ⚠️ **Cannot be undone** - confirm before deleting |
|
||||
|
||||
<Tip>
|
||||
**Management Best Practices**
|
||||
|
||||
- Test the integration after any configuration changes
|
||||
- Use the Enable/Disable toggle for temporary changes instead of deleting
|
||||
- Monitor the Last Checked timestamp to ensure recent connectivity
|
||||
|
||||
|
||||
</Tip>
|
||||
## Viewing Findings in AWS Security Hub
|
||||
|
||||
After successful configuration and scan completion, Prowler findings automatically appear in AWS Security Hub. For detailed information about accessing and interpreting findings in the Security Hub console, refer to the [AWS Security Hub findings documentation](/user-guide/providers/aws/securityhub#viewing-prowler-findings-in-aws-security-hub).
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Connection test fails:**
|
||||
|
||||
- Verify AWS Security Hub is enabled in target regions
|
||||
- Confirm Prowler integration is accepted in Security Hub
|
||||
- Check IAM permissions include required Security Hub actions
|
||||
- If using IAM Role, verify trust policy and External ID
|
||||
|
||||
**No findings in Security Hub:**
|
||||
|
||||
- Ensure integration shows "Connected" status
|
||||
- Verify a scan has completed after enabling integration
|
||||
- Check Security Hub console in the correct region
|
||||
- Confirm finding filters match expectations
|
||||
|
||||
**Authentication errors:**
|
||||
|
||||
- For provider credentials, verify provider configuration
|
||||
- For custom credentials, check access key validity
|
||||
- For IAM roles, confirm role ARN and External ID match
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 'Social Login Configuration'
|
||||
---
|
||||
|
||||
**Prowler App** supports social login using Google and GitHub OAuth providers. This document guides you through configuring the required environment variables to enable social authentication.
|
||||
|
||||
<img src="/images/prowler-app/social-login/social_login_buttons.png" alt="Social login buttons" width="700" />
|
||||
## Configuring Social Login Credentials
|
||||
|
||||
To enable social login with Google and GitHub, you must define the following environment variables:
|
||||
|
||||
### Google OAuth Configuration
|
||||
|
||||
Set the following environment variables for Google OAuth:
|
||||
|
||||
```env
|
||||
SOCIAL_GOOGLE_OAUTH_CLIENT_ID=""
|
||||
SOCIAL_GOOGLE_OAUTH_CLIENT_SECRET=""
|
||||
```
|
||||
|
||||
### GitHub OAuth Configuration
|
||||
|
||||
Set the following environment variables for GitHub OAuth:
|
||||
|
||||
```env
|
||||
SOCIAL_GITHUB_OAUTH_CLIENT_ID=""
|
||||
SOCIAL_GITHUB_OAUTH_CLIENT_SECRET=""
|
||||
```
|
||||
|
||||
### Important Notes
|
||||
|
||||
- If either `SOCIAL_GOOGLE_OAUTH_CLIENT_ID` or `SOCIAL_GOOGLE_OAUTH_CLIENT_SECRET` is empty or not defined, the Google login button will be disabled.
|
||||
- If either `SOCIAL_GITHUB_OAUTH_CLIENT_ID` or `SOCIAL_GITHUB_OAUTH_CLIENT_SECRET` is empty or not defined, the GitHub login button will be disabled.
|
||||
|
||||
<img src="/images/prowler-app/social-login/social_login_buttons_disabled.png" alt="Social login buttons disabled" width="700" />
|
||||
## Obtaining OAuth Credentials
|
||||
|
||||
To obtain `CLIENT_ID` and `CLIENT_SECRET` for each provider, follow their official documentation:
|
||||
|
||||
- **Google OAuth**: [Google OAuth Credentials Setup](https://developers.google.com/identity/protocols/oauth2)
|
||||
- **GitHub OAuth**: [GitHub OAuth App Setup](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app)
|
||||
|
||||
### Overview of the Steps
|
||||
|
||||
For both providers, the process generally involves:
|
||||
|
||||
1. Registering your application in the provider's developer portal.
|
||||
2. Defining the authorized redirect URL (`SOCIAL_<PROVIDER>_OAUTH_CALLBACK_URL`).
|
||||
3. Copying the generated `CLIENT_ID` and `CLIENT_SECRET` into the corresponding environment variables.
|
||||
|
||||
Once completed, ensure your environment variables are correctly loaded in your Prowler deployment to activate social login.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: 'Entra ID Configuration'
|
||||
---
|
||||
|
||||
This page provides instructions for creating and configuring a Microsoft Entra ID (formerly Azure AD) application to use SAML SSO with Prowler App.
|
||||
|
||||
You can find a walkthrough video [here](https://www.youtube.com/watch?v=zegqm55oJVk).
|
||||
|
||||
## Creating and Configuring the Enterprise Application
|
||||
|
||||
1. From the "Enterprise Applications" page in the Azure Portal, click "+ New application".
|
||||
|
||||
|
||||
|
||||
2. At the top of the page, click "+ Create your own application".
|
||||
|
||||
|
||||
|
||||
3. Enter a name for the application and select the "Integrate any other application you don't find in the gallery (Non-gallery)" option.
|
||||
|
||||
|
||||
|
||||
4. Assign users and groups to the application, then proceed to "Set up single sign on" and select "SAML" as the method.
|
||||
|
||||
|
||||
|
||||
5. In the "Basic SAML Configuration" section, click "Edit".
|
||||
|
||||
|
||||
|
||||
6. Enter the "Identifier (Entity ID)" and "Reply URL (Assertion Consumer Service URL)". These values can be obtained from the SAML SSO integration setup in Prowler App. For detailed instructions, refer to the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso) page.
|
||||
|
||||
|
||||
|
||||
7. In the "SAML Certificates" section, click "Edit".
|
||||
|
||||
|
||||
|
||||
8. For the "Signing Option," select "Sign SAML response and assertion", and then click "Save".
|
||||
|
||||
|
||||
|
||||
9. Once the changes are saved, the metadata XML can be downloaded from the "App Federation Metadata Url".
|
||||
|
||||
|
||||
|
||||
10. Save the downloaded Metadata XML to a file. To complete the setup, upload this file during the Prowler App integration. (See the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso) page for details).
|
||||
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: 'SAML Single Sign-On (SSO)'
|
||||
---
|
||||
|
||||
This guide provides comprehensive instructions to configure SAML-based Single Sign-On (SSO) in Prowler App. This configuration allows users to authenticate using the organization's Identity Provider (IdP).
|
||||
|
||||
This document is divided into two main sections:
|
||||
|
||||
- **User Guide**: For organization administrators to configure SAML SSO through Prowler App.
|
||||
|
||||
- **Developer and Administrator Guide**: For developers and system administrators running self-hosted Prowler App instances, providing technical details on environment configuration, API usage, and testing.
|
||||
|
||||
---
|
||||
|
||||
## User Guide Configuration
|
||||
|
||||
Follow these steps to enable and configure SAML SSO for an organization.
|
||||
|
||||
### Key Features
|
||||
|
||||
Prowler can be integrated with SAML SSO identity providers such as Okta to enable single sign-on for the organization's users. The Prowler SAML integration currently supports the following features:
|
||||
|
||||
- [**IdP-Initiated SSO**](#idp-initiated-sso): Users can initiate login from their Identity Provider's dashboard.
|
||||
- [**SP-Initiated SSO**](#sp-initiated-sso): Users can initiate login directly from the Prowler login page.
|
||||
- **Just-in-Time Provisioning**: Users from the organization signing into Prowler for the first time will be automatically created.
|
||||
|
||||
<Warning>
|
||||
**Deactivate SAML**
|
||||
|
||||
If the SAML configuration is removed, users who previously authenticated via SAML will need to reset their password to regain access using standard login. This occurs because accounts no longer have valid authentication credentials without the SAML integration.
|
||||
|
||||
</Warning>
|
||||
### Prerequisites
|
||||
|
||||
- Administrator access to the Prowler organization is required.
|
||||
- Administrative access to the SAML 2.0 compliant Identity Provider (e.g., Okta, Azure AD, Google Workspace) is necessary.
|
||||
|
||||
### Configuration Steps
|
||||
|
||||
#### Step 1: Access Profile Settings
|
||||
|
||||
To access the account settings, click the "Account" button in the top-right corner of Prowler App, or navigate directly to `https://cloud.prowler.com/profile` (or `http://localhost:3000/profile` for local setups).
|
||||
|
||||
|
||||
|
||||
#### Step 2: Enable SAML Integration
|
||||
|
||||
On the profile page, find the "SAML SSO Integration" card and click "Enable" to begin the configuration process.
|
||||
|
||||
|
||||
|
||||
<Info>
|
||||
**Choose Your Method**
|
||||
|
||||
**Use Step 3A (Generic Method)** for any SAML 2.0 compliant Identity Provider or when you need custom configuration.
|
||||
|
||||
**Use Step 3B (Okta App Catalog)** if you're using Okta and want a simplified setup process with pre-configured settings.
|
||||
|
||||
</Info>
|
||||
#### Step 3A: Configure the Identity Provider (IdP) - Generic
|
||||
|
||||
Prowler App displays the SAML configuration information needed to configure the IdP. Use this information to create a new SAML application in the IdP.
|
||||
|
||||
1. **Assertion Consumer Service (ACS) URL**: The endpoint in Prowler that will receive the SAML assertion from the IdP.
|
||||
2. **Audience URI (Entity ID)**: A unique identifier for the Prowler application (Service Provider).
|
||||
|
||||
To configure the IdP, copy the **ACS URL** and **Audience URI** from Prowler App and use them to set up a new SAML application.
|
||||
|
||||
|
||||
|
||||
<Info>
|
||||
**IdP Configuration**
|
||||
|
||||
The exact steps for configuring an IdP vary depending on the provider (Okta, Azure AD, etc.). Please refer to the IdP's documentation for instructions on creating a SAML application. For SSO integration with Azure AD / Entra ID, see our [Entra ID configuration instructions](/user-guide/tutorials/prowler-app-sso-entra).
|
||||
|
||||
</Info>
|
||||
#### Step 3B: Configure Prowler from App Catalog - Okta
|
||||
|
||||
Instead of creating a custom SAML integration, Okta administrators can configure Prowler Cloud directly from Okta's application catalog:
|
||||
|
||||
1. **Access App Catalog**: Navigate to the IdP's application catalog (e.g., [Browse App Catalog](https://www.okta.com/integrations/) in Okta).
|
||||
|
||||
|
||||
|
||||
2. **Search for Prowler Cloud**: Use the search functionality to find "Prowler Cloud" in the app catalog. The official Prowler Cloud application will appear in the search results.
|
||||
|
||||
|
||||
|
||||
3. **Select Prowler Cloud Application**: Click on the Prowler Cloud application from the search results to view its details page.
|
||||
|
||||
|
||||
|
||||
4. **Add Integration**: Click the "Add Integration" button to begin adding Prowler Cloud to the organization's applications.
|
||||
|
||||
5. **Configure General Settings**: In the "Add Prowler Cloud" configuration screen, the integration automatically configures the necessary settings.
|
||||
|
||||
|
||||
|
||||
6. **Assign Users**: Navigate to the **Assignments** tab and assign the appropriate users or groups to the Prowler application by clicking "Assign" and selecting "Assign to People" or "Assign to Groups".
|
||||
|
||||
With this step, the Okta app catalog configuration is complete. Users can now access Prowler Cloud using either [IdP-initiated](#idp-initiated-sso) or [SP-initiated SSO](#sp-initiated-sso) flows.
|
||||
|
||||
**If you used Step 3B (Okta App Catalog)**, jump to [Step 6: Save and Verify Configuration](#step-6-save-and-verify-configuration).
|
||||
|
||||
#### Step 4: Configure Attribute Mapping in the IdP
|
||||
|
||||
For Prowler App to correctly identify and provision users, configure the IdP to send the following attributes in the SAML assertion:
|
||||
|
||||
| Attribute Name | Description | Required |
|
||||
|----------------|---------------------------------------------------------------------------------------------------------|----------|
|
||||
| `firstName` | The user's first name. | Yes |
|
||||
| `lastName` | The user's last name. | Yes |
|
||||
| `userType` | The Prowler role to be assigned to the user (e.g., `admin`, `auditor`). If a role with that name already exists, it will be used; otherwise, a new role called `no_permissions` will be created with minimal permissions. Role permissions can be edited in the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac). | No |
|
||||
| `companyName` | The user's company name. This is automatically populated if the IdP sends an `organization` attribute. | No |
|
||||
|
||||
<Info>
|
||||
**IdP Attribute Mapping**
|
||||
|
||||
Note that the attribute name is just an example and may be different depending on the IdP. For instance, if the IdP provides a 'division' attribute, it can be mapped to 'userType'.
|
||||
|
||||
|
||||
</Info>
|
||||
<Warning>
|
||||
**Dynamic Updates**
|
||||
|
||||
Prowler App updates these attributes each time a user logs in. Any changes made in the Identity Provider (IdP) will be reflected when the user logs in again.
|
||||
|
||||
</Warning>
|
||||
#### Step 5: Upload IdP Metadata to Prowler
|
||||
|
||||
Once the IdP is configured, it provides a **metadata XML file**. This file contains the IdP's configuration information, such as its public key and login URL.
|
||||
|
||||
To complete the Prowler App configuration:
|
||||
|
||||
1. Return to the Prowler SAML configuration page.
|
||||
|
||||
2. Enter the **email domain** for the organization (e.g., `mycompany.com`). Prowler App uses this to identify users who should authenticate via SAML.
|
||||
|
||||
3. Upload the **metadata XML file** downloaded from the IdP.
|
||||
|
||||
|
||||
|
||||
#### Step 6: Save and Verify Configuration
|
||||
|
||||
Click the "Save" button to complete the setup. The "SAML Integration" card will now display an "Active" status, indicating the configuration is complete and enabled.
|
||||
|
||||
|
||||
|
||||
<Info>
|
||||
**IdP Configuration**
|
||||
|
||||
The exact steps for configuring an IdP vary depending on the provider (Okta, Azure AD, etc.). Please refer to the IdP's documentation for instructions on creating a SAML application.
|
||||
|
||||
</Info>
|
||||
##### Remove SAML Configuration
|
||||
SAML SSO can be disabled by removing the existing configuration from the integration panel.
|
||||
|
||||
|
||||
### IdP-Initiated SSO
|
||||
|
||||
Once SAML SSO is configured, users can access Prowler Cloud directly from their Identity Provider's dashboard:
|
||||
|
||||
1. Navigate to the IdP dashboard or portal
|
||||
2. Click on the Prowler Cloud application tile
|
||||
3. The system automatically authenticates users and redirects them to Prowler Cloud
|
||||
|
||||
This method is convenient for users who primarily work from the IdP portal and prefer a seamless single-click access.
|
||||
|
||||
### SP-Initiated SSO
|
||||
|
||||
Users can also initiate the login process directly from Prowler's login page:
|
||||
|
||||
1. Navigate to the Prowler login page
|
||||
2. Click "Continue with SAML SSO"
|
||||
|
||||
3. Enter their email address from the configured domain
|
||||
|
||||
4. The system redirects users to the IdP for authentication
|
||||
5. After successful authentication, users are returned to Prowler App
|
||||
|
||||
This method is useful when users bookmark Prowler or navigate directly to the application.
|
||||
|
||||
---
|
||||
|
||||
## Developer and Administrator Guide
|
||||
|
||||
This section provides technical details for developers and administrators of self-hosted Prowler instances.
|
||||
|
||||
### Environment Configuration
|
||||
|
||||
For self-hosted deployments, several environment variables must be configured to ensure SAML SSO functions correctly. These variables are typically set in an `.env` file.
|
||||
|
||||
| Variable | Description | Example |
|
||||
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
|
||||
| `API_BASE_URL` | The base URL of the Prowler API instance. | `http://mycompany.prowler/api/v1` |
|
||||
| `DJANGO_ALLOWED_HOSTS` | A comma-separated list of hostnames that the Django backend will accept requests from. Include any domains used to access the Prowler API. | `localhost,127.0.0.1,prowler-api,mycompany.prowler` |
|
||||
| `AUTH_URL` | The base URL of the Prowler web UI. This is used to construct the callback URL after authentication. | `http://mycompany.prowler` |
|
||||
| `SAML_SSO_CALLBACK_URL` | The full callback URL where users are redirected after authenticating with the IdP. It is typically constructed using the `AUTH_URL`. | `${AUTH_URL}/api/auth/callback/saml` |
|
||||
|
||||
After modifying these variables, the Prowler API must be restarted for the changes to take effect.
|
||||
|
||||
### SAML API Reference
|
||||
|
||||
Prowler provides a REST API to manage SAML configurations programmatically.
|
||||
|
||||
- **Endpoint**: `/api/v1/saml-config`
|
||||
- **Methods**:
|
||||
- `GET`: Retrieve the current SAML configuration for the tenant.
|
||||
- `POST`: Create a new SAML configuration.
|
||||
- `PATCH`: Update an existing SAML configuration.
|
||||
- `DELETE`: Remove the SAML configuration.
|
||||
|
||||
<Note>
|
||||
**API Documentation**
|
||||
|
||||
For detailed information on using the API, refer to the [Prowler API Reference](https://api.prowler.com/api/v1/docs#tag/SAML/operation/saml_config_create).
|
||||
|
||||
</Note>
|
||||
#### SAML Initiate Endpoint
|
||||
|
||||
- **Endpoint**: `POST /api/v1/accounts/saml/initiate/`
|
||||
- **Description**: This endpoint initiates the SAML login flow. It takes an email address, determines if the domain has a SAML configuration, and redirects the user to the appropriate IdP login page. It is primarily designed for browser-based flows.
|
||||
|
||||
### Testing SAML Integration
|
||||
|
||||
Follow these steps to test a SAML integration in a development environment.
|
||||
|
||||
#### 1. Expose the Local Environment
|
||||
|
||||
Since the IdP needs to send requests to the local Prowler instance, it must be exposed to the internet. A tool like `ngrok` can be used for this purpose.
|
||||
|
||||
To start ngrok, run the following command:
|
||||
```bash
|
||||
ngrok http 8080
|
||||
```
|
||||
This command provides a public URL (e.g., `https://<random-string>.ngrok.io`) that forwards to the local server on port 8080.
|
||||
|
||||
#### 2. Update `DJANGO_ALLOWED_HOSTS`
|
||||
|
||||
To allow requests from ngrok, add its URL to the `DJANGO_ALLOWED_HOSTS` environment variable.
|
||||
|
||||
```env
|
||||
DJANGO_ALLOWED_HOSTS=localhost,127.0.0.1,prowler-api,*.ngrok.io
|
||||
```
|
||||
|
||||
#### 3. Configure the IdP
|
||||
|
||||
When configuring the IdP for testing, use the ngrok URL for the ACS URL:
|
||||
`https://<your-ngrok-url>/api/v1/accounts/saml/<YOUR_DOMAIN>/acs/`
|
||||
|
||||
#### 4. Configure Prowler via API
|
||||
|
||||
To create a SAML configuration for testing, use `curl`. Replace placeholders with actual data.
|
||||
|
||||
```bash
|
||||
curl --location 'http://localhost:8080/api/v1/saml-config' \
|
||||
--header 'Content-Type: application/vnd.api+json' \
|
||||
--header 'Accept: application/vnd.api+json' \
|
||||
--header 'Authorization: Bearer <YOUR_API_TOKEN>' \
|
||||
--data '{
|
||||
"data": {
|
||||
"type": "saml-configurations",
|
||||
"attributes": {
|
||||
"email_domain": "yourdomain.com",
|
||||
"metadata_xml": "<PASTE_YOUR_IDP_METADATA_XML_HERE>"
|
||||
}
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
#### 5. Initiate Login Flow
|
||||
|
||||
To test the end-to-end flow, construct the login URL and open it in a browser. This starts the IdP-initiated login flow.
|
||||
|
||||
`https://<your-ngrok-url>/api/v1/accounts/saml/<YOUR_DOMAIN>/login/`
|
||||
|
||||
If successful, the user will be redirected back to the Prowler application with a valid session.
|
||||
@@ -0,0 +1,357 @@
|
||||
---
|
||||
title: 'Prowler Cloud'
|
||||
---
|
||||
|
||||
**Prowler Cloud** is a web application that simplifies running Prowler. This tutorial will guide you through setting up and using it.
|
||||
|
||||
We refer to **Prowler App** as the self-hosted version of **Prowler Cloud**.
|
||||
|
||||
## Accessing Prowler Cloud and API Documentation
|
||||
|
||||
If you are a [Prowler Cloud](https://cloud.prowler.com/sign-in) user, you can access API docs at [https://api.prowler.com/api/v1/docs](https://api.prowler.com/api/v1/docs)
|
||||
|
||||
<Note>
|
||||
**For Prowler App users**
|
||||
|
||||
After [installing](/getting-started/installation/prowler-app) **Prowler App**, access it at [http://localhost:3000](http://localhost:3000).
|
||||
|
||||
To view the auto-generated **Prowler API** documentation, navigate to [http://localhost:8080/api/v1/docs](http://localhost:8080/api/v1/docs). This documentation provides details on available endpoints, parameters, and responses.
|
||||
</Note>
|
||||
|
||||
## **Step 1: Sign Up**
|
||||
|
||||
### **Sign Up with Email**
|
||||
|
||||
To get started, sign up using your email and password:
|
||||
|
||||
<img src="/images/sign-up-button.png" alt="Sign Up Button" width="320" />
|
||||
<img src="/images/sign-up.png" alt="Sign Up" width="285" />
|
||||
|
||||
### **Sign Up with Social Login**
|
||||
|
||||
If Social Login is enabled, you can sign up using your preferred provider (e.g., Google, GitHub).
|
||||
|
||||
<Note>
|
||||
**How Social Login Works**
|
||||
|
||||
If your email is already registered, you will be logged in, and your social account will be linked.
|
||||
If your email is not registered, a new account will be created using your social account email.
|
||||
|
||||
</Note>
|
||||
<Note>
|
||||
**Enable Social Login**
|
||||
|
||||
See [how to configure Social Login for Prowler](/user-guide/tutorials/prowler-app-social-login) to enable this feature in your own deployments.
|
||||
|
||||
</Note>
|
||||
## **Step 2: Log In**
|
||||
|
||||
Once registered, log in with your email and password to access Prowler App.
|
||||
|
||||
<img src="/images/log-in.png" alt="Log In" width="350" />
|
||||
|
||||
Upon logging in, the Overview page will display. At this stage, no data is present: add a provider to begin scanning your cloud environment.
|
||||
|
||||
## **Step 3: Add a Provider**
|
||||
|
||||
To perform security scans, link a cloud provider account. Prowler supports the following providers and more:
|
||||
|
||||
- **AWS**
|
||||
|
||||
- **Azure**
|
||||
|
||||
- **Google Cloud Platform (GCP)**
|
||||
|
||||
- **Kubernetes**
|
||||
|
||||
- **M365**
|
||||
|
||||
- **GitHub**
|
||||
|
||||
Steps to add a provider:
|
||||
|
||||
1. Navigate to `Settings > Cloud Providers`.
|
||||
2. Click `Add Account` to set up a new provider and provide your credentials.
|
||||
|
||||
<img src="/images/add-provider.png" alt="Add Provider" width="700" />
|
||||
|
||||
## **Step 4: Configure the Provider**
|
||||
|
||||
Select the cloud provider you want to scan.
|
||||
|
||||
<img src="/images/select-provider.png" alt="Select a Provider" width="700" />
|
||||
|
||||
Once chosen, enter the Provider UID for authentication:
|
||||
|
||||
- **AWS**: Enter your AWS Account ID.
|
||||
- **GCP**: Enter your GCP Project ID.
|
||||
- **Azure**: Enter your Azure Subscription ID.
|
||||
- **Kubernetes**: Enter your Kubernetes Cluster context of your kubeconfig file.
|
||||
- **M365**: Enter your M365 Domain ID.
|
||||
|
||||
Optionally, provide a **Provider Alias** for easier identification. Follow the instructions provided to add your credentials:
|
||||
|
||||
### **Step 4.1: AWS Credentials**
|
||||
|
||||
For AWS, enter your `AWS Account ID` and choose one of the following methods to connect:
|
||||
|
||||
#### **Step 4.1.1: IAM Access Keys**
|
||||
|
||||
1. Select `Connect via Credentials`.
|
||||
|
||||
<img src="/images/connect-aws-credentials.png" alt="AWS Credentials" width="350" />
|
||||
|
||||
2. Enter your `Access Key ID`, `Secret Access Key` and optionally a `Session Token`:
|
||||
|
||||
<img src="/images/aws-credentials.png" alt="AWS Credentials" width="350" />
|
||||
|
||||
#### **Step 4.1.2: IAM Role**
|
||||
|
||||
1. Select `Connect assuming IAM Role`.
|
||||
|
||||
<img src="/images/connect-aws-role.png" alt="AWS Role" width="350" />
|
||||
|
||||
2. Enter the `Role ARN` and any optional field like the AWS Access Keys to assume the role, the `External ID`, the `Role Session Name` or the `Session Duration`:
|
||||
|
||||
<img src="/images/aws-role.png" alt="AWS Role" width="700" />
|
||||
|
||||
<Note>
|
||||
Check if your AWS Security Token Service (STS) has the EU (Ireland) endpoint active. If not, we will not be able to connect to your AWS account.
|
||||
|
||||
If that is the case your STS configuration may look like this:
|
||||
|
||||
<img src="/images/sts-configuration.png" alt="AWS Role" width="800" />
|
||||
|
||||
To solve this issue, please activate the EU (Ireland) STS endpoint.
|
||||
|
||||
</Note>
|
||||
### **Step 4.2: Azure Credentials**:
|
||||
|
||||
For Azure, Prowler App uses a service principal application to authenticate. For more information about the process of creating and adding permissions to a service principal refer to this [section](/user-guide/providers/azure/authentication). When you finish creating and adding the [Entra](/user-guide/providers/azure/create-prowler-service-principal#assigning-proper-permissions) and [Subscription](/user-guide/providers/azure/subscriptions) scope permissions to the service principal, enter the `Tenant ID`, `Client ID` and `Client Secret` of the service principal application.
|
||||
|
||||
<img src="/images/azure-credentials.png" alt="Azure Credentials" width="700" />
|
||||
|
||||
---
|
||||
### **Step 4.3: GCP Credentials**
|
||||
|
||||
For Google Cloud, first enter your `GCP Project ID` and then select the authentication method you want to use:
|
||||
|
||||
- **Service Account Authentication** (**Recommended**)
|
||||
- **Application Default Credentials**
|
||||
|
||||
**Service Account Authentication** is the recommended authentication method for automated systems and machine-to-machine interactions, like Prowler. For detailed information about this, refer to the [Google Cloud documentation](https://cloud.google.com/iam/docs/service-account-overview).
|
||||
|
||||
<img src="/images/prowler-app/gcp-auth-methods.png" alt="GCP Authentication Methods" width="700" />
|
||||
|
||||
#### **Step 4.3.1: Service Account Authentication**
|
||||
|
||||
First of all, in the same project that you selected in the previous step, you need to create a service account and then generate a key in JSON format for it. For more information about this, you can follow the next Google Cloud documentation tutorials:
|
||||
|
||||
- [Create a service account](https://cloud.google.com/iam/docs/creating-managing-service-accounts)
|
||||
- [Generate a key for a service account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
|
||||
|
||||
<img src="/images/prowler-app/gcp-service-account-creds.png" alt="GCP Service Account Credentials" width="700" />
|
||||
|
||||
#### **Step 4.3.2: Application Default Credentials**
|
||||
|
||||
1. Run the following command in your terminal to authenticate with GCP:
|
||||
|
||||
```bash
|
||||
gcloud auth application-default login
|
||||
```
|
||||
|
||||
2. Once authenticated, get the `Client ID`, `Client Secret` and `Refresh Token` from `~/.config/gcloud/application_default_credentials`.
|
||||
|
||||
3. Paste the `Client ID`, `Client Secret` and `Refresh Token` into Prowler App.
|
||||
|
||||
<img src="/images/gcp-credentials.png" alt="GCP Credentials" width="700" />
|
||||
|
||||
### **Step 4.4: Kubernetes Credentials**:
|
||||
|
||||
For Kubernetes, Prowler App uses a `kubeconfig` file to authenticate, paste the contents of your `kubeconfig` file into the `Kubeconfig content` field.
|
||||
|
||||
By default, the `kubeconfig` file is located at `~/.kube/config`.
|
||||
|
||||
<img src="/images/kubernetes-credentials.png" alt="Kubernetes Credentials" width="700" />
|
||||
|
||||
If you are adding an **EKS**, **GKE**, **AKS** or external cluster, follow these additional steps to ensure proper authentication:
|
||||
|
||||
**Make sure your cluster allow traffic from the Prowler Cloud IP address `52.48.254.174/32`**
|
||||
|
||||
1. Apply the necessary Kubernetes resources to your EKS, GKE, AKS or external cluster (you can find the files in the [`kubernetes` directory of the Prowler repository](https://github.com/prowler-cloud/prowler/tree/master/kubernetes)):
|
||||
|
||||
```console
|
||||
kubectl apply -f kubernetes/prowler-sa.yaml
|
||||
kubectl apply -f kubernetes/prowler-role.yaml
|
||||
kubectl apply -f kubernetes/prowler-rolebinding.yaml
|
||||
```
|
||||
|
||||
2. Generate a long-lived token for authentication:
|
||||
|
||||
```console
|
||||
kubectl create token prowler-sa -n prowler-ns --duration=0
|
||||
```
|
||||
|
||||
- **Security Note:** The `--duration=0` option generates a non-expiring token, which may pose a security risk if not managed properly. Users should decide on an appropriate expiration time based on their security policies. If a limited-time token is preferred, set `--duration=<TIME>` (e.g., `--duration=24h`).
|
||||
- **Important:** If the token expires, Prowler Cloud will no longer be able to authenticate with the cluster. In this case, you will need to generate a new token and **remove and re-add the provider in Prowler Cloud** with the updated `kubeconfig`.
|
||||
|
||||
3. Update your `kubeconfig` to use the ServiceAccount token:
|
||||
|
||||
```console
|
||||
kubectl config set-credentials prowler-sa --token=<SA_TOKEN>
|
||||
kubectl config set-context <CONTEXT_NAME> --user=prowler-sa
|
||||
```
|
||||
|
||||
Replace `<SA_TOKEN>` with the generated token and `<CONTEXT_NAME>` with your KubeConfig Context Name of your EKS, GKE or AKS cluster.
|
||||
|
||||
4. Now you can add the modified `kubeconfig` in Prowler Cloud. Then test the connection.
|
||||
|
||||
### **Step 4.5: M365 Credentials**
|
||||
For M365, you must enter your Domain ID and choose the authentication method you want to use:
|
||||
|
||||
- Service Principal Authentication (Recommended)
|
||||
|
||||
<Warning>
|
||||
User authentication with M365_USER and M365_PASSWORD is deprecated and will be removed.
|
||||
|
||||
</Warning>
|
||||
For full setup instructions and requirements, check the [Microsoft 365 provider requirements](/user-guide/providers/microsoft365/getting-started-m365).
|
||||
|
||||
<img src="/images/m365-credentials.png" alt="Prowler Cloud M365 Credentials" width="700" />
|
||||
|
||||
### **Step 4.6: GitHub Credentials**
|
||||
For GitHub, you must enter your Provider ID (username or organization name) and choose the authentication method you want to use:
|
||||
|
||||
- **Personal Access Token** (Recommended for individual users)
|
||||
- **OAuth App Token** (For applications requiring user consent)
|
||||
- **GitHub App** (Recommended for organizations and production use)
|
||||
|
||||
<Note>
|
||||
For full setup instructions and requirements, check the [GitHub provider requirements](/user-guide/providers/github/getting-started-github).
|
||||
|
||||
</Note>
|
||||
<img src="/images/prowler-app/github-auth-methods.png" alt="GitHub Authentication Methods" width="700" />
|
||||
|
||||
#### **Step 4.6.1: Personal Access Token**
|
||||
|
||||
Personal Access Tokens provide the simplest GitHub authentication method and support individual user authentication or testing scenarios.
|
||||
|
||||
- Select `Personal Access Token` and enter your `Personal Access Token`:
|
||||
|
||||
<img src="/images/prowler-app/github-pat-credentials.png" alt="GitHub Personal Access Token Credentials" width="700" />
|
||||
|
||||
<Note>
|
||||
For detailed instructions on creating a Personal Access Token and the exact permissions required, check the [GitHub Personal Access Token tutorial](/user-guide/providers/github/getting-started-github#1-personal-access-token-pat).
|
||||
|
||||
</Note>
|
||||
#### **Step 4.6.2: OAuth App Token**
|
||||
|
||||
OAuth Apps enable applications to act on behalf of users with explicit consent.
|
||||
|
||||
- Select `OAuth App Token` and enter your `OAuth App Token`:
|
||||
|
||||
<img src="/images/prowler-app/github-oauth-credentials.png" alt="GitHub OAuth App Credentials" width="700" />
|
||||
|
||||
<Note>
|
||||
To create an OAuth App, go to GitHub Settings → Developer settings → OAuth Apps → New OAuth App. You'll need to exchange an authorization code for an access token using the OAuth flow.
|
||||
|
||||
</Note>
|
||||
#### **Step 4.6.3: GitHub App**
|
||||
|
||||
GitHub Apps provide the recommended integration method for accessing multiple repositories or organizations.
|
||||
|
||||
- Select `GitHub App` and enter your `GitHub App ID` and `GitHub App Private Key`:
|
||||
|
||||
<img src="/images/prowler-app/github-app-credentials.png" alt="GitHub App Credentials" width="700" />
|
||||
|
||||
<Note>
|
||||
To create a GitHub App, go to GitHub Settings → Developer settings → GitHub Apps → New GitHub App. Configure the necessary permissions and generate a private key. Install the app to your account or organization and provide the App ID and private key content.
|
||||
|
||||
</Note>
|
||||
## **Step 5: Test Connection**
|
||||
|
||||
After adding your credentials of your cloud account, click the `Launch` button to verify that Prowler App can successfully connect to your provider:
|
||||
|
||||
<img src="/images/test-connection-button.png" alt="Test Connection" width="700" />
|
||||
|
||||
## **Step 6: Scan started**
|
||||
|
||||
After successfully adding and testing your credentials, Prowler will start scanning your cloud environment, click the `Go to Scans` button to see the progress:
|
||||
|
||||
<img src="/images/provider-added.png" alt="Start Now" width="700" />
|
||||
|
||||
<Note>
|
||||
Prowler will automatically scan all configured providers every **24 hours**, ensuring your cloud environment stays continuously monitored.
|
||||
|
||||
</Note>
|
||||
## **Step 7: Monitor Scan Progress**
|
||||
|
||||
Track the progress of your scan in the `Scans` section:
|
||||
|
||||
<img src="/images/scan-progress.png" alt="Scan Progress" width="700" />
|
||||
|
||||
|
||||
## **Step 8: Analyze the Findings**
|
||||
|
||||
While the scan is running, start exploring the findings in these sections:
|
||||
|
||||
- **Overview**: High-level summary of the scans.
|
||||
|
||||
<img src="/images/products/overview.png" alt="Overview" width="700" />
|
||||
|
||||
- **Compliance**: Insights into compliance status.
|
||||
|
||||
<img src="/images/compliance.png" alt="Compliance" width="700" />
|
||||
|
||||
- **Issues**: Types of issues detected.
|
||||
|
||||
<img src="/images/issues.png" alt="Issues" width="300" />
|
||||
|
||||
- **Browse All Findings**: Detailed list of findings detected, where you can filter by severity, service, and more.
|
||||
|
||||
<img src="/images/findings.png" alt="Findings" width="700" />
|
||||
|
||||
To view all `new` findings that have not been seen prior to this scan, click the `Delta` filter and select `new`. To view all `changed` findings that have had a status change (from `PASS` to `FAIL` for example), click the `Delta` filter and select `changed`.
|
||||
|
||||
## **Step 9: Download the Outputs**
|
||||
|
||||
Once a scan is complete, navigate to the Scan Jobs section to download the output files generated by Prowler:
|
||||
|
||||
<img src="/images/scan_jobs_section.png" alt="Scan Jobs section" width="700" />
|
||||
|
||||
You can download the output files generated by Prowler as a single `zip` file. This archive contains the CSV, JSON-OSCF, and HTML reports detailing the findings.
|
||||
|
||||
To download these files, click the **Download** button. This button becomes available only after the scan has finished.
|
||||
|
||||
<img src="/images/download_output.png" alt="Download output" width="700" />
|
||||
|
||||
The `zip` file unpacks into a folder named like `prowler-output-<provider_id>-<timestamp>`, which includes all of the above outputs. In the example below, you can see the `.csv`, .`json`, and `.html` reports alongside a subfolder for detailed compliance checks.
|
||||
|
||||
<img src="/images/output_folder.png" alt="Output folder" width="700" />
|
||||
|
||||
<Note>
|
||||
**API Note**
|
||||
|
||||
For more information about the API endpoint used by the UI to download the ZIP archive, refer to: [Prowler API Reference - Download Scan Output](https://api.prowler.com/api/v1/docs#tag/Scan/operation/scans_report_retrieve)
|
||||
|
||||
</Note>
|
||||
## **Step 10: Download specified compliance report**
|
||||
|
||||
Once your scan has finished, you don’t need to grab the entire ZIP—just pull down the specific compliance report you want:
|
||||
|
||||
- Navigate to the **Compliance** section of the UI.
|
||||
|
||||
<img src="/images/compliance_section.png" alt="Compliance section" width="700" />
|
||||
|
||||
- Find the Framework report you need.
|
||||
|
||||
- Click its **Download** icon to retrieve that report’s CSV file with all the detailed findings.
|
||||
|
||||
<img src="/images/compliance_download.png" alt="Download compliance output" width="700" />
|
||||
|
||||
<Note>
|
||||
**API Note**
|
||||
|
||||
To fetch a single compliance report via API, see the Retrieve compliance report as CSV endpoint in the Prowler API Reference.[Prowler API Reference - Retrieve compliance report as CSV](https://api.prowler.com/api/v1/docs#tag/Scan/operation/scans_compliance_retrieve)
|
||||
|
||||
</Note>
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 'Prowler Check Kreator'
|
||||
---
|
||||
|
||||
<Note>
|
||||
Currently, this tool is only available for creating checks for the AWS provider.
|
||||
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
If you are looking for a way to create new checks for all the supported providers, you can use [Prowler Studio](https://github.com/prowler-cloud/prowler-studio), it is an AI-powered toolkit for generating and managing security checks for Prowler (better version of the Check Kreator).
|
||||
|
||||
</Note>
|
||||
|
||||
## Introduction
|
||||
|
||||
**Prowler Check Kreator** is a utility designed to streamline the creation of new checks for Prowler. This tool generates all necessary files required to add a new check to the Prowler repository. Specifically, it creates:
|
||||
|
||||
- A dedicated folder for the check.
|
||||
- The main check script.
|
||||
- A metadata file with essential details.
|
||||
- A folder and file structure for testing the check.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the tool, execute the main script with the following command:
|
||||
|
||||
```bash
|
||||
python util/prowler_check_kreator/prowler_check_kreator.py <prowler_provider> <check_name>
|
||||
```
|
||||
|
||||
Parameters:
|
||||
|
||||
- `<prowler_provider>`: Currently only AWS is supported.
|
||||
- `<check_name>`: The name you wish to assign to the new check.
|
||||
|
||||
## AI integration
|
||||
|
||||
This tool optionally integrates AI to assist in generating the check code and metadata file content. When AI assistance is chosen, the tool uses [Gemini](https://gemini.google.com/) to produce preliminary code and metadata.
|
||||
|
||||
<Note>
|
||||
For this feature to work, you must have the library `google-generativeai` installed in your Python environment.
|
||||
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
AI-generated code and metadata might contain errors or require adjustments to align with specific Prowler requirements. Carefully review all AI-generated content before committing.
|
||||
|
||||
</Warning>
|
||||
|
||||
To enable AI assistance, simply confirm when prompted by the tool. Additionally, ensure that the `GEMINI_API_KEY` environment variable is set with a valid Gemini API key. For instructions on obtaining your API key, refer to the [Gemini documentation](https://ai.google.dev/gemini-api/docs/api-key).
|
||||
@@ -0,0 +1,256 @@
|
||||
# Check Mapping Prowler v4/v3 to v2
|
||||
|
||||
Prowler v3 and v4 introduce distinct identifiers while preserving the checks originally implemented in v2. This change was made because, in previous versions, check names were primarily derived from the CIS Benchmark for AWS. Starting with v3 and v4, all checks are independent of any security framework and have unique names and IDs.
|
||||
|
||||
For more details on the updated compliance implementation in Prowler v4 and v3, refer to the [Compliance](/user-guide/cli/tutorials/compliance) section.
|
||||
|
||||
```
|
||||
checks_v4_v3_to_v2_mapping = {
|
||||
"accessanalyzer_enabled_without_findings": "extra769",
|
||||
"account_maintain_current_contact_details": "check117",
|
||||
"account_security_contact_information_is_registered": "check118",
|
||||
"account_security_questions_are_registered_in_the_aws_account": "check115",
|
||||
"acm_certificates_expiration_check": "extra730",
|
||||
"acm_certificates_transparency_logs_enabled": "extra724",
|
||||
"apigateway_restapi_authorizers_enabled": "extra746",
|
||||
"apigateway_restapi_client_certificate_enabled": "extra743",
|
||||
"apigateway_restapi_public": "extra745",
|
||||
"apigateway_restapi_logging_enabled": "extra722",
|
||||
"apigateway_restapi_waf_acl_attached": "extra744",
|
||||
“apigatewayv2_api_access_logging_enabled": "extra7156",
|
||||
"apigatewayv2_api_authorizers_enabled": "extra7157",
|
||||
"appstream_fleet_default_internet_access_disabled": "extra7193",
|
||||
"appstream_fleet_maximum_session_duration": "extra7190",
|
||||
"appstream_fleet_session_disconnect_timeout": "extra7191",
|
||||
"appstream_fleet_session_idle_disconnect_timeout": "extra7192",
|
||||
"autoscaling_find_secrets_ec2_launch_configuration": "extra775",
|
||||
"awslambda_function_invoke_api_operations_cloudtrail_logging_enabled": "extra720",
|
||||
"awslambda_function_no_secrets_in_code": "extra760",
|
||||
"awslambda_function_no_secrets_in_variables": "extra759",
|
||||
"awslambda_function_not_publicly_accessible": "extra798",
|
||||
"awslambda_function_url_cors_policy": "extra7180",
|
||||
"awslambda_function_url_public": "extra7179",
|
||||
"awslambda_function_using_supported_runtimes": "extra762",
|
||||
"cloudformation_stack_outputs_find_secrets": "extra742",
|
||||
"cloudformation_stacks_termination_protection_enabled": "extra7154",
|
||||
"cloudfront_distributions_field_level_encryption_enabled": "extra767",
|
||||
"cloudfront_distributions_geo_restrictions_enabled": "extra732",
|
||||
"cloudfront_distributions_https_enabled": "extra738",
|
||||
"cloudfront_distributions_logging_enabled": "extra714",
|
||||
"cloudfront_distributions_using_deprecated_ssl_protocols": "extra791",
|
||||
"cloudfront_distributions_using_waf": "extra773",
|
||||
"cloudtrail_cloudwatch_logging_enabled": "check24",
|
||||
"cloudtrail_kms_encryption_enabled": "check27",
|
||||
"cloudtrail_log_file_validation_enabled": "check22",
|
||||
"cloudtrail_logs_s3_bucket_access_logging_enabled": "check26",
|
||||
"cloudtrail_logs_s3_bucket_is_not_publicly_accessible": "check23",
|
||||
"cloudtrail_multi_region_enabled": "check21",
|
||||
"cloudtrail_s3_dataevents_read_enabled": "extra7196",
|
||||
"cloudtrail_s3_dataevents_write_enabled": "extra725",
|
||||
"cloudwatch_changes_to_network_acls_alarm_configured": "check311",
|
||||
"cloudwatch_changes_to_network_gateways_alarm_configured": "check312",
|
||||
"cloudwatch_changes_to_network_route_tables_alarm_configured": "check313",
|
||||
"cloudwatch_changes_to_vpcs_alarm_configured": "check314",
|
||||
"cloudwatch_cross_account_sharing_disabled": "extra7144",
|
||||
"cloudwatch_log_group_kms_encryption_enabled": "extra7164",
|
||||
"cloudwatch_log_group_retention_policy_specific_days_enabled": "extra7162",
|
||||
"cloudwatch_log_metric_filter_and_alarm_for_aws_config_configuration_changes_enabled": "check39",
|
||||
"cloudwatch_log_metric_filter_and_alarm_for_cloudtrail_configuration_changes_enabled": "check35",
|
||||
"cloudwatch_log_metric_filter_authentication_failures": "check36",
|
||||
"cloudwatch_log_metric_filter_aws_organizations_changes": "extra7197",
|
||||
"cloudwatch_log_metric_filter_disable_or_scheduled_deletion_of_kms_cmk": "check37",
|
||||
"cloudwatch_log_metric_filter_for_s3_bucket_policy_changes": "check38",
|
||||
"cloudwatch_log_metric_filter_policy_changes": "check34",
|
||||
"cloudwatch_log_metric_filter_root_usage": "check33",
|
||||
"cloudwatch_log_metric_filter_security_group_changes": "check310",
|
||||
"cloudwatch_log_metric_filter_sign_in_without_mfa": "check32",
|
||||
"cloudwatch_log_metric_filter_unauthorized_api_calls": "check31",
|
||||
"codeartifact_packages_external_public_publishing_disabled": "extra7195",
|
||||
"codebuild_project_older_90_days": "extra7174",
|
||||
"codebuild_project_user_controlled_buildspec": "extra7175",
|
||||
"config_recorder_all_regions_enabled": "check25",
|
||||
"directoryservice_directory_log_forwarding_enabled": "extra7181",
|
||||
"directoryservice_directory_monitor_notifications": "extra7182",
|
||||
"directoryservice_directory_snapshots_limit": "extra7184",
|
||||
"directoryservice_ldap_certificate_expiration": "extra7183",
|
||||
"directoryservice_radius_server_security_protocol": "extra7188",
|
||||
"directoryservice_supported_mfa_radius_enabled": "extra7189",
|
||||
"dynamodb_accelerator_cluster_encryption_enabled": "extra7165",
|
||||
"dynamodb_tables_kms_cmk_encryption_enabled": "extra7128",
|
||||
"dynamodb_tables_pitr_enabled": "extra7151",
|
||||
"ec2_ami_public": "extra76",
|
||||
"ec2_ebs_default_encryption": "extra761",
|
||||
"ec2_ebs_public_snapshot": "extra72",
|
||||
"ec2_ebs_snapshots_encrypted": "extra740",
|
||||
"ec2_ebs_volume_encryption": "extra729",
|
||||
"ec2_elastic_ip_shodan": "extra7102",
|
||||
"ec2_elastic_ip_unassigned": "extra7146",
|
||||
"ec2_instance_imdsv2_enabled": "extra786",
|
||||
"ec2_instance_internet_facing_with_instance_profile": "extra770",
|
||||
"ec2_instance_managed_by_ssm": "extra7124",
|
||||
"ec2_instance_older_than_specific_days": "extra758",
|
||||
"ec2_instance_profile_attached": "check119",
|
||||
"ec2_instance_public_ip": "extra710",
|
||||
"ec2_instance_secrets_user_data": "extra741",
|
||||
"ec2_networkacl_allow_ingress_any_port": "extra7138",
|
||||
"ec2_networkacl_allow_ingress_tcp_port_22": "check45",
|
||||
"ec2_networkacl_allow_ingress_tcp_port_3389": "check46",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_all_ports": "extra748",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_any_port": "extra74",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_port_mongodb_27017_27018": "extra753",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_ftp_port_20_21": "extra7134",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_22": "check41",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_3389": "check42",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_cassandra_7199_9160_8888": "extra754",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_elasticsearch_kibana_9200_9300_5601": "extra779",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_kafka_9092": "extra7135",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_memcached_11211": "extra755",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_mysql_3306": "extra750",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_oracle_1521_2483": "extra749",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_postgres_5432": "extra751",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_redis_6379": "extra752",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_sql_server_1433_1434": "extra7137",
|
||||
"ec2_securitygroup_allow_ingress_from_internet_to_tcp_port_telnet_23": "extra7136",
|
||||
"ec2_securitygroup_allow_wide_open_public_ipv4": "extra778",
|
||||
"ec2_securitygroup_default_restrict_traffic": "check43",
|
||||
"ec2_securitygroup_from_launch_wizard": "extra7173",
|
||||
"ec2_securitygroup_not_used": "extra75",
|
||||
"ec2_securitygroup_with_many_ingress_egress_rules": "extra777",
|
||||
"ecr_repositories_lifecycle_policy_enabled": "extra7194",
|
||||
"ecr_repositories_not_publicly_accessible": "extra77",
|
||||
"ecr_repositories_scan_images_on_push_enabled": "extra765",
|
||||
"ecr_repositories_scan_vulnerabilities_in_latest_image": "extra776",
|
||||
"ecs_task_definitions_no_environment_secrets": "extra768",
|
||||
"efs_encryption_at_rest_enabled": "extra7161",
|
||||
"efs_have_backup_enabled": "extra7148",
|
||||
"efs_not_publicly_accessible": "extra7143",
|
||||
"eks_cluster_kms_cmk_encryption_in_secrets_enabled": "extra797",
|
||||
"eks_control_plane_endpoint_access_restricted": "extra796",
|
||||
"eks_control_plane_logging_all_types_enabled": "extra794",
|
||||
"eks_endpoints_not_publicly_accessible": "extra795",
|
||||
"elb_insecure_ssl_ciphers": "extra792",
|
||||
"elb_internet_facing": "extra79",
|
||||
"elb_logging_enabled": "extra717",
|
||||
"elb_ssl_listeners": "extra793",
|
||||
"elbv2_deletion_protection": "extra7150",
|
||||
"elbv2_desync_mitigation_mode": "extra7155",
|
||||
"elbv2_insecure_ssl_ciphers": "extra792",
|
||||
"elbv2_internet_facing": "extra79",
|
||||
"elbv2_listeners_underneath": "extra7158",
|
||||
"elbv2_logging_enabled": "extra717",
|
||||
"elbv2_ssl_listeners": "extra793",
|
||||
"elbv2_waf_acl_attached": "extra7129",
|
||||
"emr_cluster_account_public_block_enabled": "extra7178",
|
||||
"emr_cluster_master_nodes_no_public_ip": "extra7176",
|
||||
"emr_cluster_publicly_accesible": "extra7177",
|
||||
"glacier_vaults_policy_public_access": "extra7147",
|
||||
"glue_data_catalogs_connection_passwords_encryption_enabled": "extra7117",
|
||||
"glue_data_catalogs_metadata_encryption_enabled": "extra7116",
|
||||
"glue_database_connections_ssl_enabled": "extra7115",
|
||||
"glue_development_endpoints_cloudwatch_logs_encryption_enabled": "extra7119",
|
||||
"glue_development_endpoints_job_bookmark_encryption_enabled": "extra7121",
|
||||
"glue_development_endpoints_s3_encryption_enabled": "extra7114",
|
||||
"glue_etl_jobs_amazon_s3_encryption_enabled": "extra7118",
|
||||
"glue_etl_jobs_cloudwatch_logs_encryption_enabled": "extra7120",
|
||||
"glue_etl_jobs_job_bookmark_encryption_enabled": "extra7122",
|
||||
"guardduty_is_enabled": "extra713",
|
||||
"guardduty_no_high_severity_findings": "extra7139",
|
||||
"iam_administrator_access_with_mfa": "extra71",
|
||||
"iam_avoid_root_usage": "check11",
|
||||
"iam_check_saml_providers_sts": "extra733",
|
||||
"iam_customer_attached_policy_no_administrative_privileges": "subset of check122",
|
||||
"iam_customer_unattached_policy_no_administrative_privileges": "subset of check122",
|
||||
"iam_no_custom_policy_permissive_role_assumption": "extra7100",
|
||||
"iam_no_expired_server_certificates_stored": "extra7199",
|
||||
"iam_no_root_access_key": "check112",
|
||||
"iam_password_policy_expires_passwords_within_90_days_or_less": "check111",
|
||||
"iam_password_policy_lowercase": "check16",
|
||||
"iam_password_policy_minimum_length_14": "check19",
|
||||
"iam_password_policy_number": "check18",
|
||||
"iam_password_policy_reuse_24": "check110",
|
||||
"iam_password_policy_symbol": "check17",
|
||||
"iam_password_policy_uppercase": "check15",
|
||||
"iam_policy_allows_privilege_escalation": "extra7185",
|
||||
"iam_policy_attached_only_to_group_or_roles": "check116",
|
||||
"iam_root_hardware_mfa_enabled": "check114",
|
||||
"iam_root_mfa_enabled": "check113",
|
||||
"iam_rotate_access_key_90_days": "check14",
|
||||
"iam_support_role_created": "check120",
|
||||
"iam_user_accesskey_unused": "subset of check13,extra774,extra7198",
|
||||
"iam_user_console_access_unused": "subset of check13,extra774,extra7198",
|
||||
"iam_user_hardware_mfa_enabled": "extra7125",
|
||||
"iam_user_mfa_enabled_console_access": "check12",
|
||||
"iam_user_no_setup_initial_access_key": "check121",
|
||||
"iam_user_two_active_access_key": "extra7123",
|
||||
"iam_role_cross_service_confused_deputy_prevention": "extra7201",
|
||||
"kms_cmk_are_used": "extra7126",
|
||||
"kms_cmk_rotation_enabled": "check28",
|
||||
"kms_key_not_publicly_accessible": "extra736",
|
||||
"macie_is_enabled": "extra712",
|
||||
"opensearch_service_domains_audit_logging_enabled": "extra7101",
|
||||
"opensearch_service_domains_cloudwatch_logging_enabled": "extra715",
|
||||
"opensearch_service_domains_encryption_at_rest_enabled": "extra781",
|
||||
"opensearch_service_domains_https_communications_enforced": "extra783",
|
||||
"opensearch_service_domains_internal_user_database_enabled": "extra784",
|
||||
"opensearch_service_domains_node_to_node_encryption_enabled": "extra782",
|
||||
"opensearch_service_domains_not_publicly_accessible": "extra716",
|
||||
"opensearch_service_domains_updated_to_the_latest_service_software_version": "extra785",
|
||||
"opensearch_service_domains_use_cognito_authentication_for_kibana": "extra780",
|
||||
"rds_instance_backup_enabled": "extra739",
|
||||
"rds_instance_deletion_protection": "extra7113",
|
||||
"rds_instance_enhanced_monitoring_enabled": "extra7132",
|
||||
"rds_instance_integration_cloudwatch_logs": "extra747",
|
||||
"rds_instance_minor_version_upgrade_enabled": "extra7131",
|
||||
"rds_instance_multi_az": "extra7133",
|
||||
"rds_instance_no_public_access": "extra78",
|
||||
"rds_instance_storage_encrypted": "extra735",
|
||||
"rds_snapshots_public_access": "extra723",
|
||||
"redshift_cluster_audit_logging": "extra721",
|
||||
"redshift_cluster_automated_snapshot": "extra7149",
|
||||
"redshift_cluster_automatic_upgrades": "extra7160",
|
||||
"redshift_cluster_public_access": "extra711",
|
||||
"route53_domains_privacy_protection_enabled": "extra7152",
|
||||
"route53_domains_transferlock_enabled": "extra7153",
|
||||
"route53_public_hosted_zones_cloudwatch_logging_enabled": "extra719",
|
||||
"s3_account_level_public_access_blocks": "extra7186",
|
||||
"s3_bucket_acl_prohibited": "extra7172",
|
||||
"s3_bucket_default_encryption": "extra734",
|
||||
"s3_bucket_no_mfa_delete": "extra7200",
|
||||
"s3_bucket_object_versioning": "extra763",
|
||||
"s3_bucket_policy_public_write_access": "extra771",
|
||||
"s3_bucket_public_access": "extra73",
|
||||
"s3_bucket_secure_transport_policy": "extra764",
|
||||
"s3_bucket_server_access_logging_enabled": "extra718",
|
||||
"sagemaker_models_network_isolation_enabled": "extra7105",
|
||||
"sagemaker_models_vpc_settings_configured": "extra7106",
|
||||
"sagemaker_notebook_instance_encryption_enabled": "extra7112",
|
||||
"sagemaker_notebook_instance_root_access_disabled": "extra7103",
|
||||
"sagemaker_notebook_instance_vpc_settings_configured": "extra7104",
|
||||
"sagemaker_notebook_instance_without_direct_internet_access_configured": "extra7111",
|
||||
"sagemaker_training_jobs_intercontainer_encryption_enabled": "extra7107",
|
||||
"sagemaker_training_jobs_network_isolation_enabled": "extra7109",
|
||||
"sagemaker_training_jobs_volume_and_output_encryption_enabled": "extra7108",
|
||||
"sagemaker_training_jobs_vpc_settings_configured": "extra7110",
|
||||
"secretsmanager_automatic_rotation_enabled": "extra7163",
|
||||
"securityhub_enabled": "extra799",
|
||||
"shield_advanced_protection_in_associated_elastic_ips": "extra7166",
|
||||
"shield_advanced_protection_in_classic_load_balancers": "extra7171",
|
||||
"shield_advanced_protection_in_cloudfront_distributions": "extra7167",
|
||||
"shield_advanced_protection_in_global_accelerators": "extra7169",
|
||||
"shield_advanced_protection_in_internet_facing_load_balancers": "extra7170",
|
||||
"shield_advanced_protection_in_route53_hosted_zones": "extra7168",
|
||||
"sns_topics_kms_encryption_at_rest_enabled": "extra7130",
|
||||
"sns_topics_not_publicly_accessible": "extra731",
|
||||
"sqs_queues_not_publicly_accessible": "extra727",
|
||||
"sqs_queues_server_side_encryption_enabled": "extra728",
|
||||
"ssm_document_secrets": "extra7141",
|
||||
"ssm_documents_set_as_public": "extra7140",
|
||||
"ssm_managed_compliant_patching": "extra7127",
|
||||
"trustedadvisor_errors_and_warnings": "extra726",
|
||||
"vpc_endpoint_connections_trust_boundaries": "extra789",
|
||||
"vpc_endpoint_services_allowed_principals_trust_boundaries": "extra790",
|
||||
"vpc_flow_logs_enabled": "check29",
|
||||
"vpc_peering_routing_tables_with_least_privilege": "check44",
|
||||
"workspaces_volume_encryption_enabled": "extra7187",
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user