mirror of
https://github.com/prowler-cloud/prowler.git
synced 2026-10-12 22:44:14 +00:00
Merge master
This commit is contained in:
mintlify-bot committed
commit
aecac60c12
2428 files changed
+134745
-24745
No files matched your search
@@ -10,9 +10,9 @@ The tool, `aws_org_generator.py`, complements the [Bulk Provider Provisioning
|
||||
<Note>
|
||||
**Native AWS Organizations support is now available in Prowler Cloud.** You can onboard all accounts via the UI wizard — with automatic discovery, hierarchical tree selection, connection testing, and bulk scan launch — without any scripts or YAML files.
|
||||
|
||||
See [AWS Organizations in Prowler Cloud](/user-guide/tutorials/prowler-cloud-aws-organizations).
|
||||
See [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations) in Prowler Cloud.
|
||||
|
||||
The CLI-based tool below remains useful for self-hosted Prowler App and advanced automation scenarios.
|
||||
The CLI-based tool below remains useful for Prowler Local Server and advanced automation scenarios.
|
||||
</Note>
|
||||
|
||||
{/* TODO: Add screenshot of the tool in action */}
|
||||
@@ -33,9 +33,9 @@ The AWS Organizations Bulk Provisioning tool simplifies multi-account onboarding
|
||||
* Python 3.7 or higher
|
||||
* AWS credentials with Organizations read access
|
||||
* ProwlerRole (or custom role) deployed across all target accounts
|
||||
* Prowler API key (from Prowler Cloud or self-hosted Prowler App)
|
||||
* For self-hosted Prowler App, remember to [point to your API base URL](./bulk-provider-provisioning#custom-api-endpoints)
|
||||
* Learn how to create API keys: [Prowler App API Keys](../tutorials/prowler-app-api-keys)
|
||||
* Prowler API key (from Prowler Cloud or Prowler Local Server)
|
||||
* For Prowler Local Server, remember to [point to your API base URL](./bulk-provider-provisioning#custom-api-endpoints)
|
||||
* Learn how to create API keys: [Prowler Cloud API Keys](../tutorials/prowler-app-api-keys)
|
||||
|
||||
### Deploying ProwlerRole Across AWS Organizations
|
||||
|
||||
@@ -98,13 +98,13 @@ export PROWLER_API_KEY="pk_example-api-key"
|
||||
|
||||
To create an API key:
|
||||
|
||||
1. Log in to Prowler Cloud or Prowler App
|
||||
1. Log in to Prowler Cloud or Prowler Local Server
|
||||
2. Click **Profile** → **Account**
|
||||
3. Click **Create API Key**
|
||||
4. Provide a descriptive name and optionally set an expiration date
|
||||
5. Copy the generated API key (it will only be shown once)
|
||||
|
||||
For detailed instructions, see: [Prowler App API Keys](../tutorials/prowler-app-api-keys)
|
||||
For detailed instructions, see: [Prowler Cloud API Keys](../tutorials/prowler-app-api-keys)
|
||||
|
||||
## Basic Usage
|
||||
|
||||
@@ -273,6 +273,8 @@ python aws_org_generator.py \
|
||||
4. Deploy to all organizational units
|
||||
5. Use a unique external ID (e.g., `prowler-org-2024-abc123`)
|
||||
|
||||
Alternatively, deploy the same template as a **single stack** with `DeployStackSet=true` and `AWSOrganizationalUnitId` set to your root/OU ID — it creates the StackSet for you. See [Native CloudFormation StackSet Deployment](../providers/aws/organizations#native-cloudformation-stackset-deployment-recommended).
|
||||
|
||||
{/* TODO: Add screenshot of CloudFormation StackSets deployment */}
|
||||
</Step>
|
||||
|
||||
@@ -325,7 +327,7 @@ python aws_org_generator.py \
|
||||
</Step>
|
||||
|
||||
<Step title="Run Bulk Provisioning">
|
||||
Provision all accounts to Prowler Cloud or Prowler App:
|
||||
Provision all accounts to Prowler Cloud or Prowler Local Server:
|
||||
|
||||
```bash
|
||||
# Set Prowler API key
|
||||
@@ -488,7 +490,7 @@ grep "provider: aws" aws-org-accounts.yaml | wc -l
|
||||
<Card title="Bulk Provider Provisioning" icon="terminal" href="/user-guide/tutorials/bulk-provider-provisioning">
|
||||
Learn how to bulk provision providers in Prowler.
|
||||
</Card>
|
||||
<Card title="Prowler App" icon="pen-to-square" href="/user-guide/tutorials/prowler-app">
|
||||
<Card title="Prowler Cloud" icon="pen-to-square" href="/user-guide/tutorials/prowler-app">
|
||||
Detailed instructions on how to use Prowler.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -11,7 +11,7 @@ The tool is available in the Prowler repository at: [util/prowler-bulk-provision
|
||||
|
||||
## Overview
|
||||
|
||||
The Bulk Provider Provisioning tool automates the creation of cloud providers in Prowler App or Prowler Cloud by:
|
||||
The Bulk Provider Provisioning tool automates the creation of cloud providers in Prowler Cloud or Prowler Local Server by:
|
||||
|
||||
* Reading provider configurations from YAML files
|
||||
* Creating providers with appropriate authentication credentials
|
||||
@@ -27,9 +27,9 @@ The Bulk Provider Provisioning tool automates the creation of cloud providers in
|
||||
### Requirements
|
||||
|
||||
* Python 3.7 or higher
|
||||
* Prowler API key (from Prowler Cloud or self-hosted Prowler App)
|
||||
* For self-hosted Prowler App, remember to [point to your API base URL](#custom-api-endpoints)
|
||||
* Learn how to create API keys: [Prowler App API Keys](../tutorials/prowler-app-api-keys)
|
||||
* Prowler API key (from Prowler Cloud or Prowler Local Server)
|
||||
* For Prowler Local Server, remember to [point to your API base URL](#custom-api-endpoints)
|
||||
* Learn how to create API keys: [Prowler Cloud API Keys](../tutorials/prowler-app-api-keys)
|
||||
* Authentication credentials for target cloud providers
|
||||
|
||||
### Installation
|
||||
@@ -52,13 +52,13 @@ export PROWLER_API_KEY="pk_example-api-key"
|
||||
|
||||
To create an API key:
|
||||
|
||||
1. Log in to Prowler Cloud or Prowler App
|
||||
1. Log in to Prowler Cloud or Prowler Local Server
|
||||
2. Click **Profile** → **Account**
|
||||
3. Click **Create API Key**
|
||||
4. Provide a descriptive name and optionally set an expiration date
|
||||
5. Copy the generated API key (it will only be shown once)
|
||||
|
||||
For detailed instructions, see: [Prowler App API Keys](../tutorials/prowler-app-api-keys)
|
||||
For detailed instructions, see: [Prowler Cloud API Keys](../tutorials/prowler-app-api-keys)
|
||||
|
||||
## Configuration File Structure
|
||||
|
||||
@@ -262,7 +262,7 @@ python prowler_bulk_provisioning.py providers.yaml --concurrency 10
|
||||
|
||||
### Custom API Endpoints
|
||||
|
||||
For self-hosted Prowler App installations:
|
||||
For Prowler Local Server installations:
|
||||
|
||||
```bash
|
||||
python prowler_bulk_provisioning.py providers.yaml \
|
||||
|
||||
@@ -4,14 +4,17 @@ description: 'Create, manage, and revoke Prowler App API keys for automation, CI
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.13.0" />
|
||||
|
||||
API key authentication in Prowler App provides an alternative to JWT tokens and empowers automation, CI/CD pipelines, and third-party integrations. This guide explains how to create, manage, and safeguard API keys when working with the Prowler API.
|
||||
<AppliesTo />
|
||||
|
||||
API key authentication in Prowler Cloud provides an alternative to JWT tokens and empowers automation, CI/CD pipelines, and third-party integrations. This guide explains how to create, manage, and safeguard API keys when working with the Prowler API.
|
||||
|
||||
## API Key Advantages
|
||||
|
||||
- **Programmatic access:** Enables automated workflows and scripts to interact with Prowler App.
|
||||
- **Programmatic access:** Enables automated workflows and scripts to interact with Prowler Cloud.
|
||||
- **Long-lived authentication:** Allows optional expiration dates, with a default of 1 year.
|
||||
- **Granular control:** Supports multiple keys with distinct names and purposes.
|
||||
- **Secure automation:** Simplifies safe integration into CI/CD pipelines and infrastructure-as-code tooling.
|
||||
@@ -20,7 +23,7 @@ API key authentication in Prowler App provides an alternative to JWT tokens and
|
||||
|
||||
API keys provide a secure authentication mechanism for accessing the Prowler API:
|
||||
|
||||
1. API keys are created through Prowler App with a user-defined name and optional expiration date.
|
||||
1. API keys are created through Prowler Cloud with a user-defined name and optional expiration date.
|
||||
2. The full API key appears only once upon creation and cannot be retrieved later.
|
||||
3. Each API key consists of a prefix (visible in the interface) and an encrypted secret portion.
|
||||
4. Requests include the API key in the header as `Authorization: Api-Key <api-key>`.
|
||||
@@ -64,13 +67,13 @@ Creating, viewing, or managing API keys requires the **MANAGE_ACCOUNT** RBAC per
|
||||
|
||||
Without this permission, the API Keys section remains hidden. Access requests should be routed through the tenant administrator.
|
||||
|
||||
For more information about RBAC permissions, refer to the [Prowler App RBAC documentation](/user-guide/tutorials/prowler-app-rbac).
|
||||
For more information about RBAC permissions, refer to the [Prowler Cloud RBAC documentation](/user-guide/tutorials/prowler-app-rbac).
|
||||
|
||||
## Creating API Keys
|
||||
|
||||
Follow these steps to create an API key in Prowler App:
|
||||
Follow these steps to create an API key in Prowler Cloud:
|
||||
|
||||
1. Navigate to **Profile** → **Account** in Prowler App.
|
||||
1. Navigate to **Profile** → **Account** in Prowler Cloud.
|
||||
2. Select the **Create API Key** button.
|
||||
|
||||
|
||||
@@ -207,7 +210,7 @@ When using API keys in CI/CD pipelines:
|
||||
* Ensure the key has not been revoked by checking the Revoked column in the API Keys list.
|
||||
* Confirm that the key has not expired by reviewing the expiration date.
|
||||
* Confirm that the correct API key format is in use, including both prefix and secret portions.
|
||||
* Verify that the key prefix matches what is displayed in Prowler App.
|
||||
* Verify that the key prefix matches what is displayed in Prowler Cloud.
|
||||
|
||||
### API Key Not Working After Creation
|
||||
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Active Queries"
|
||||
sidebarTitle: "Active Queries"
|
||||
description: "Focus on the Attack Paths queries active in the environment: Prowler Cloud and Prowler Private Cloud record query results after each scan and hide confirmed-empty queries from the selector."
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx";
|
||||
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx";
|
||||
|
||||
<VersionBadge version="5.36.0" />
|
||||
|
||||
<SubscriptionBanner />
|
||||
|
||||
Active Queries extends the base [Attack Paths](/user-guide/tutorials/prowler-app-attack-paths) feature with capabilities that rely on managed scan infrastructure. This capability is available only in Prowler Cloud and Prowler Private Cloud.
|
||||
|
||||
## Focusing on Queries with Data
|
||||
|
||||
Running an Attack Paths query against a scan that contains no matching pattern returns an empty graph. Without automatic filtering, identifying the queries that apply to an account means opening each one and checking whether it produces a result. Running the RDS inventory query on an account with no RDS instances, for example, returns a "No data found" message.
|
||||
|
||||
|
||||
|
||||
Prowler Cloud removes that trial and error. At the end of each scan, Prowler Cloud records which built-in queries returned data. The query selector then hides the queries confirmed empty for the selected scan, so only the queries that surface a real path remain visible. Following the example above, the RDS inventory query no longer appears in the selector.
|
||||
|
||||
|
||||
|
||||
A query stays available whenever its result is not a confirmed empty graph:
|
||||
|
||||
- **Errored queries** remain listed. An error is not the same as an empty result and still requires investigation.
|
||||
- **Unknown queries** remain listed. Their result for the scan has not been recorded yet.
|
||||
- **Parameterized queries** remain listed. Their output depends on the input values provided at run time.
|
||||
|
||||
## Browsing the Full Query Catalog on Prowler Hub
|
||||
|
||||
The query selector shows the queries relevant to the selected scan, not the entire catalog. To review every built-in Attack Paths query, including the ones hidden for a given scan, browse the complete catalog on [Prowler Hub](https://hub.prowler.com).
|
||||
|
||||
Prowler Hub lists each query with its name, description, and the technique it detects, so security teams can plan coverage and understand detection scope without running a scan first.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- [Attack Paths](/user-guide/tutorials/prowler-app-attack-paths) - Run built-in and custom queries and explore the resulting graph.
|
||||
- [Attack Paths Queries](/developer-guide/attack-paths-queries) - Write and maintain openCypher queries in the Developer Guide.
|
||||
@@ -4,9 +4,12 @@ description: "Use graph-based analysis in Prowler App to detect privilege escala
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx";
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx";
|
||||
|
||||
<VersionBadge version="5.17.0" />
|
||||
|
||||
<AppliesTo />
|
||||
|
||||
Attack Paths analyzes relationships between cloud resources, permissions, and security findings to detect how privileges can be escalated and how misconfigurations can be exploited by threat actors.
|
||||
|
||||
By mapping these relationships as a graph, Attack Paths reveals risks that individual security checks cannot detect on their own, such as an IAM role that can escalate its own permissions, or a chain of policies that grants unintended access to sensitive resources.
|
||||
@@ -20,7 +23,7 @@ By mapping these relationships as a graph, Attack Paths reveals risks that indiv
|
||||
|
||||
The following prerequisites are required for Attack Paths:
|
||||
|
||||
- **An AWS provider is configured** with valid credentials in Prowler App. For setup instructions, see [Getting Started with AWS](/user-guide/providers/aws/getting-started-aws).
|
||||
- **An AWS provider is configured** with valid credentials in Prowler Cloud. For setup instructions, see [Getting Started with AWS](/user-guide/providers/aws/getting-started-aws).
|
||||
- **At least one scan has completed** on the configured AWS provider and produced graph data. Attack Paths scans run automatically alongside regular security scans, no separate configuration is required.
|
||||
|
||||
## How Attack Paths Scans Work
|
||||
@@ -92,6 +95,12 @@ To choose a query, click the dropdown and select from the available options. Eac
|
||||
|
||||
Once selected, a description panel appears below the dropdown with more context about the query.
|
||||
|
||||
<Note>
|
||||
In Prowler Cloud and Prowler Private Cloud, the query selector hides queries
|
||||
confirmed empty for the selected scan, so only queries that return data remain
|
||||
visible. See [Active Queries](/user-guide/tutorials/prowler-app-attack-paths-active-queries).
|
||||
</Note>
|
||||
|
||||
## Configuring Query Parameters
|
||||
|
||||
Some queries accept optional or required parameters to narrow the scope of the analysis. When a query has parameters, a form appears below the query description.
|
||||
@@ -175,112 +184,16 @@ RETURN r.name AS role_name, r.arn AS role_arn, p.arn AS trusted_service
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
### Working with List-Typed Properties
|
||||
### Graph Schema and Advanced Patterns
|
||||
|
||||
Some Cartography node properties carry a list of values, such as `action`, `resource`, `notaction`, and `notresource` on `AWSPolicyStatement` nodes, the algorithms on `KMSKey`, the container-definition lists on `ECSContainerDefinition`, and many others. The Attack Paths graph models each such property as a set of child item nodes connected to the parent by a typed edge. To read the values, traverse the edge; the parent does not carry the list as a single field.
|
||||
Custom queries traverse the same Cartography graph the built-in queries use. Node labels, relationships, and properties follow the upstream [Cartography AWS Schema](https://cartography-cncf.github.io/cartography/modules/aws/schema.html), enriched by Prowler with `ProwlerFinding` nodes linked through `HAS_FINDING`, `Internet` exposure nodes, and list-typed properties such as `action` and `resource` modeled as child item nodes.
|
||||
|
||||
The naming convention for any list-typed property on a parent label is:
|
||||
|
||||
- **Child label:** `<ParentLabel><PropertyPascal>Item`. Example: `AWSPolicyStatement.resource` resolves to `AWSPolicyStatementResourceItem`.
|
||||
- **Edge type:** `HAS_<PROPERTY_UPPER>`. Example: `resource` resolves to `HAS_RESOURCE`.
|
||||
- **Child property:** `value` for scalar lists (one string per list element). List-of-dict properties (rare; for example `SecretsManagerSecretVersion.tags`) carry the original dict keys as named fields on the child node.
|
||||
|
||||
To express "at least one item in the list satisfies a predicate", traverse the `HAS_*` edge in its own `MATCH` clause and apply the predicate in the attached `WHERE`. `RETURN DISTINCT` collapses duplicate parent rows produced when multiple child items satisfy the filter:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
|
||||
MATCH (stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
|
||||
WHERE toLower(a.value) STARTS WITH 's3:get'
|
||||
OR toLower(a.value) STARTS WITH 's3:list'
|
||||
RETURN DISTINCT stmt
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
To check whether every item in the list satisfies a predicate, count the counter-examples and require zero, together with a guard that ensures at least one item is attached. This is the one case where the pattern-comprehension form is the right tool:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement)
|
||||
WHERE size([
|
||||
(stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
|
||||
WHERE NOT toLower(a.value) STARTS WITH 's3:'
|
||||
| a
|
||||
]) = 0
|
||||
AND size([(stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem) | a]) > 0
|
||||
RETURN stmt
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
For the "is any item of this list a substring of a dynamic value" case, such as "does any resource pattern in this policy match a target role ARN", add the `HAS_*` traversal as its own `MATCH` and check the substring relationship between the item value and the dynamic node in `WHERE`:
|
||||
|
||||
```cypher
|
||||
MATCH (role:AWSRole)
|
||||
WHERE role.name = 'Admin'
|
||||
MATCH (principal:AWSPrincipal)-[:POLICY]->(:AWSPolicy)-[:STATEMENT]->(stmt:AWSPolicyStatement {effect: 'Allow'})
|
||||
MATCH (stmt)-[:HAS_RESOURCE]->(r:AWSPolicyStatementResourceItem)
|
||||
WHERE r.value = '*'
|
||||
OR r.value CONTAINS role.name
|
||||
OR role.arn CONTAINS r.value
|
||||
RETURN DISTINCT principal.arn AS principal, stmt, role
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
To return the list of values directly, collect them from the child items:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
|
||||
OPTIONAL MATCH (stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
|
||||
RETURN stmt, collect(a.value) AS actions
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
### Working with JSON-Encoded Properties
|
||||
|
||||
Some Cartography properties represent nested objects, most notably `condition` on `AWSPolicyStatement` and `S3PolicyStatement` nodes. In the Attack Paths graph, object-typed properties are stored as JSON-encoded strings to keep the schema portable across graph backends. The value looks like:
|
||||
|
||||
```
|
||||
'{"StringEquals":{"aws:SourceAccount":"123456789012"}}'
|
||||
```
|
||||
|
||||
There is no JSON parser available at query time, so use `CONTAINS` for substring checks against keys or known values:
|
||||
|
||||
```cypher
|
||||
MATCH (stmt:AWSPolicyStatement)
|
||||
WHERE stmt.effect = 'Allow'
|
||||
AND stmt.condition CONTAINS '"aws:SourceAccount"'
|
||||
RETURN stmt
|
||||
LIMIT 25
|
||||
```
|
||||
|
||||
When a query needs to inspect the structured members of a condition (for example, evaluate every operator and key), fetch the rows first and parse the JSON in application code. Cypher cannot navigate JSON object keys or values.
|
||||
|
||||
### Tips for Writing Queries
|
||||
|
||||
- Start small with `LIMIT` to inspect the shape of the data before broadening the pattern.
|
||||
- Traverse `HAS_*` edges to reach list-typed property values (for example `action`, `resource`). The parent node does not carry the list as a single field; see [Working with List-Typed Properties](#working-with-list-typed-properties) for the patterns.
|
||||
- On large scans, avoid broad disconnected patterns such as `MATCH (a:Label), (b:OtherLabel)`. Bind one side with a selective predicate first, and use `WITH DISTINCT` between expanding traversals when duplicates are possible.
|
||||
- Use `RETURN` projections (`RETURN n.name, n.region`) instead of returning whole nodes to keep responses compact.
|
||||
- Combine resource nodes with `ProwlerFinding` nodes via `HAS_FINDING` to correlate misconfigurations with the affected resources.
|
||||
- When a query times out or returns no rows, simplify the pattern step by step until the first variant runs successfully, then add constraints back.
|
||||
|
||||
### Cartography Schema Reference
|
||||
|
||||
Attack Paths graphs are populated by [Cartography](https://github.com/cartography-cncf/cartography), an open-source graph ingestion framework. The node labels, relationship types, and properties available in custom queries follow the upstream Cartography schema for the corresponding provider.
|
||||
|
||||
For the complete catalogue of node labels and relationships available in custom queries, refer to the official Cartography schema documentation:
|
||||
|
||||
- **AWS:** [Cartography AWS Schema](https://cartography-cncf.github.io/cartography/modules/aws/schema.html)
|
||||
|
||||
In addition to the upstream schema, Prowler enriches the graph with:
|
||||
|
||||
- **`ProwlerFinding`** nodes representing Prowler check results, linked to affected resources via `HAS_FINDING` relationships.
|
||||
- **`Internet`** nodes used to model exposure paths from the public internet to internal resources.
|
||||
- **List-typed properties** such as `action` or `resource` on `AWSPolicyStatement`, the algorithm lists on `KMSKey`, and similar lists on other node types are modeled as child item nodes linked by typed `HAS_*` edges. See [Working with List-Typed Properties](#working-with-list-typed-properties) for the read pattern.
|
||||
- **Object-typed properties** such as `condition` on `AWSPolicyStatement` are stored as JSON-encoded strings. See [Working with JSON-Encoded Properties](#working-with-json-encoded-properties) for the read pattern.
|
||||
For the complete reference, including the graph model, list-typed and JSON-encoded properties, performance guidance, and openCypher compatibility rules, see [Attack Paths Queries](/developer-guide/attack-paths-queries) in the Developer Guide.
|
||||
|
||||
<Note>
|
||||
AI assistants connected through Prowler MCP Server can fetch the exact
|
||||
Cartography schema for the active scan via the
|
||||
`prowler_app_get_attack_paths_cartography_schema` tool. This guarantees that
|
||||
`prowler_get_attack_paths_cartography_schema` tool. This guarantees that
|
||||
generated queries match the schema version pinned by the running Prowler
|
||||
release.
|
||||
</Note>
|
||||
@@ -424,10 +337,10 @@ Attack Paths capabilities are also available through the [Prowler MCP Server](/g
|
||||
|
||||
The following MCP tools are available for Attack Paths:
|
||||
|
||||
- **`prowler_app_list_attack_paths_scans`** - List and filter Attack Paths scans.
|
||||
- **`prowler_app_list_attack_paths_queries`** - Discover available queries for a completed scan.
|
||||
- **`prowler_app_run_attack_paths_query`** - Execute a query and retrieve graph results with nodes and relationships.
|
||||
- **`prowler_app_get_attack_paths_cartography_schema`** - Retrieve the Cartography graph schema for custom openCypher queries.
|
||||
- **`prowler_list_attack_paths_scans`** - List and filter Attack Paths scans.
|
||||
- **`prowler_list_attack_paths_queries`** - Discover available queries for a completed scan.
|
||||
- **`prowler_run_attack_paths_query`** - Execute a query and retrieve graph results with nodes and relationships.
|
||||
- **`prowler_get_attack_paths_cartography_schema`** - Retrieve the Cartography graph schema for custom openCypher queries.
|
||||
|
||||
### Example Questions
|
||||
|
||||
|
||||
@@ -4,9 +4,12 @@ description: 'Group security findings by check in Prowler App to cut noise, prio
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.23.0" />
|
||||
|
||||
<AppliesTo />
|
||||
|
||||
Finding Groups transforms security findings triage by grouping them by check instead of displaying a flat list. This dramatically reduces noise and enables faster, more effective prioritization.
|
||||
|
||||
## Triage Challenges with Flat Finding Lists
|
||||
@@ -112,7 +115,7 @@ This provides full context without leaving the drawer.
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. Navigate to the **Findings** section in Prowler Cloud/App.
|
||||
1. Navigate to the **Findings** section in Prowler Cloud.
|
||||
2. Toggle to the **Grouped View** to see findings organized by check.
|
||||
3. Select any group row to expand and see affected resources.
|
||||
4. Select a resource to open the detail drawer with full context.
|
||||
|
||||
@@ -113,7 +113,7 @@ Make sure the row is an individual finding row. Finding Groups rows do not show
|
||||
|
||||
### Changes cannot be saved
|
||||
|
||||
Confirm that the user role has **Manage Scans** permission. Self-hosted Prowler App does not support Findings Triage writes.
|
||||
Confirm that the user role has **Manage Scans** permission. Prowler Local Server does not support Findings Triage writes.
|
||||
|
||||
### Resolved or Reopened is missing from the selector
|
||||
|
||||
|
||||
@@ -3,14 +3,17 @@ title: "Prowler App Jira Integration"
|
||||
description: "Configure Prowler App's Jira integration to send security findings as work items with full remediation guidance and streamline security incident tracking."
|
||||
---
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.12.0" />
|
||||
|
||||
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.
|
||||
<AppliesTo />
|
||||
|
||||
Integrating Prowler App with Jira provides:
|
||||
Prowler Cloud 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.
|
||||
|
||||
* **Streamlined management:** Convert security findings directly into actionable Jira work items
|
||||
Integrating Prowler Cloud 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
|
||||
|
||||
@@ -18,14 +21,24 @@ Integrating Prowler App with Jira provides:
|
||||
|
||||
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.
|
||||
1. Select one or more complete Finding Groups, or expand a Finding Group and select multiple Findings, from the Findings table.
|
||||
2. Send the selection to Jira in one action.
|
||||
3. Choose how Jira issues are created:
|
||||
* **Grouped issue:** Create one Jira issue that contains all selected Findings from the Finding Group.
|
||||
* **Separate issues:** Create one Jira issue for each selected Finding. Each Finding represents one affected resource.
|
||||
4. Review the Finding Group summary and affected-resource details in Jira, then use the link at the bottom of the issue to open the complete Finding Group in Prowler Cloud.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
<VersionBadge version="5.36.0" />
|
||||
|
||||
Configuring and using the Jira integration requires the **Manage Integrations** permission. The Jira integration is tenant-wide, so it does not require **Unlimited Visibility** or any specific Provider Group. Findings sent to Jira are still limited to the providers the role can access.
|
||||
|
||||
## Configuration
|
||||
|
||||
To configure Jira integration in Prowler App:
|
||||
To configure Jira integration in Prowler Cloud:
|
||||
|
||||
1. Navigate to **Integrations** in the Prowler App interface
|
||||
1. Navigate to **Integrations** in Prowler Cloud
|
||||
2. Locate the **Jira** card and click **Manage**, then select **Add integration**
|
||||
|
||||
|
||||
@@ -43,16 +56,68 @@ To generate a Jira API token, visit: https://id.atlassian.com/manage-profile/sec
|
||||
|
||||
</Note>
|
||||
|
||||
Once configured successfully, the integration is ready to send findings to Jira.
|
||||
Once configured successfully, the integration is ready to send Findings to Jira.
|
||||
|
||||
## Sending Findings to Jira
|
||||
|
||||
### Manual Export
|
||||
Prowler Cloud can send a complete Finding Group or a selection of Findings within a group to Jira in one action.
|
||||
|
||||
To manually send individual findings to Jira:
|
||||
### Sending a Complete Finding Group
|
||||
|
||||
1. Navigate to the **Findings** section in Prowler App
|
||||
2. Select one finding you want to export
|
||||
<VersionBadge version="5.36.0" />
|
||||
|
||||
To send every Finding in a Finding Group:
|
||||
|
||||
1. Navigate to **Findings** in Prowler Cloud.
|
||||
2. Select one or more Finding Groups.
|
||||
3. Open the bulk actions menu and click **Send Finding Group to Jira**.
|
||||
|
||||
|
||||
|
||||
4. Select the Jira project and issue type.
|
||||
5. Choose an issue creation mode:
|
||||
* **Create one Jira issue for all selected Findings in this Finding Group:** Keeps the complete Finding Group in one Jira issue.
|
||||
* **Create separate Jira issues:** Creates one Jira issue per selected Finding so that each affected resource can be tracked independently.
|
||||
6. Click **Send to Jira**.
|
||||
|
||||
|
||||
|
||||
### Sending Multiple Findings from a Group
|
||||
|
||||
<VersionBadge version="5.36.0" />
|
||||
|
||||
To send only specific affected resources:
|
||||
|
||||
1. Expand a Finding Group.
|
||||
2. Select the Findings to send. Each Finding represents one affected resource.
|
||||
3. Open the bulk actions menu and click **Send Findings to Jira**.
|
||||
4. Select the Jira project, issue type, and grouped or separate issue creation mode.
|
||||
5. Click **Send to Jira**.
|
||||
|
||||
|
||||
|
||||
### Reviewing the Jira Issue
|
||||
|
||||
A grouped Jira issue starts with Finding Group summary information. This section identifies the check and provides context such as the check title and ID, severity, status, provider, service, number of affected failing resources, last-seen time, failure duration, and risk.
|
||||
|
||||
|
||||
|
||||
The affected-resources table lists the selected Findings included in the Jira issue. Each row represents an affected resource and includes the information needed to identify and triage it, such as resource and provider identifiers, provider, service, status, severity, region, last-seen time, failure duration, and triage status.
|
||||
|
||||
|
||||
|
||||
At the bottom of the affected-resources table, click **View this Finding Group in Prowler Cloud** to open the complete Finding Group in Prowler Cloud. The link opens the group, not only the Findings included in the Jira issue.
|
||||
|
||||
|
||||
|
||||
### Sending One Finding
|
||||
|
||||
<VersionBadge version="5.12.0" />
|
||||
|
||||
To manually send individual Findings to Jira:
|
||||
|
||||
1. Navigate to the **Findings** section in Prowler Cloud
|
||||
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**
|
||||
@@ -66,8 +131,8 @@ 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
|
||||
* **Connection Status:** Connected or Disconnected indicator
|
||||
* **Instance Information:** Jira domain and last checked timestamp
|
||||
|
||||
### Actions
|
||||
|
||||
@@ -86,7 +151,7 @@ Each Jira integration provides management actions through dedicated buttons:
|
||||
|
||||
Certain Jira issue types (such as Epic) may require mandatory custom fields that Prowler does not currently populate when creating work items. If a selected issue type enforces required fields beyond the standard set (e.g., "Team", "Epic Name"), the work item creation will fail.
|
||||
|
||||
To avoid this, select an issue type that does not require additional custom fields — **Task**, **Bug**, or **Story** typically work without restrictions. If unsure which issue types are available for a project, Prowler automatically fetches and displays them in the "Issue Type" selector when sending a finding.
|
||||
To avoid this, select an issue type that does not require additional custom fields — **Task**, **Bug**, or **Story** typically work without restrictions. If unsure which issue types are available for a project, Prowler automatically fetches and displays them in the "Issue Type" selector when sending a Finding.
|
||||
|
||||
<Note>
|
||||
Support for custom field mapping is planned for a future release.
|
||||
@@ -96,9 +161,9 @@ Support for custom field mapping is planned for a future release.
|
||||
|
||||
### 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
|
||||
* 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)
|
||||
|
||||
@@ -111,7 +176,7 @@ Replace `http://localhost:8080` with the base URL where your Prowler API is acce
|
||||
|
||||
1) Get an access token (replace email and password):
|
||||
|
||||
```
|
||||
```bash
|
||||
curl --location 'http://localhost:8080/api/v1/tokens' \
|
||||
--header 'Content-Type: application/vnd.api+json' \
|
||||
--header 'Accept: application/vnd.api+json' \
|
||||
@@ -128,7 +193,7 @@ curl --location 'http://localhost:8080/api/v1/tokens' \
|
||||
|
||||
2) List tasks filtered by the Jira task (`integration-jira`) using the access token:
|
||||
|
||||
```
|
||||
```bash
|
||||
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
|
||||
@@ -141,7 +206,7 @@ If you don't have `jq` installed, run the command without `| jq`.
|
||||
|
||||
3) Share the output so we can help. A typical result will look like:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"links": {
|
||||
"first": "https://api.dev.prowler.com/api/v1/tasks?page%5Bnumber%5D=1",
|
||||
@@ -210,5 +275,5 @@ If you don't have `jq` installed, run the command without `| jq`.
|
||||
|
||||
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.
|
||||
* "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.
|
||||
@@ -129,6 +129,25 @@ To connect a provider:
|
||||
3. Configure in Lighthouse AI:
|
||||
- **API Key**: OpenRouter API key
|
||||
- **Base URL**: `https://openrouter.ai/api/v1`
|
||||
|
||||
### Base URL Validation
|
||||
|
||||
To prevent server-side request forgery (SSRF), Prowler API validates the base URL before connecting to it:
|
||||
|
||||
- The URL must use HTTPS.
|
||||
- The host must resolve to a public IP address. Private, loopback, link-local, and cloud metadata addresses are rejected.
|
||||
|
||||
<Warning>
|
||||
This validation can break configurations that point to internal endpoints, such as a self-hosted Ollama server. This is intentional: it fixes a security issue where the Prowler API could be directed to internal services. Internal endpoints must now be allowed explicitly through `LIGHTHOUSE_AI_OPENAI_COMPATIBLE_ALLOWED_HOSTS`.
|
||||
</Warning>
|
||||
|
||||
To allow internal endpoints, set a comma-separated list of hostnames or IP addresses in the Prowler API environment (for Docker Compose deployments, the shared `.env` file):
|
||||
|
||||
```bash
|
||||
LIGHTHOUSE_AI_OPENAI_COMPATIBLE_ALLOWED_HOSTS=custom-openai.internal,10.0.0.20
|
||||
```
|
||||
|
||||
Hosts in this list skip the public-endpoint validation. HTTPS is still required, so the endpoint needs a certificate the Prowler API trusts.
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Behind the scenes, Lighthouse AI works as follows:
|
||||
- The agent accesses Prowler data through [Prowler MCP](https://docs.prowler.com/getting-started/products/prowler-mcp), which exposes tools from multiple sources, including:
|
||||
- Prowler Hub
|
||||
- Prowler Docs
|
||||
- Prowler App
|
||||
- Prowler Local Server
|
||||
- Instead of calling every tool directly, the agent uses two meta-tools:
|
||||
- `describe_tool` to retrieve a tool schema and parameter requirements.
|
||||
- `execute_tool` to run the selected tool with the required input.
|
||||
|
||||
@@ -4,10 +4,13 @@ description: 'Use Prowler App Organizations to isolate providers, scans, finding
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.23.0" />
|
||||
|
||||
Prowler App supports multi-tenancy through **Organizations**, allowing users to belong to multiple isolated environments within a single account. Each organization maintains its own providers, scans, findings, and user memberships, ensuring complete data separation between teams or business units.
|
||||
<AppliesTo />
|
||||
|
||||
Prowler Cloud supports multi-tenancy through **Organizations**, allowing users to belong to multiple isolated environments within a single account. Each organization maintains its own providers, scans, findings, and user memberships, ensuring complete data separation between teams or business units.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
@@ -129,7 +132,7 @@ When invited to join an organization, the invited user receives a link to accept
|
||||
|
||||
1. Open the invitation link.
|
||||
|
||||
2. If already authenticated, the invitation is accepted automatically and the user is redirected to Prowler App.
|
||||
2. If already authenticated, the invitation is accepted automatically and the user is redirected to Prowler Cloud.
|
||||
|
||||
3. If not authenticated, choose **I have an account -- Sign in**, authenticate with existing credentials, and the invitation is accepted upon sign-in.
|
||||
|
||||
|
||||
@@ -3,10 +3,13 @@ title: 'Advanced Mutelist (YAML) in Prowler App'
|
||||
description: 'Write YAML-based mutelist rules in Prowler App to mute findings across checks, regions, resources, and tags using regex patterns for complex environments.'
|
||||
---
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.9.0" />
|
||||
|
||||
Prowler App allows users to mute specific findings to focus on the most critical security issues. This guide demonstrates how to use the Advanced Mutelist feature with YAML configuration for complex, pattern-based muting rules.
|
||||
<AppliesTo />
|
||||
|
||||
Prowler Cloud allows users to mute specific findings to focus on the most critical security issues. This guide demonstrates how to use the Advanced Mutelist feature with YAML configuration for complex, pattern-based muting rules.
|
||||
|
||||
<Note>
|
||||
For muting individual findings without YAML configuration, use [Simple Mutelist](/user-guide/tutorials/prowler-app-simple-mutelist) to mute findings directly from the Findings table.
|
||||
@@ -32,8 +35,8 @@ Advanced Mutelist requires the **Manage Account** permission. See [RBAC Administ
|
||||
|
||||
Before muting findings, ensure:
|
||||
|
||||
- Valid access to Prowler App with appropriate permissions
|
||||
- A provider added to the Prowler App
|
||||
- Valid access to Prowler Cloud with appropriate permissions
|
||||
- A provider added to Prowler Cloud
|
||||
- Understanding of the security implications of muting specific findings
|
||||
|
||||
<Warning>
|
||||
@@ -44,7 +47,7 @@ Muting findings does not resolve underlying security issues. Review each finding
|
||||
|
||||
To configure Advanced Mutelist:
|
||||
|
||||
1. Log into Prowler App
|
||||
1. Log into Prowler Cloud
|
||||
2. Navigate to the Providers page
|
||||
|
||||
3. Connect a provider to enable Mutelist configuration
|
||||
@@ -164,7 +167,7 @@ Mutelist:
|
||||
- "*"
|
||||
Resources:
|
||||
- "app-vnet-peering-*"
|
||||
Description: "Mute App Function Vnet findings related with the reources pattern"
|
||||
Description: "Mute App Function Vnet findings related with the resources pattern"
|
||||
```
|
||||
|
||||
#### Azure Resource Group Muting
|
||||
@@ -424,7 +427,7 @@ Mutelist:
|
||||
|
||||
### Priority: Advanced vs. Simple Mutelist
|
||||
|
||||
When both Advanced Mutelist (YAML) and [Simple Mutelist](/user-guide/tutorials/prowler-app-simple-mutelist) rules match the same finding, the **Advanced Mutelist takes higher priority**. The finding will be muted with the reason "Muted by mutelist". If a finding is not matched by the Advanced Mutelist but matches a Simple Mutelist rule, the Simple rule's custom justification is used instead.
|
||||
When both Advanced Mutelist and [Simple Mutelist](/user-guide/tutorials/prowler-app-simple-mutelist) rules match the same finding, the **Advanced Mutelist takes higher priority**. The finding will be muted with the reason "Muted by mutelist". If a finding is not matched by the Advanced Mutelist but matches a Simple Mutelist rule, the Simple rule's custom justification is used instead.
|
||||
|
||||
### Best Practices
|
||||
|
||||
@@ -437,7 +440,7 @@ When both Advanced Mutelist (YAML) and [Simple Mutelist](/user-guide/tutorials/p
|
||||
|
||||
### Validation
|
||||
|
||||
Prowler App validates your mutelist configuration and will display errors for:
|
||||
Prowler Cloud validates the mutelist configuration and will display errors for:
|
||||
|
||||
- Invalid YAML syntax
|
||||
- Missing required fields
|
||||
|
||||
@@ -4,10 +4,13 @@ description: 'Invite users, assign roles, and configure Role-Based Access Contro
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.1.0" />
|
||||
|
||||
**Prowler App** supports multiple users within a single tenant, enabling seamless collaboration by allowing team members to easily share insights and manage security findings.
|
||||
<AppliesTo />
|
||||
|
||||
**Prowler Cloud** 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.
|
||||
|
||||
@@ -66,7 +69,7 @@ To remove **another** user from your organization, use the [_Expel from organiza
|
||||
#### Inviting Users
|
||||
|
||||
<Note>
|
||||
Please be aware that at this time, an email address can only be associated with a single Prowler account_.
|
||||
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:
|
||||
@@ -125,7 +128,7 @@ To resend the invitation to the user, it is necessary to explicitly **delete the
|
||||
|
||||
## 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.
|
||||
Roles combine administrative permissions with provider visibility. Administrative permissions control the actions a role can perform. Provider Groups and Unlimited Visibility control the providers, resources, findings, scans, compliance results, and integrations the role can access.
|
||||
|
||||
<Note>
|
||||
**Only users that have the _Manage Account_ or _admin_ permission can access this section.**
|
||||
@@ -133,47 +136,59 @@ The Roles section in Prowler is designed to facilitate the assignment of custom
|
||||
</Note>
|
||||
### Provider Groups
|
||||
|
||||
Provider Groups control visibility across specific providers. When creating a new role, you can assign specific groups to define their Provider visibility. This ensures that users with that role have access only to the Providers that are required.
|
||||
Provider Groups limit visibility to selected providers. Assigning one or more Provider Groups to a role grants access to the providers in those groups and their resources, findings, scans, and compliance results.
|
||||
|
||||
By default, a new user role does not have visibility into any group.
|
||||
New roles have no provider visibility by default. Assign at least one Provider Group or enable **Unlimited Visibility** before assigning the role to users who need access to provider data.
|
||||
|
||||
Alternatively, to grant the role unlimited visibility across all providers, check the Grant Unlimited Visibility checkbox.
|
||||
**Unlimited Visibility** grants organization-wide visibility across every provider, regardless of the Provider Groups assigned to the role. It does not grant administrative permissions.
|
||||
|
||||
#### Integration Visibility
|
||||
|
||||
<VersionBadge version="5.36.0" />
|
||||
|
||||
Integrations follow the visibility of the providers attached to them: a role can see an integration when it can access at least one of its providers, and only the providers visible to that role are listed on the integration. Editing or deleting an integration attached to providers outside the visibility of the role is not allowed. Integrations that are not attached to any provider, such as Jira, are tenant-wide and remain available to every role with the **Manage Integrations** permission.
|
||||
|
||||
#### Creating a Provider Group
|
||||
|
||||
Follow these steps to create a provider group in your account:
|
||||
|
||||
1. Navigate to **Provider Groups** from the side menu..
|
||||
1. Click **Providers** in the side menu.
|
||||
|
||||
2. In this view you can select the provider groups you want to assign to one or more roles.
|
||||
2. Select the **Provider Groups** tab.
|
||||
|
||||
3. Click the **Create Group** button on the center of the screen.
|
||||
3. Enter a group name in the **Create a new provider group** form.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group.png" alt="Create Provider Group" width="700" />
|
||||
4. Select the providers that the group controls. Optionally, select the roles that should use the group.
|
||||
|
||||
5. Click **Create Group**.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group.png" alt="Create a 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.
|
||||
1. Click **Providers** in the side menu and select the **Provider Groups** tab.
|
||||
|
||||
2. Click the edit button of the provider group you want to modify.
|
||||
2. Open the actions menu for the Provider Group and click **Edit Provider Group**.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit.png" alt="Edit Provider Group" width="700" />
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit.png" alt="Edit Provider Group action" width="300" />
|
||||
|
||||
3. Change the provider group parameters you need and save the changes.
|
||||
3. Update the group name, providers, or roles, and save the changes.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit_1.png" alt="Edit Provider Group Details" width="700" />
|
||||
<img src="/images/prowler-app/rbac/provider_group_edit_1.png" alt="Edit Provider Group form" width="700" />
|
||||
|
||||
#### Removing a Provider Group
|
||||
|
||||
Follow these steps to remove a provider group of your account:
|
||||
Follow these steps to remove a provider group from your account:
|
||||
|
||||
1. Navigate to **Provider Groups** from the side menu.
|
||||
1. Click **Providers** in the side menu and select the **Provider Groups** tab.
|
||||
|
||||
2. Click on the delete button of the provider group you want to remove.
|
||||
2. Open the actions menu for the Provider Group and click **Delete Provider Group**.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_remove.png" alt="Remove Provider Group" width="700" />
|
||||
3. Confirm the deletion.
|
||||
|
||||
<img src="/images/prowler-app/rbac/provider_group_remove.png" alt="Delete Provider Group confirmation" width="700" />
|
||||
|
||||
### Roles
|
||||
|
||||
@@ -183,19 +198,20 @@ 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.
|
||||
2. Click **Add Role**.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_create.png" alt="Create Role" width="700" />
|
||||
3. Enter the role name and select the required administrative permissions.
|
||||
|
||||
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.
|
||||
4. Configure **Visibility**:
|
||||
- To grant organization-wide visibility, select **Enable Unlimited Visibility for this role**.
|
||||
- To limit visibility, leave Unlimited Visibility cleared and select one or more Provider Groups.
|
||||
|
||||
<img src="/images/prowler-app/rbac/role_create_1.png" alt="Role parameters" width="700" />
|
||||
|
||||
5. Click **Add Role**.
|
||||
|
||||
<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.
|
||||
To grant read-only access across the organization, enable **Unlimited Visibility** without selecting administrative permissions. Then, assign the role from the **Users** page.
|
||||
|
||||
</Note>
|
||||
#### Editing a Role
|
||||
@@ -204,25 +220,21 @@ 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.
|
||||
2. Open the actions menu for the role and click **Edit Role**.
|
||||
|
||||
<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" />
|
||||
3. Update the role name, administrative permissions, Unlimited Visibility setting, or Provider Groups.
|
||||
|
||||
4. Save the changes.
|
||||
|
||||
#### Removing a Role
|
||||
|
||||
Follow these steps to remove a role of your account:
|
||||
Follow these steps to remove a role from 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" />
|
||||
2. Open the actions menu for the role and click **Delete Role**.
|
||||
|
||||
3. Confirm the deletion.
|
||||
|
||||
## RBAC Administrative Permissions
|
||||
|
||||
|
||||
@@ -4,10 +4,13 @@ description: 'Automatically export Prowler App scan results in CSV, HTML, and OC
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.10.0" />
|
||||
|
||||
**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.
|
||||
<AppliesTo />
|
||||
|
||||
**Prowler Cloud** 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:
|
||||
|
||||
@@ -202,7 +205,7 @@ Replace `<SOURCE ACCOUNT ID>` with the AWS account ID that contains the IAM role
|
||||
</Note>
|
||||
### Available Templates
|
||||
|
||||
**Prowler App** provides Infrastructure as Code (IaC) templates to automate IAM role setup with S3 integration permissions.
|
||||
**Prowler Cloud** 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.
|
||||
@@ -260,8 +263,8 @@ If using Prowler's CloudFormation template, execute the following command to upd
|
||||
- `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"
|
||||
5. In the "Configure stack options" screen, again, leave everything as it is and click "Next"
|
||||
6. Finally, under "Review Prowler", at the bottom click "Submit"
|
||||
|
||||
#### Terraform
|
||||
|
||||
@@ -279,7 +282,7 @@ If using Prowler's CloudFormation template, execute the following command to upd
|
||||
|
||||
3. Edit `terraform.tfvars` with your specific values:
|
||||
```hcl
|
||||
# Required: External ID from Prowler App
|
||||
# Required: External ID from Prowler Cloud
|
||||
external_id = "your-unique-external-id-here"
|
||||
|
||||
# S3 Integration Configuration
|
||||
@@ -311,11 +314,11 @@ For detailed information, refer to the [Terraform README](https://github.com/pro
|
||||
|
||||
## Configuration
|
||||
|
||||
Once the required permissions are set up, proceed to configure the S3 integration in **Prowler App**.
|
||||
Once the required permissions are set up, proceed to configure the S3 integration in **Prowler Cloud**.
|
||||
|
||||
1. Navigate to "Integrations"
|
||||
|
||||
2. Locate the Amazon S3 Integration card and click on the "Configure" button
|
||||
2. Locate the Amazon S3 Integration card and click the "Configure" button
|
||||
|
||||
3. Click the "Add Integration" button
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
|
||||
|
||||
<VersionBadge version="5.32.0" />
|
||||
|
||||
Scan Configuration lets you override, per provider, specific values in the default configuration Prowler's checks use during a scan. Each configuration modifies how specific checks behave, e.g.: thresholds, allowed values, retention windows, and you attach it to the providers that you want to use it on their next scan.
|
||||
Scan Configuration lets you override, per provider, specific values in the default configuration Prowler's checks use during a scan. Each configuration can modify how specific checks behave, such as thresholds, allowed values, and retention windows, or exclude checks and services from the scan scope. Attach it to the providers that should use it on their next scan.
|
||||
|
||||
<SubscriptionBanner />
|
||||
|
||||
@@ -54,6 +54,24 @@ gcp:
|
||||
storage_min_retention_days: 30
|
||||
```
|
||||
|
||||
### Limiting the Scan Scope
|
||||
|
||||
<VersionBadge version="5.35.0" />
|
||||
|
||||
Use `excluded_checks` to skip individual checks and `excluded_services` to skip every check in a service for the matching provider type:
|
||||
|
||||
```yaml
|
||||
aws:
|
||||
excluded_checks:
|
||||
- s3_bucket_public_access
|
||||
excluded_services:
|
||||
- ec2
|
||||
```
|
||||
|
||||
<Warning>
|
||||
When a Scan Configuration excludes checks or services, Prowler calculates overviews, aggregations, and other result-based information from the reduced scan scope. The displayed information reflects only the checks and services that ran, not a complete assessment of the provider. Consider the applied Scan Configuration when interpreting totals and security posture.
|
||||
</Warning>
|
||||
|
||||
## Creating a Scan Configuration
|
||||
|
||||
<Steps>
|
||||
|
||||
@@ -3,12 +3,15 @@ title: "Prowler App AWS Security Hub Integration"
|
||||
description: "Send Prowler App findings to AWS Security Hub to centralize multi-account visibility, automate archiving, filter by severity, and control ingestion costs."
|
||||
---
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.11.0" />
|
||||
|
||||
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.
|
||||
<AppliesTo />
|
||||
|
||||
Integrating Prowler App with AWS Security Hub provides:
|
||||
Prowler Cloud 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 Cloud 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
|
||||
@@ -31,7 +34,7 @@ Refer to [AWS Security Hub pricing](https://aws.amazon.com/security-hub/pricing/
|
||||
</Note>
|
||||
## Prerequisites
|
||||
|
||||
Before configuring AWS Security Hub Integration in Prowler App, complete these steps:
|
||||
Before configuring AWS Security Hub Integration in Prowler Cloud, complete these steps:
|
||||
|
||||
### AWS Security Hub Setup
|
||||
|
||||
@@ -43,9 +46,9 @@ Configure AWS credentials by following the [AWS authentication setup guide](/use
|
||||
|
||||
## Configuration
|
||||
|
||||
To configure AWS Security Hub integration in Prowler App:
|
||||
To configure AWS Security Hub integration in Prowler Cloud:
|
||||
|
||||
1. Navigate to **Integrations** in the Prowler App interface
|
||||
1. Navigate to **Integrations** in Prowler Cloud
|
||||
2. Locate the **AWS Security Hub** card and click **Manage**, then select **Add integration**
|
||||
|
||||
|
||||
|
||||
@@ -4,10 +4,13 @@ description: "Mute Prowler App findings individually or in bulk from the Finding
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx";
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx";
|
||||
|
||||
<VersionBadge version="5.16.0" />
|
||||
|
||||
Prowler App provides Simple Mutelist, an intuitive way to mute findings directly from the Findings page without writing YAML configuration. This feature streamlines the muting workflow by allowing individual or bulk muting with just a few clicks.
|
||||
<AppliesTo />
|
||||
|
||||
Prowler Cloud provides Simple Mutelist, an intuitive way to mute findings directly from the Findings page without writing YAML configuration. This feature streamlines the muting workflow by allowing individual or bulk muting with just a few clicks.
|
||||
|
||||
## What Is Simple Mutelist?
|
||||
|
||||
|
||||
@@ -4,10 +4,13 @@ description: 'Enable Google and GitHub OAuth authentication in Prowler App by co
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<VersionBadge version="5.5.0" />
|
||||
|
||||
**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.
|
||||
<AppliesTo />
|
||||
|
||||
Prowler supports social login using Google and GitHub OAuth providers. In **Prowler Cloud** social login is available out of the box. In **Prowler Local Server**, enable it by configuring the environment variables described in this guide.
|
||||
|
||||
<img src="/images/prowler-app/social-login/social_login_buttons.png" alt="Social login buttons" width="700" />
|
||||
## Configuring Social Login Credentials
|
||||
|
||||
@@ -3,7 +3,11 @@ title: 'SAML SSO with Microsoft Entra ID'
|
||||
description: 'Create and configure a Microsoft Entra ID (Azure AD) enterprise application to enable SAML Single Sign-On for Prowler App users across your organization.'
|
||||
---
|
||||
|
||||
This page provides instructions for creating and configuring a Microsoft Entra ID (formerly Azure AD) application to use SAML SSO with Prowler App.
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<AppliesTo />
|
||||
|
||||
This page provides instructions for creating and configuring a Microsoft Entra ID (formerly Azure AD) application to use SAML SSO with Prowler Cloud.
|
||||
|
||||
You can find a walkthrough video [here](https://www.youtube.com/watch?v=zegqm55oJVk).
|
||||
|
||||
@@ -29,7 +33,7 @@ You can find a walkthrough video [here](https://www.youtube.com/watch?v=zegqm55o
|
||||
|
||||
|
||||
|
||||
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.
|
||||
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 Cloud. For detailed instructions, refer to the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso) page.
|
||||
|
||||
|
||||
|
||||
@@ -45,4 +49,4 @@ You can find a walkthrough video [here](https://www.youtube.com/watch?v=zegqm55o
|
||||
|
||||
|
||||
|
||||
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).
|
||||
10. Save the downloaded Metadata XML to a file. To complete the setup, upload this file during the SAML SSO integration setup in Prowler Cloud. (See the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso) page for details).
|
||||
@@ -3,20 +3,25 @@ title: 'SAML SSO with Google Workspace'
|
||||
description: 'Set up a custom SAML app in Google Admin Console and pair it with Prowler App to give Google Workspace users Single Sign-On access to your organization.'
|
||||
---
|
||||
|
||||
This page explains how to configure SAML-based Single Sign-On (SSO) in Prowler App using **Google Workspace** as the Identity Provider (IdP). The setup is divided into two parts: create a custom SAML app in Google Admin Console, then complete the configuration in Prowler App.
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
|
||||
<AppliesTo />
|
||||
|
||||
This page explains how to configure SAML-based Single Sign-On (SSO) in Prowler Cloud using **Google Workspace** as the Identity Provider (IdP). The setup is divided into two parts: create a custom SAML app in Google Admin Console, then complete the configuration in Prowler Cloud.
|
||||
|
||||
<Info>
|
||||
**Parallel Setup Required**
|
||||
|
||||
Google Admin Console requires the ACS URL and Entity ID from Prowler App, while Prowler App displays these values only after opening the SAML configuration dialog. To work around this, open Prowler App in a separate browser tab, navigate to the profile page, open the "Configure SAML SSO" dialog, and copy the ACS URL and Entity ID before proceeding with the Google configuration.
|
||||
Google Admin Console requires the ACS URL and Entity ID from Prowler Cloud, while Prowler Cloud displays these values only after opening the SAML configuration dialog. To work around this, open Prowler Cloud in a separate browser tab, navigate to the profile page, open the "Configure SAML SSO" dialog, and copy the ACS URL and Entity ID before proceeding with the Google configuration.
|
||||
|
||||
</Info>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Google Workspace**: Super Admin access (or delegated admin with app management permissions).
|
||||
- **Prowler App**: Administrator access to the organization (role with "Manage Account" permission).
|
||||
- Prowler App version **5.9.0** or later.
|
||||
- **Prowler Cloud**: Administrator access to the organization (role with "Manage Account" permission).
|
||||
- Prowler version **5.9.0** or later.
|
||||
|
||||
---
|
||||
|
||||
@@ -45,7 +50,7 @@ On the **Google Identity Provider details** screen:
|
||||
1. Google displays two options:
|
||||
- **Option 1**: Click "Download Metadata" to save the XML file directly. This is the recommended approach.
|
||||
- **Option 2**: Manually copy the **SSO URL**, **Entity ID**, and **Certificate**.
|
||||
2. Download the metadata. This file is required to complete the Prowler App configuration in Part B.
|
||||
2. Download the metadata. This file is required to complete the configuration in Prowler Cloud (Part B).
|
||||
3. Click "Continue".
|
||||
|
||||
|
||||
@@ -53,18 +58,18 @@ On the **Google Identity Provider details** screen:
|
||||
<Warning>
|
||||
**Save the Metadata File**
|
||||
|
||||
Download and save the IdP metadata XML file before proceeding. This file cannot be easily retrieved later and is required to complete the SAML configuration in Prowler App.
|
||||
Download and save the IdP metadata XML file before proceeding. This file cannot be easily retrieved later and is required to complete the SAML configuration in Prowler Cloud.
|
||||
|
||||
</Warning>
|
||||
|
||||
### Step 4: Configure the Service Provider Details
|
||||
|
||||
Enter the following values obtained from the SAML SSO configuration dialog in Prowler App (see [Part B, Step 1](#step-1-open-the-saml-configuration-dialog) for details on where to find them):
|
||||
Enter the following values obtained from the SAML SSO configuration dialog in Prowler Cloud (see [Part B, Step 1](#step-1-open-the-saml-configuration-dialog) for details on where to find them):
|
||||
|
||||
| Google Workspace Field | Value |
|
||||
|------------------------|-------|
|
||||
| **ACS URL** | The Assertion Consumer Service (ACS) URL displayed in Prowler App (e.g., `https://api.prowler.com/api/v1/accounts/saml/your-domain.com/acs/`). Self-hosted deployments use a different base URL. |
|
||||
| **Entity ID** | The Audience URI displayed in Prowler App (e.g., `urn:prowler.com:sp`). |
|
||||
| **ACS URL** | The Assertion Consumer Service (ACS) URL displayed in Prowler Cloud (e.g., `https://api.prowler.com/api/v1/accounts/saml/your-domain.com/acs/`). Prowler Local Server deployments use a different base URL. |
|
||||
| **Entity ID** | The Audience URI displayed in Prowler Cloud (e.g., `urn:prowler.com:sp`). |
|
||||
| **Name ID format** | Select `EMAIL` from the dropdown. |
|
||||
| **Name ID** | Select `Basic Information > Primary email` from the dropdown. |
|
||||
|
||||
@@ -83,7 +88,7 @@ Click "Add mapping" for each entry:
|
||||
| `Basic Information > First name` | `firstName` | Yes | |
|
||||
| `Basic Information > Last name` | `lastName` | Yes | |
|
||||
| `Employee Details > Department` | `userType` | No | Determines the Prowler role. **Case-sensitive.** |
|
||||
| `Employee Details > Organization` | `organization` | No | Company name displayed in Prowler App profile. |
|
||||
| `Employee Details > Organization` | `organization` | No | Company name displayed in the user profile in Prowler Cloud. |
|
||||
|
||||
<Info>
|
||||
**Remember the Mapped Fields**
|
||||
@@ -99,7 +104,7 @@ Click "Finish" to create the SAML app.
|
||||
<Info>
|
||||
**Dynamic Updates**
|
||||
|
||||
Prowler App updates user attributes each time a user logs in. Any changes made in Google Workspace are reflected on the next login.
|
||||
Prowler Cloud updates user attributes each time a user logs in. Any changes made in Google Workspace are reflected on the next login.
|
||||
|
||||
</Info>
|
||||
|
||||
@@ -109,8 +114,13 @@ Prowler App updates user attributes each time a user logs in. Any changes made i
|
||||
The `userType` attribute controls which Prowler role is assigned to the user:
|
||||
|
||||
- If `userType` matches an existing Prowler role name, the user receives that role automatically.
|
||||
- If `userType` does not match any existing role, Prowler App creates a new role with that name **with read-only access** (visibility over all providers, no management permissions). A Prowler administrator can adjust its permissions afterward through the [RBAC Management](/user-guide/tutorials/prowler-app-rbac) tab.
|
||||
- If `userType` is not set, the user's existing roles are left unchanged.
|
||||
- If `userType` does not match any existing role, Prowler Cloud creates a new role with that name **with read-only access** (visibility over all providers, no management permissions). A Prowler administrator can adjust its permissions afterward through the [RBAC Management](/user-guide/tutorials/prowler-app-rbac) tab.
|
||||
|
||||
**Fallback Role Without `userType`**
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
If `userType` is not set, the user's existing roles are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role until a Prowler administrator assigns another role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name.
|
||||
|
||||
The `userType` value is **case-sensitive** - for example, `Backend` and `backend` are treated as different roles.
|
||||
|
||||
@@ -149,13 +159,13 @@ If attempting to use the "Test SAML login" option in Google Admin Console and re
|
||||
|
||||
---
|
||||
|
||||
## Part B - Prowler App Configuration
|
||||
## Part B - Prowler Cloud Configuration
|
||||
|
||||
### Step 1: Open the SAML Configuration Dialog
|
||||
|
||||
1. Navigate to the profile settings page:
|
||||
- **Prowler Cloud**: `https://cloud.prowler.com/profile`
|
||||
- **Self-hosted**: `http://{your-domain}/profile`
|
||||
- **Prowler Local Server**: `http://{your-domain}/profile`
|
||||
2. Find the "SAML SSO Integration" card and click "Enable" (or "Update" if already configured).
|
||||
3. The "Configure SAML SSO" dialog opens, displaying:
|
||||
- **ACS URL**: The Assertion Consumer Service URL (copy this value for Part A, Step 4). This URL updates dynamically when the email domain is entered.
|
||||
@@ -163,21 +173,21 @@ If attempting to use the "Test SAML login" option in Google Admin Console and re
|
||||
- **Name ID Format**: The expected format (`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`).
|
||||
- **Supported Assertion Attributes**: The list of accepted attributes (`firstName`, `lastName`, `userType`, `organization`).
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 2: Enter the Email Domain and Upload Metadata
|
||||
|
||||
1. Enter the **email domain** for the organization (e.g., `prowler.cloud`). Prowler App uses this domain to identify users who should authenticate via SAML. The ACS URL updates automatically to reflect the configured domain.
|
||||
1. Enter the **email domain** for the organization (e.g., `prowler.cloud`). Prowler Cloud uses this domain to identify users who should authenticate via SAML. The ACS URL updates automatically to reflect the configured domain.
|
||||
2. Upload the **metadata XML file** downloaded in Part A, Step 3.
|
||||
3. Click "Save".
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 3: Verify the Enabled Status
|
||||
|
||||
The "SAML SSO Integration" card should now display a **"Status: Enabled"** indicator with a checkmark, confirming that the configuration is complete.
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -215,13 +225,13 @@ To test the `userType` → role mapping, set the **Department** attribute in the
|
||||
1. Navigate to the Prowler login page.
|
||||
2. Click "Continue with SAML SSO".
|
||||
3. Enter an email from the configured domain (e.g., `adrian@prowler.cloud`).
|
||||
4. Click "Log in". The browser redirects to Google for authentication and returns to Prowler App upon success.
|
||||
4. Click "Log in". The browser redirects to Google for authentication and returns to Prowler Cloud upon success.
|
||||
|
||||
|
||||
|
||||
|
||||
### Verify User Profile and Role Mapping
|
||||
|
||||
After a successful SSO login, the user profile in Prowler App reflects the attributes sent by Google Workspace:
|
||||
After a successful SSO login, the user profile in Prowler Cloud reflects the attributes sent by Google Workspace:
|
||||
|
||||
- **Name**: Populated from the `firstName` and `lastName` attributes.
|
||||
- **Role**: Created automatically from the `userType` attribute (e.g., `Backend`). If the role did not exist previously, it is created with read-only access by default.
|
||||
@@ -231,14 +241,14 @@ After a successful SSO login, the user profile in Prowler App reflects the attri
|
||||
|
||||
For more details on role assignment behavior and attribute mapping, refer to the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso#configure-attribute-mapping-in-the-idp) page.
|
||||
|
||||
|
||||
|
||||
|
||||
### IdP-Initiated SSO (from Google)
|
||||
|
||||
1. Sign in to Google Workspace with an account that has access to the Prowler SAML app.
|
||||
2. Open the Google Workspace app launcher (the grid icon in the top-right corner of any Google page).
|
||||
3. Click the Prowler app tile.
|
||||
4. The browser redirects directly to Prowler App, authenticated.
|
||||
3. Click the Prowler tile.
|
||||
4. The browser redirects directly to Prowler Cloud, authenticated.
|
||||
|
||||
For more information on the SSO login flows, refer to the [SAML SSO Configuration](/user-guide/tutorials/prowler-app-sso#idp-initiated-sso) page.
|
||||
|
||||
@@ -271,7 +281,7 @@ Prowler does not allow two tenants to share the same email domain. If the domain
|
||||
<Info>
|
||||
**Just-in-Time Provisioning**
|
||||
|
||||
Users who authenticate via SAML for the first time are automatically created in Prowler App. No prior invitation is needed. User attributes (`firstName`, `lastName`, `userType`) are updated on every login from the Google directory.
|
||||
Users who authenticate via SAML for the first time are automatically created in Prowler Cloud. No prior invitation is needed. User attributes (`firstName`, `lastName`, `userType`) are updated on every login from the Google directory.
|
||||
|
||||
</Info>
|
||||
|
||||
@@ -279,10 +289,10 @@ Users who authenticate via SAML for the first time are automatically created in
|
||||
|
||||
## Quick Summary
|
||||
|
||||
1. In **Google Admin Console**, create a custom SAML app using the ACS URL and Entity ID from Prowler App.
|
||||
1. In **Google Admin Console**, create a custom SAML app using the ACS URL and Entity ID from Prowler Cloud.
|
||||
2. Configure **attribute mapping**: `firstName`, `lastName`, and optionally `userType` and `organization`.
|
||||
3. **Download the metadata XML** from Google.
|
||||
4. **Enable the app** in Google Workspace for the relevant users or groups.
|
||||
5. In **Prowler App**, enter the email domain, upload the metadata XML, and save.
|
||||
5. In **Prowler Cloud**, enter the email domain, upload the metadata XML, and save.
|
||||
6. Verify the SAML SSO Integration shows **"Status: Enabled"**.
|
||||
7. Test login via "Continue with SAML SSO" on the Prowler login page.
|
||||
@@ -4,16 +4,20 @@ description: 'Configure SAML-based Single Sign-On in Prowler App with any Identi
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { AppliesTo } from "/snippets/applies-to.mdx"
|
||||
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
|
||||
|
||||
<VersionBadge version="5.9.0" />
|
||||
|
||||
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).
|
||||
<AppliesTo />
|
||||
|
||||
This guide provides comprehensive instructions to configure SAML-based Single Sign-On (SSO) in Prowler Cloud. This configuration allows users to authenticate using the organization's Identity Provider (IdP).
|
||||
|
||||
This document is divided into two main sections:
|
||||
|
||||
- **[User Guide](#user-guide-configuration)**: For organization administrators to configure SAML SSO through Prowler App.
|
||||
- **[User Guide](#user-guide-configuration)**: For organization administrators to configure SAML SSO through Prowler Cloud.
|
||||
|
||||
- **[Developer and Administrator Guide](#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.
|
||||
- **[Developer and Administrator Guide](#developer-and-administrator-guide)**: For developers and system administrators running Prowler Local Server instances, providing technical details on environment configuration, API usage, and testing.
|
||||
|
||||
---
|
||||
|
||||
@@ -44,7 +48,7 @@ If the SAML configuration is removed, users who previously authenticated via SAM
|
||||
|
||||
#### 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).
|
||||
To access the account settings, click the "Account" button in the top-right corner of Prowler Cloud, or navigate directly to `https://cloud.prowler.com/profile` (or `http://localhost:3000/profile` for local setups).
|
||||
|
||||
|
||||
|
||||
@@ -64,12 +68,12 @@ Choose a Method:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Generic Method">
|
||||
Prowler App displays the SAML configuration information needed to configure the IdP. Use this information to create a new SAML application in the IdP.
|
||||
Prowler Cloud 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.
|
||||
To configure the IdP, copy the **ACS URL** and **Audience URI** from Prowler Cloud and use them to set up a new SAML application.
|
||||
|
||||
|
||||
|
||||
@@ -82,15 +86,21 @@ Choose a Method:
|
||||
|
||||
**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:
|
||||
For Prowler Cloud 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` | Determines which Prowler role the user receives (e.g., `admin`, `auditor`). If a role with that name already exists, the user receives it automatically; if it does not exist, Prowler App creates a new role with that name with read-only access (visibility over all providers, no management permissions). If `userType` is not defined, the user's existing roles are left unchanged. Role permissions can be edited in the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac). | No |
|
||||
| `userType` | Determines which Prowler role the user receives (e.g., `admin`, `auditor`). If a role with that name already exists, the user receives it automatically; if it does not exist, Prowler Cloud creates a new role with that name with read-only access (visibility over all providers, no management permissions). A Prowler administrator can adjust its permissions through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac). If `userType` is not defined, Prowler Cloud applies the fallback behavior described below. | No |
|
||||
| `organization` | The user's company name. | No |
|
||||
|
||||
**Fallback Role Without `userType`**
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
If `userType` is not defined, the user's existing roles are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name. A Prowler administrator can then assign the appropriate role through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac).
|
||||
|
||||
<Info>
|
||||
**IdP Attribute Mapping**
|
||||
|
||||
@@ -101,13 +111,13 @@ Choose a Method:
|
||||
<Warning>
|
||||
**Single-Value `userType` Required**
|
||||
|
||||
Map `userType` to an IdP attribute that always contains a single value. If the IdP sends multiple values, Prowler App uses only the first value and does not assign multiple roles or select the highest-privilege role.
|
||||
Map `userType` to an IdP attribute that always contains a single value. If the IdP sends multiple values, Prowler Cloud uses only the first value and does not assign multiple roles or select the highest-privilege role.
|
||||
|
||||
</Warning>
|
||||
<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.
|
||||
Prowler Cloud 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>
|
||||
|
||||
@@ -139,31 +149,36 @@ Choose a Method:
|
||||
|
||||
|
||||
|
||||
7. **Configure User Attributes in Okta**: Okta acts as the central source for user profile information. Prowler App maps the following Okta user profile attributes during each SAML login:
|
||||
7. **Configure User Attributes in Okta**: Okta acts as the central source for user profile information. Prowler Cloud maps the following Okta user profile attributes during each SAML login:
|
||||
|
||||
* **First name** (`firstName`): Maps to the user's first name in Prowler App.
|
||||
* **Last name** (`lastName`): Maps to the user's last name in Prowler App.
|
||||
* **First name** (`firstName`): Maps to the user's first name in Prowler Cloud.
|
||||
* **Last name** (`lastName`): Maps to the user's last name in Prowler Cloud.
|
||||
|
||||
|
||||
|
||||
* **Organization** (`organization`): Maps to the company name displayed in Prowler App. This attribute is optional.
|
||||
* **User type** (`userType`): Determines the Prowler role assigned to the user. This attribute is **case-sensitive**: if it matches the exact name of an existing role in Prowler App the user receives that role; if no role with that name exists, a new one is created with read-only access.
|
||||
* **Organization** (`organization`): Maps to the company name displayed in Prowler Cloud. This attribute is optional.
|
||||
* **User type** (`userType`): Determines the Prowler role assigned to the user. This attribute is **case-sensitive**: if it matches the exact name of an existing role in Prowler Cloud the user receives that role; if no role with that name exists, a new one is created with read-only access.
|
||||
|
||||
|
||||
|
||||
To modify these values, edit the user's profile directly in the Okta admin console under the "Profile" tab. Changes are reflected in Prowler App the next time the user logs in via SAML.
|
||||
To modify these values, edit the user's profile directly in the Okta admin console under the "Profile" tab. Changes are reflected in Prowler Cloud the next time the user logs in via SAML.
|
||||
|
||||
<Warning>
|
||||
**User Type and Role Assignment**
|
||||
|
||||
The `userType` attribute controls which Prowler role is assigned to the user:
|
||||
|
||||
* If a role with the specified name already exists in Prowler App, the user automatically receives that role.
|
||||
* If the role does not exist, Prowler App creates a new role with that exact name with read-only access: the user can see all providers and their findings but cannot manage anything. A Prowler administrator (a user whose role includes the "Manage Account" permission) can adjust its permissions afterward through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac).
|
||||
* If `userType` is not defined in the user's Okta profile, the user's existing roles in Prowler App are left unchanged.
|
||||
* `userType` must contain a single value. If the IdP sends multiple values, Prowler App uses only the first value and does not assign multiple roles.
|
||||
* If a role with the specified name already exists in Prowler Cloud, the user automatically receives that role.
|
||||
* If the role does not exist, Prowler Cloud creates a new role with that exact name with read-only access: the user can see all providers and their findings but cannot manage anything. A Prowler administrator (a user whose role includes the "Manage Account" permission) can adjust its permissions afterward through the [RBAC Management tab](/user-guide/tutorials/prowler-app-rbac).
|
||||
* `userType` must contain a single value. If the IdP sends multiple values, Prowler Cloud uses only the first value and does not assign multiple roles.
|
||||
|
||||
**Example:** To assign the `IT` role to a user, set the `userType` value to `IT` in Okta. If a role named `IT` already exists in Prowler App, the user receives it automatically upon login. If it does not exist, Prowler App creates a new role called `IT` with read-only access, and a Prowler administrator can adjust its permissions as needed.
|
||||
**Fallback Role Without `userType`**
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
If `userType` is not defined in the user's Okta profile, the user's existing roles in Prowler Cloud are left unchanged. Users without an existing role in that tenant receive a least-privilege `read_only` fallback role until a Prowler administrator assigns another role. If `read_only` already belongs to a role with different permissions, Prowler Cloud checks suffixed names in order, starting with `read_only_0`. It reuses the first role with the fallback permissions or creates the first available name.
|
||||
|
||||
**Example:** To assign the `IT` role to a user, set the `userType` value to `IT` in Okta. If a role named `IT` already exists in Prowler Cloud, the user receives it automatically upon login. If it does not exist, Prowler Cloud creates a new role called `IT` with read-only access, and a Prowler administrator can adjust its permissions as needed.
|
||||
|
||||
</Warning>
|
||||
|
||||
@@ -179,11 +194,11 @@ Choose a Method:
|
||||
|
||||
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:
|
||||
To complete the Prowler Cloud 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.
|
||||
2. Enter the **primary email domain** for the organization (e.g., `mycompany.com`). Prowler Cloud uses this domain to generate the Assertion Consumer Service (ACS) URL. Every configured domain can identify users who authenticate through this SAML configuration.
|
||||
|
||||
3. Upload the **metadata XML file** downloaded from the IdP.
|
||||
|
||||
@@ -191,27 +206,47 @@ To complete the Prowler App configuration:
|
||||
|
||||
#### Step 5: 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.
|
||||
Click the "Save" button to complete the setup. The "SAML SSO Integration" card will now display an "Enabled" 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.
|
||||
### Add Multiple SAML Domains
|
||||
|
||||
</Info>
|
||||
<VersionBadge version="5.38.0" />
|
||||
|
||||
<SubscriptionBanner />
|
||||
|
||||
Prowler Cloud supports one primary domain and up to 19 additional verified email domains in the same SAML configuration. Users from every configured domain authenticate through the same Identity Provider (IdP), so separate SAML applications are not required for each domain.
|
||||
|
||||
<Note>
|
||||
A SAML configuration supports up to 20 email domains in total. One domain is required as the primary domain, leaving 19 slots for additional domains. Each subdomain counts as a separate additional domain. For example, `partners.example.com` counts separately from `example.com`.
|
||||
</Note>
|
||||
|
||||
The ACS URL always uses the primary domain. Configure this single ACS URL in the IdP even when the SAML configuration includes additional domains.
|
||||
|
||||
To add domains to a new or existing SAML configuration:
|
||||
|
||||
1. Enter the domain in **Additional Email Domains**.
|
||||
2. Click **Add**. Each additional domain must be unique and must differ from the primary domain.
|
||||
3. Repeat these steps for every domain that must share the configuration.
|
||||
4. Click **Save** for a new configuration or **Update** for an existing configuration.
|
||||
|
||||
|
||||
|
||||
To remove an additional domain, click the remove button next to the domain, then click **Update**. Users from a removed domain can no longer start SAML authentication through this configuration.
|
||||
|
||||
### 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
|
||||
2. Click 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.
|
||||
@@ -222,11 +257,11 @@ 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
|
||||
5. After successful authentication, users are returned to Prowler Cloud
|
||||
|
||||
This method is useful when users bookmark Prowler or navigate directly to the application.
|
||||
|
||||
@@ -234,11 +269,11 @@ This method is useful when users bookmark Prowler or navigate directly to the ap
|
||||
|
||||
## Developer and Administrator Guide
|
||||
|
||||
This section provides technical details for developers and administrators of self-hosted Prowler instances.
|
||||
This section provides technical details for developers and administrators of Prowler Local Server 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.
|
||||
For Prowler Local Server 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 |
|
||||
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
|
||||
|
||||
@@ -7,16 +7,16 @@ import { ProviderCards } from "/snippets/provider-cards.mdx"
|
||||
|
||||
**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**.
|
||||
**Prowler Local Server** is the self-hosted version of **Prowler Cloud**. See [Prowler product families](/getting-started/products) for every official product name.
|
||||
|
||||
## 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**
|
||||
**For Prowler Local Server users**
|
||||
|
||||
After [installing](/getting-started/installation/prowler-app) **Prowler App**, access it at [http://localhost:3000](http://localhost:3000).
|
||||
After [installing](/getting-started/installation/prowler-app) **Prowler Local Server**, 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>
|
||||
@@ -45,7 +45,7 @@ See [how to configure Social Login for Prowler](/user-guide/tutorials/prowler-ap
|
||||
|
||||
</Note>
|
||||
## Step 2: Log In
|
||||
Once registered, log in with your email and password to access Prowler App.
|
||||
Once registered, log in with your email and password to access Prowler Cloud.
|
||||
|
||||
<img src="/images/log-in.png" alt="Log In" width="350" />
|
||||
|
||||
@@ -85,12 +85,12 @@ For detailed instructions on configuring credentials for each provider, refer to
|
||||
<ProviderCards />
|
||||
|
||||
## 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:
|
||||
After adding your cloud account credentials, click the `Check connection` button to verify that Prowler 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:
|
||||
After the connection check succeeds, save the provider and start your first scan with the `Launch Scan` button. The `Scans` section shows the scan in progress:
|
||||
|
||||
<img src="/images/provider-added.png" alt="Start Now" width="700" />
|
||||
|
||||
@@ -127,28 +127,22 @@ While the scan is running, start exploring the findings in these sections:
|
||||
|
||||
<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.
|
||||
- **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:
|
||||
Once a scan is complete, navigate to the `Scans` 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.
|
||||
You can download the output files generated by Prowler as a single `zip` file. This archive contains the CSV, JSON-OCSF, 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.
|
||||
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" />
|
||||
|
||||
@@ -163,8 +157,6 @@ Once your scan has finished, you don’t need to grab the entire ZIP—just pull
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -8,12 +8,14 @@ import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
|
||||
|
||||
<VersionBadge version="5.19.0" />
|
||||
|
||||
Prowler Cloud enables you to onboard all AWS accounts in your Organization through a single guided wizard. Instead of connecting accounts one by one, you can discover every account in your AWS Organization, select the ones you want to monitor, test connectivity, and launch scans — all from the Prowler Cloud UI.
|
||||
Prowler Cloud onboards every AWS account in your Organization through a single guided wizard. Instead of connecting accounts one by one, you can discover every account in your AWS Organization, select the ones you want to monitor, test connectivity, and launch scans — all from the Prowler Cloud UI.
|
||||
|
||||
<SubscriptionBanner>
|
||||
For CLI-based multi-account scanning, see [AWS Organizations in Prowler CLI](/user-guide/providers/aws/organizations).
|
||||
</SubscriptionBanner>
|
||||
|
||||
To follow this guide you need an active [Prowler Cloud](https://cloud.prowler.com) account and access to your AWS Organization [management account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) (or a registered delegated administrator account).
|
||||
|
||||
## Overview
|
||||
|
||||
### Individual Accounts vs Organizations
|
||||
@@ -25,225 +27,17 @@ For CLI-based multi-account scanning, see [AWS Organizations in Prowler CLI](/us
|
||||
|
||||
### How It Works
|
||||
|
||||
Before using the AWS Organizations wizard, you need to deploy **two Identity and Access Management (IAM) roles** in your AWS environment. The onboarding follows this sequence:
|
||||
<VersionBadge version="5.35.0" />
|
||||
|
||||
Onboarding deploys the **ProwlerScan Identity and Access Management (IAM) role** in your management account and in every member account. A **single CloudFormation stack** — launched from the wizard's **Create Stack in Management Account** button ([Step 2](#step-2-authenticate-with-your-management-account)) — creates the management account role **and** a service-managed StackSet that rolls the role out to your member accounts in one operation. Prefer to deploy the roles yourself? See [Deploy the Roles Manually](#deploy-the-roles-manually).
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/onboarding-flow.svg" alt="Onboarding flow: 1. Create Management Account Role (Quick Create or Manual), 2. Deploy StackSet, 3. Run the Wizard, 4. Launch Scans" />
|
||||
<img src="/images/organizations/onboarding-flow.svg" alt="Onboarding flow: 1. Start the Wizard, 2. Deploy the Roles (single CloudFormation stack), 3. Discover and Connect, 4. Launch Scans" />
|
||||
</Frame>
|
||||
|
||||
## Key Concepts
|
||||
## Step 1: Start the Organization Wizard
|
||||
|
||||
### What Is an External ID?
|
||||
|
||||
An **External ID** is a security token that Prowler generates unique to your tenant. When Prowler assumes the IAM role in your AWS account, it presents this External ID to prove its identity.
|
||||
|
||||
This prevents the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) — a scenario where an unauthorized party could trick AWS into granting access to your account. By requiring the External ID, only your specific Prowler tenant can assume the role.
|
||||
|
||||
You don't need to create the External ID yourself — Prowler generates it automatically and displays it in the wizard for you to copy.
|
||||
|
||||
### Two Roles Architecture
|
||||
|
||||
Prowler requires **two separate IAM roles** deployed in different places, each with a distinct purpose:
|
||||
|
||||
| Role | Where it lives | What it does | How to deploy it |
|
||||
|------|---------------|--------------|------------------|
|
||||
| **ProwlerScan** (management account) | Your management (root) account only | Discovers the Organization structure **and** scans the management account. Has additional Organizations discovery permissions. | Via **Quick Create** link or **manually** in the IAM Console ([Step 1](#step-1-create-the-management-account-role)). Cannot be deployed via StackSet. |
|
||||
| **ProwlerScan** (member accounts) | Every member account | Scans the account for security findings. | Via **CloudFormation StackSet** ([Step 2](#step-2-deploy-the-cloudformation-stackset)). Automated across all accounts. |
|
||||
|
||||
<Frame caption="Both roles share the same name `ProwlerScan`. The management account role includes additional Organization discovery permissions.">
|
||||
<img src="/images/organizations/two-roles-architecture.svg" alt="Two Roles Architecture: ProwlerScan in management account (Quick Create or Manual, discovery + scanning) and ProwlerScan in member accounts (via StackSet, scanning only)" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
**Same name, different permissions.** Both roles are named `ProwlerScan` — Prowler expects a consistent role name across all accounts. The management account role has the same scanning permissions as member accounts, plus additional Organizations discovery permissions (see [Step 1](#step-1-create-the-management-account-role) for the full list).
|
||||
</Note>
|
||||
|
||||
### What Is a CloudFormation StackSet?
|
||||
|
||||
A [CloudFormation StackSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) lets you deploy the same CloudFormation template across multiple AWS accounts in a single operation. Prowler uses a StackSet to deploy the **ProwlerScan** IAM role into every member account of your organization, so you don't have to create the role manually in each account.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Prowler Cloud Account
|
||||
|
||||
You need an active [Prowler Cloud](https://cloud.prowler.com) account. Each AWS account you connect will count as a provider in your subscription. See [Billing Impact](#billing-impact) for details.
|
||||
|
||||
### AWS Organization Enabled
|
||||
|
||||
Your AWS environment must have [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) enabled. You will need access to the **management account** (or a delegated administrator account) to provide the Organization ID and IAM Role ARN.
|
||||
|
||||
## Step 1: Create the Management Account Role
|
||||
|
||||
The first role you need to create is the **management account role**. This role allows Prowler to discover your Organization structure — listing accounts, OUs, and hierarchy.
|
||||
|
||||
<Warning>
|
||||
**StackSets do not deploy to the management account.** Organizational CloudFormation StackSets with service-managed permissions only target member accounts — this is an AWS limitation, not a Prowler one. You must create the management account role separately, either via the Quick Create link ([Option A](#option-a-quick-create-link-fastest)) or manually ([Option B](#option-b-create-the-role-manually)).
|
||||
</Warning>
|
||||
|
||||
<Note>
|
||||
**The role must be named `ProwlerScan`** — the same name as the role deployed to member accounts via StackSet. Prowler expects a consistent role name across all accounts in the Organization. If you use a different name, connection tests and scans will fail for the management account.
|
||||
</Note>
|
||||
|
||||
### Option A: Quick Create Link (Fastest)
|
||||
|
||||
The Prowler wizard provides a one-click link that opens the AWS Console with the CloudFormation template pre-configured. This creates a **CloudFormation Stack** (not a StackSet) that deploys the ProwlerScan role with Organizations permissions enabled in your management account.
|
||||
|
||||
<Tip>
|
||||
**[Open Quick Create Stack in AWS Console →](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_EnableOrganizations=true)**
|
||||
|
||||
Opens the CloudFormation Console with the Prowler scan role template and `EnableOrganizations=true` pre-filled. You will need to enter the **ExternalId** parameter manually — copy it from the Prowler wizard ([Step 4](#step-4-authenticate-with-your-management-account)).
|
||||
</Tip>
|
||||
|
||||
1. Click **[Open Quick Create Stack in AWS Console →](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_EnableOrganizations=true)** or use the **Create Stack in Management Account** button in the Prowler wizard (which also pre-fills the ExternalId).
|
||||
2. Enter the **ExternalId** parameter if not pre-filled.
|
||||
3. Check **"I acknowledge that AWS CloudFormation might create IAM resources with custom names"** and click **Create stack**.
|
||||
4. Wait for the stack to reach **CREATE_COMPLETE** status.
|
||||
|
||||
Take note of the **Role ARN** from the stack's **Outputs** tab — you will need it in the wizard.
|
||||
|
||||
### Option B: Create the Role Manually
|
||||
|
||||
1. Sign in to the [AWS IAM Console](https://console.aws.amazon.com/iam/) in your **management account**.
|
||||
|
||||
2. Go to **Roles > Create role** and select **Custom trust policy**.
|
||||
|
||||
3. Paste the following trust policy. This allows Prowler Cloud to assume the role using your tenant's External ID (you will get this from the Prowler wizard in [Step 3](#step-3-start-the-organization-wizard)):
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::232136659152:root"
|
||||
},
|
||||
"Action": "sts:AssumeRole",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"sts:ExternalId": "<YOUR_EXTERNAL_ID>"
|
||||
},
|
||||
"StringLike": {
|
||||
"aws:PrincipalArn": "arn:aws:iam::232136659152:role/prowler*"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Replace `<YOUR_EXTERNAL_ID>` with the External ID shown in the Prowler wizard.
|
||||
|
||||
4. Attach the following AWS managed policies:
|
||||
- **SecurityAudit**
|
||||
- **ViewOnlyAccess**
|
||||
|
||||
This allows Prowler to also scan the management account for security findings, just like any other account.
|
||||
|
||||
5. Create an additional inline policy with the following permissions. These are specific to the management account and allow Prowler to discover your Organization structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "ProwlerOrganizationDiscovery",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"organizations:DescribeAccount",
|
||||
"organizations:DescribeOrganization",
|
||||
"organizations:ListAccounts",
|
||||
"organizations:ListAccountsForParent",
|
||||
"organizations:ListOrganizationalUnitsForParent",
|
||||
"organizations:ListRoots",
|
||||
"organizations:ListTagsForResource"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "ProwlerStackSetManagement",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"organizations:RegisterDelegatedAdministrator",
|
||||
"iam:CreateServiceLinkedRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<Tip>
|
||||
You can optionally restrict the `Resource` field to your specific Organization ARN (e.g., `arn:aws:organizations::123456789012:organization/o-abc123def4`) instead of `"*"` to minimize the blast radius.
|
||||
</Tip>
|
||||
|
||||
6. Name the role **`ProwlerScan`** and click **Create role**. Take note of the **Role ARN** — you will need it in the Prowler wizard.
|
||||
|
||||
The ARN follows this format: `arn:aws:iam::<account-id>:role/ProwlerScan`
|
||||
|
||||
<Warning>
|
||||
The role **must** be named `ProwlerScan`. Do not use a different name.
|
||||
</Warning>
|
||||
|
||||
<Note>
|
||||
If you just created the role, it may take up to **60 seconds** for AWS to propagate it. If you get an error in the Prowler wizard, wait a moment and try again.
|
||||
</Note>
|
||||
|
||||
## Step 2: Deploy the CloudFormation StackSet
|
||||
|
||||
After creating the management account role, the next step is to deploy the **ProwlerScan** role to your member accounts using a CloudFormation StackSet. This is the recommended method for consistent, scalable deployment across your entire organization.
|
||||
|
||||
The StackSet uses **service-managed permissions**, which means AWS Organizations handles the cross-account deployment automatically — you don't need to create execution roles manually in each account. The StackSet deploys the ProwlerScan IAM role in every target member account, enabling Prowler to assume that role for cross-account scanning.
|
||||
|
||||
<Note>
|
||||
**Trusted access required:** CloudFormation StackSets must have trusted access enabled in your management account. Verify this in the AWS Console under **AWS Organizations > Settings > Trusted access for AWS CloudFormation StackSets**.
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
**The Quick Create link creates a Stack, not a StackSet.** The link in the Prowler wizard creates a CloudFormation **Stack** that deploys the ProwlerScan role in your management account only ([Step 1](#step-1-create-the-management-account-role)). To deploy the role across **member accounts**, you must create a StackSet manually as described below. AWS does not support Quick Create links for StackSets.
|
||||
</Warning>
|
||||
|
||||
<Tip>
|
||||
**[Open StackSets Console →](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacksets/create)**
|
||||
|
||||
Opens the CloudFormation StackSets creation page directly. You will need to paste the template URL and ExternalId manually.
|
||||
</Tip>
|
||||
|
||||
1. Click the link above or navigate to **CloudFormation > StackSets > Create StackSet** in your management account.
|
||||
2. Choose **Service-managed permissions**.
|
||||
3. Select **Amazon S3 URL** as the template source and paste the following URL:
|
||||
```
|
||||
https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml
|
||||
```
|
||||
4. Set the **ExternalId** parameter to the External ID shown in the Prowler wizard.
|
||||
5. Choose your deployment targets (entire organization or specific OUs).
|
||||
6. Select the AWS regions where you want the role deployed.
|
||||
7. Click **Create StackSet**.
|
||||
|
||||
### Verify StackSet Deployment
|
||||
|
||||
After deploying, verify that all stack instances completed successfully:
|
||||
|
||||
1. In the CloudFormation Console, go to **StackSets** and select your Prowler StackSet.
|
||||
2. Click the **Stack instances** tab.
|
||||
3. Confirm that all instances show **Status: CURRENT** and **Stack status: CREATE_COMPLETE**.
|
||||
|
||||
Deployment typically takes **2–5 minutes** for medium-sized organizations. Large organizations (500+ accounts) may take longer.
|
||||
|
||||
<Note>
|
||||
**Prefer Terraform?** You can deploy the ProwlerScan role using Terraform instead. See the [StackSets deployment guide](/user-guide/providers/aws/organizations#deploying-prowler-iam-roles-across-aws-organizations) for the Terraform module.
|
||||
</Note>
|
||||
|
||||
### Key Considerations
|
||||
|
||||
- **Service-managed permissions**: Always select **Service-managed permissions** when creating the StackSet. This lets AWS Organizations manage the deployment automatically across current and future member accounts.
|
||||
- **Least privilege**: The ProwlerScan role deployed by the StackSet uses `SecurityAudit` and `ViewOnlyAccess` — AWS managed policies that grant read-only access — plus a small set of additional read-only permissions for services not covered by those policies. See the [CloudFormation template](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml) for the full list. Prowler does not make any changes to your accounts.
|
||||
- **New accounts**: When you add new accounts to your AWS Organization, the StackSet automatically deploys the ProwlerScan role to them if you targeted the organization root or the relevant OU. Combined with Prowler's 6-hour automatic sync, new accounts are onboarded end-to-end without manual intervention.
|
||||
- **Management account**: Organizational StackSets **do not deploy to the management account itself**. If you want to scan the management account, you need to create the ProwlerScan role there separately using a regular CloudFormation Stack.
|
||||
|
||||
## Step 3: Start the Organization Wizard
|
||||
|
||||
Now that both roles are deployed — the management account role (Step 1) and the ProwlerScan role in member accounts (Step 2) — you can start the Prowler wizard.
|
||||
The Prowler wizard walks you through the entire flow: deploying both roles from a single CloudFormation stack, discovering your accounts, testing connectivity, and launching scans.
|
||||
|
||||
### Open the Wizard
|
||||
|
||||
@@ -280,29 +74,50 @@ Now that both roles are deployed — the management account role (Step 1) and th
|
||||
|
||||
Click **Next** to proceed to the authentication phase.
|
||||
|
||||
## Step 4: Authenticate with Your Management Account
|
||||
## Step 2: Authenticate with Your Management Account
|
||||
|
||||
The wizard's **Authentication Details** page guides you through three actions: deploying the roles in AWS, entering the management account Role ARN, and confirming the deployment.
|
||||
The **Authentication Details** page guides you through three actions: deploying the roles in AWS, entering the deployment account Role ARN, and confirming the deployment. The deployment account is either the management account or, when delegated administrator mode is selected, the delegated administrator account.
|
||||
|
||||
### External ID
|
||||
|
||||
The wizard displays a **Prowler External ID** at the top — auto-generated and unique to your tenant. Click the copy icon to copy it. You will need this External ID for both the management account Stack and the member accounts StackSet.
|
||||
The wizard displays a **Prowler External ID** at the top — auto-generated and unique to your tenant. Click the copy icon to copy it. The External ID is pre-filled into the deployment link, and the single stack applies it to both the management account role and the member-account StackSet. Learn more in [What Is an External ID?](#what-is-an-external-id).
|
||||
|
||||
### Deploy the Roles
|
||||
|
||||
The wizard provides two deployment actions:
|
||||
<VersionBadge version="5.35.0" />
|
||||
|
||||
1. **Create Stack in Management Account** — opens a Quick Create link that deploys the ProwlerScan role with `EnableOrganizations=true` in your management account ([Step 1](#step-1-create-the-management-account-role)). The External ID is pre-filled.
|
||||
The wizard deploys the deployment account role and the member-account StackSet in a **single** CloudFormation Stack:
|
||||
|
||||
2. **Open StackSets Console** — links to the CloudFormation StackSets console where you create a StackSet for member accounts ([Step 2](#step-2-deploy-the-cloudformation-stackset)). Copy the template URL shown in the wizard and paste the External ID manually.
|
||||
<Note>
|
||||
**Prefer to use your own role?** You do not have to use the Quick Create template. Create the ProwlerScan role yourself — through the IAM Console, Terraform, or your own CloudFormation [(Following this guide)](#deploy-the-roles-manually) — and paste its ARN into the Role ARN field below. The role must use the external ID from the earlier step and include the trust policy and permissions described in [Deploy the Roles Manually](#deploy-the-roles-manually).
|
||||
</Note>
|
||||
|
||||
1. **Organizational Unit or Root ID** — enter the AWS OU (`ou-xxxx-yyyyyyyy`) or organization root (`r-xxxx`) you want to onboard. Prowler rolls the ProwlerScan role out to every member account under this target. Find it in the [AWS Organizations Console](https://console.aws.amazon.com/organizations/); use the **root ID** (`r-`) to cover the entire organization or an **OU ID** (`ou-`) to target a specific unit.
|
||||
|
||||
2. *(Optional)* Check **"I'm deploying from a delegated administrator account"** if you launch the stack from a delegated administrator account instead of the management account.
|
||||
|
||||
3. **Create Stack in Management Account** — or **Create Stack in Delegated Administrator Account** when delegated administrator mode is selected — opens a Quick Create link that deploys, in a single stack: the ProwlerScan role in the account where you launch the stack (`DeployLocalRole`, with `EnableOrganizations=true`) **and** a service-managed StackSet (`DeployStackSet`) that rolls the role out to your member accounts. The External ID, OU/Root ID, and deployment options are pre-filled.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/authentication-details.png" alt="Authentication Details form showing External ID, two deployment buttons (Create Stack in Management Account and Open StackSets Console), Management Account Role ARN field, and deployment confirmation checkbox" />
|
||||
<img src="/images/organizations/authentication-details.png" alt="Authentication Details form showing External ID, Organizational Unit or Root ID field, delegated administrator checkbox, deployment account stack button, deployment account Role ARN field, and deployment confirmation checkbox" />
|
||||
</Frame>
|
||||
|
||||
### Enter the Management Account Role ARN
|
||||
<Tip>
|
||||
**Finding your Organizational Unit or Root ID.** In the [AWS Organizations Console](https://console.aws.amazon.com/organizations/) the root (`r-…`) and OU (`ou-…`) IDs appear in the account tree, or run these from your management account:
|
||||
|
||||
Paste the **Role ARN** of the management account role you created in [Step 1](#step-1-create-the-management-account-role) into the **Management Account Role ARN** field.
|
||||
```bash
|
||||
# Root ID — deploys the role to the entire organization
|
||||
aws organizations list-roots --query 'Roots[0].Id' --output text
|
||||
|
||||
# OU IDs under the root — to target a specific unit instead
|
||||
aws organizations list-organizational-units-for-parent --parent-id r-xxxx \
|
||||
--query 'OrganizationalUnits[].{Name:Name,Id:Id}' --output table
|
||||
```
|
||||
</Tip>
|
||||
|
||||
### Enter the Deployment Account Role ARN
|
||||
|
||||
Paste the **Role ARN** created by the stack above into the **Management Account Role ARN** field or, when delegated administrator mode is selected, the **Delegated Administrator Account Role ARN** field.
|
||||
|
||||
The ARN follows this format:
|
||||
```
|
||||
@@ -312,12 +127,16 @@ arn:aws:iam::<account-id>:role/ProwlerScan
|
||||
For example: `arn:aws:iam::123456789012:role/ProwlerScan`
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/role-arn-field.png" alt="Management Account Role ARN field in the Authentication Details form" />
|
||||
<img src="/images/organizations/role-arn-field.png" alt="Deployment account Role ARN field in the Authentication Details form" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
It may take up to **60 seconds** for AWS to generate the IAM Role ARN after the stack completes. If the wizard reports an error, wait a moment and try again.
|
||||
</Note>
|
||||
|
||||
### Confirm and Discover
|
||||
|
||||
1. Check the box: **"The Stack and StackSet have been successfully deployed in AWS"**.
|
||||
1. Check the box: **"The Stack has been successfully deployed in AWS"**.
|
||||
2. Click **Authenticate**.
|
||||
|
||||
Here's what happens behind the scenes:
|
||||
@@ -325,7 +144,22 @@ Here's what happens behind the scenes:
|
||||
- An asynchronous discovery is triggered to query your AWS Organization structure.
|
||||
- You will see a **"Gathering AWS Accounts..."** spinner — this typically takes **30 seconds to 2 minutes** depending on your organization size.
|
||||
|
||||
## Step 5: Select Accounts to Scan
|
||||
#### When Discovery Takes Too Long
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
Prowler waits up to **3 minutes** for a result. Past that, the wizard stops waiting — but the discovery keeps running in the background — and offers two actions:
|
||||
|
||||
- **Keep waiting** — resume the same discovery. Nothing is re-read from AWS.
|
||||
- **Retry** — start a fresh discovery, which queries your Organization structure again.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/discovery-timeout.png" alt="Discovery timeout notice offering Keep waiting and Retry" />
|
||||
</Frame>
|
||||
|
||||
If discovery fails outright, the wizard reports the error and offers **Retry discovery**.
|
||||
|
||||
## Step 3: Select Accounts to Scan
|
||||
|
||||
### Understanding the Tree View
|
||||
|
||||
@@ -336,6 +170,7 @@ Once discovery completes, the wizard displays a **hierarchical tree view** of yo
|
||||
</Frame>
|
||||
|
||||
- The tree supports up to **5 levels of nesting** (Root > OUs > Sub-OUs > Accounts).
|
||||
- If you deployed the stack for just one OU, that OU will be preselected in the tree.
|
||||
- **Selecting an OU** automatically selects all accounts within it.
|
||||
- **Individual overrides**: deselect specific accounts even if the parent OU is selected.
|
||||
- The header shows **"X of Y accounts selected"** to track your selection.
|
||||
@@ -352,14 +187,12 @@ Only **ACTIVE** accounts can be selected for scanning:
|
||||
| **CLOSED** | No | Account has been closed. |
|
||||
|
||||
<Note>
|
||||
**Your existing data is safe.** If an AWS account is already connected to Prowler as an individual provider, it will appear in the tree with a checkmark indicator.
|
||||
**Your existing data is safe.** If an AWS account is already connected to Prowler as an individual provider, it appears in the tree with a checkmark indicator.
|
||||
|
||||
When you proceed:
|
||||
- The existing provider is **linked** to the organization — it is **not** duplicated.
|
||||
- All your **historical scan data and findings are preserved** — nothing is overwritten.
|
||||
- There is **no additional billing** — the existing provider is reused.
|
||||
|
||||
This is completely safe. You are simply associating the account with the organization for easier management.
|
||||
</Note>
|
||||
|
||||
### Custom Aliases
|
||||
@@ -368,14 +201,26 @@ You can edit the display name for each account before connecting. This alias is
|
||||
|
||||
### Blocked Accounts
|
||||
|
||||
Some accounts may appear as **blocked** (grayed out, not selectable). This happens when:
|
||||
- The account is **already linked to a different organization** in Prowler (`linked_to_other_organization`).
|
||||
Some accounts appear as **blocked** (grayed out, not selectable) when onboarding them would conflict with something Prowler already stores. Hover over the blocked account to see the specific reason.
|
||||
|
||||
Hover over the blocked account to see the specific reason.
|
||||
| Reason | What it means |
|
||||
|--------|---------------|
|
||||
| `organization_conflict` | The account is already connected under a **different** Prowler organization. |
|
||||
| `organization_node_conflict` | The account is already grouped under a different organizational unit in Prowler — for example, it moved in AWS after it was onboarded. |
|
||||
|
||||
## Step 6: Test Connections
|
||||
### Accounts That Already Have Credentials
|
||||
|
||||
### How Connection Testing Works
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
Applying your selection stores the organization credential on every selected account. When a selected account is already connected to Prowler with its own credential, that credential is **overwritten** — so the wizard asks first, naming the affected accounts:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/replace-credentials-apply.png" alt="Replace existing credentials modal listing the accounts whose credentials will be replaced" />
|
||||
</Frame>
|
||||
|
||||
Click **Replace and continue** to proceed, or **Cancel** to adjust your selection. Historical scans and findings are preserved either way — only the credential changes.
|
||||
|
||||
## Step 4: Test Connections
|
||||
|
||||
Click **Test Connections** to verify that Prowler can assume the **ProwlerScan** role in each selected member account.
|
||||
|
||||
@@ -383,154 +228,273 @@ Click **Test Connections** to verify that Prowler can assume the **ProwlerScan**
|
||||
<img src="/images/organizations/test-connections.png" alt="Connection testing in progress with spinners on each account" />
|
||||
</Frame>
|
||||
|
||||
- Each account shows a real-time status indicator:
|
||||
- **Spinner** — test in progress
|
||||
- **Green checkmark (✓)** — connection successful
|
||||
- **Red icon (✗)** — connection failed (hover to see the error)
|
||||
|
||||
### All Tests Pass
|
||||
Each account shows a real-time status indicator:
|
||||
- **Spinner** — test in progress
|
||||
- **Green checkmark (✓)** — connection successful
|
||||
- **Red icon (✗)** — connection failed (hover to see the error)
|
||||
|
||||
If every account connects successfully, you automatically advance to the next step.
|
||||
|
||||
### Some Tests Fail
|
||||
### When Some Tests Fail
|
||||
|
||||
An error banner appears: **"There was a problem connecting to some accounts."**
|
||||
|
||||
You have two options:
|
||||
An error banner appears: **"There was a problem connecting to some accounts. Hover each account to check the error."** You have two options:
|
||||
|
||||
**a) Fix and retry:**
|
||||
1. Go to the AWS Console and verify the StackSet deployed to the failing accounts.
|
||||
2. Check that the External ID in the StackSet matches the one shown in Prowler.
|
||||
3. Return to Prowler and click **Test Connections** — only the **failed accounts are re-tested** (smart retry). Accounts that already passed are not tested again.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/test-connections-button.png" alt="Test Connections button" />
|
||||
</Frame>
|
||||
|
||||
**b) Skip and continue:**
|
||||
Click **Skip Connection Validation** to proceed with only the accounts that connected successfully. The failed accounts will not be scanned.
|
||||
Click **Skip Connection Validation** to proceed with only the accounts that connected successfully. The failed accounts will not be scanned. This option is only available when at least one account connected successfully.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/connection-failures-skip.png" alt="Connection test results showing failed accounts with error banner and Skip Connection Validation button" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
**Skip Connection Validation** is only available when at least one account connected successfully.
|
||||
</Note>
|
||||
If **no accounts** connected successfully, the banner instead reads *"No accounts connected successfully. Fix the connection errors and retry before launching scans."* and you cannot proceed. Fix the underlying connection issues — see [Troubleshooting](#troubleshooting) — and retry before launching scans.
|
||||
|
||||
### All Tests Fail
|
||||
|
||||
If **no accounts** connected successfully, you cannot proceed:
|
||||
|
||||
> *"No accounts connected successfully. Fix the connection errors and retry before launching scans."*
|
||||
|
||||
You must fix the underlying connection issues before continuing. See [Updating Credentials](#updating-credentials) below.
|
||||
|
||||
### Updating Credentials
|
||||
|
||||
If connection tests fail, here's how to fix common issues:
|
||||
|
||||
1. Open the [CloudFormation Console](https://console.aws.amazon.com/cloudformation/) and check that your StackSet instances show **CREATE_COMPLETE** for the failing accounts. If not, update the StackSet to include the missing OUs.
|
||||
2. Compare the **ExternalId** parameter in your StackSet with the External ID displayed in the Prowler wizard. They must match exactly.
|
||||
3. After fixing the issue in AWS, return to Prowler and click **Test Connections**. Only the previously failed accounts will be re-tested.
|
||||
|
||||
## Step 7: Launch Scans
|
||||
|
||||
### Choose Scan Schedule
|
||||
## Step 5: Launch Scans
|
||||
|
||||
The Organizations wizard uses the same schedule controls described in [Scan Scheduling](/user-guide/tutorials/prowler-scan-scheduling#schedule-options).
|
||||
|
||||
### Launch
|
||||
|
||||
Click **Save**, **Save and launch scan**, or **Launch scan**, depending on the selected schedule option. A toast notification confirms whether the schedule was saved, scans were launched, or both. The toast includes a link to the **Scans** page. Prowler redirects to the **Providers** page.
|
||||
|
||||
Scans are only launched for accounts that are accessible (passed connection testing) and were selected.
|
||||
Click **Save**, **Save and launch scan**, or **Launch scan**, depending on the selected schedule option. A toast notification confirms whether the schedule was saved, scans were launched, or both, and includes a link to the **Scans** page. Prowler then redirects to the **Providers** page. Scans launch only for accounts that passed connection testing and were selected.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/launch-scan.png" alt="Launch Scan step showing Accounts Connected confirmation, scan schedule selector, and Launch scan button" />
|
||||
</Frame>
|
||||
|
||||
### What Happens Next
|
||||
|
||||
After launching:
|
||||
- Scans appear in the **Scans** page as they start and complete.
|
||||
- Results populate the **Overview** and **Findings** pages.
|
||||
- Prowler runs an **automatic sync every 6 hours** to detect new accounts added to your Organization or accounts that have been removed. New accounts are onboarded automatically based on the parent OU configuration.
|
||||
- Prowler runs an **automatic sync every 6 hours** to detect accounts added to or removed from your Organization. New accounts under the targeted OU or root are onboarded automatically.
|
||||
|
||||
## Manage Your Organization After Onboarding
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
Open the row actions menu on the organization row on the **Providers** page.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/organization-row-actions.png" alt="Row actions menu on an AWS organization row" />
|
||||
</Frame>
|
||||
|
||||
| Action | What it does |
|
||||
|--------|--------------|
|
||||
| **Edit Organization Name** | Renames the organization in Prowler. Leave it blank to fall back to the name stored in AWS. |
|
||||
| **Update Credentials** | Reopens the Authentication Details step to store a new Role ARN. |
|
||||
| **Edit Scan Schedule** | Applies one schedule to every connected account in the organization. |
|
||||
| **Test Connections (N)** | Re-tests every account in the organization. |
|
||||
| **Delete Organization** | Deletes the organization and cascades to its providers. |
|
||||
|
||||
Organizational unit rows carry the same **Test Connections** and **Delete Organizational Unit** actions, scoped to the accounts beneath them.
|
||||
|
||||
### Update Organization Credentials
|
||||
|
||||
Choosing **Update Credentials** re-enters the Authentication Details step. Because the organization already holds a credential, Prowler warns before overwriting it and names how many providers re-authenticate with the new one:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/replace-credentials-setup.png" alt="Replace existing credentials modal showing how many providers re-authenticate" />
|
||||
</Frame>
|
||||
|
||||
Storing a new credential runs a fresh discovery, so any discovery already in progress is discarded — discovery authenticates with the credential it started from.
|
||||
|
||||
### Delete an Organization or Organizational Unit
|
||||
|
||||
Deleting an organization or an organizational unit **cascades to every provider grouped under it**, along with their scans and findings. Both dialogs state how many providers are affected before you confirm.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/delete-organization.png" alt="Delete organization dialog showing how many providers are deleted with it" />
|
||||
</Frame>
|
||||
|
||||
Deletion runs in the background. Prowler confirms with a **"Deletion started"** notification; if any part of it fails, the affected rows reappear on a later refresh.
|
||||
|
||||
<Danger>
|
||||
Deleting an organization **permanently deletes every account provider grouped under it**, including their historical scans and findings. This action cannot be undone.
|
||||
</Danger>
|
||||
|
||||
### When Grouping Is Unavailable
|
||||
|
||||
If Prowler cannot read your hierarchy while loading the Providers page, a notice reads *"Organization grouping is incomplete. Some providers may appear ungrouped."* Your providers are still listed, just flat. Reload the page to try again.
|
||||
|
||||
## Billing Impact
|
||||
|
||||
Each AWS account you connect through the Organizations wizard counts as one **provider** in your Prowler Cloud subscription.
|
||||
|
||||
- **Already-connected accounts**: if an account was already linked as a provider, adding it to the organization does **not** incur additional billing. The existing provider is reused.
|
||||
- **Large organizations**: connecting a 500-account organization will result in up to 500 providers on your subscription. Review your plan limits before proceeding.
|
||||
- **Large organizations**: connecting a 500-account organization results in up to 500 providers on your subscription. Review your plan limits before proceeding.
|
||||
- **Deleted providers**: if you later remove an account, the deleted provider no longer counts toward your subscription.
|
||||
|
||||
For pricing details, see [Prowler Cloud Pricing](/getting-started/products/prowler-cloud-pricing).
|
||||
For pricing details, see [Prowler Cloud Pricing](https://prowler.com/pricing).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Invalid AWS Organization ID
|
||||
### Only Some Accounts Connect
|
||||
|
||||
*"Must be a valid AWS Organization ID"*
|
||||
Discovery succeeds and the tree view appears, but only one account — or a handful — passes the connection test. This almost always means the ProwlerScan role reached the deployment account but not every member account.
|
||||
|
||||
- Verify the Organization ID format: `o-` followed by 10–32 lowercase alphanumeric characters (e.g., `o-abc123def4`)
|
||||
- Copy it directly from the [AWS Organizations Console](https://console.aws.amazon.com/organizations/) to avoid typos
|
||||
- **Confirm the StackSet deployed.** Open the [CloudFormation Console](https://console.aws.amazon.com/cloudformation/) in the deployment account, select your Prowler StackSet, open the **Stack instances** tab, and confirm every instance shows **Status: CURRENT** and **Stack status: CREATE_COMPLETE**. Instances still in progress or in a failed state explain the missing accounts.
|
||||
- **Check the targeted OU or root.** The single stack only rolls the role out to accounts under the **Organizational Unit or Root ID** you entered in [Step 2](#step-2-authenticate-with-your-management-account). Accounts in other OUs are not covered — redeploy targeting the organization root (`r-`) or add the missing OUs.
|
||||
- **Verify the deployment account.** The role is created only in the account where you launched the stack. If you deployed from a **delegated administrator account**, confirm that account is a **registered delegated administrator** for CloudFormation StackSets (registered through AWS Organizations), not just a regular member account. A regular member account cannot create a service-managed StackSet, so only its own role is created — leaving every other account without the role.
|
||||
- **Suspended accounts** cannot be scanned. Deselect them and proceed.
|
||||
|
||||
### Invalid IAM Role ARN
|
||||
### No Accounts Connect
|
||||
|
||||
*"Must be a valid IAM Role ARN"*
|
||||
No account passes the connection test.
|
||||
|
||||
- Verify the ARN format: `arn:aws:iam::<12-digit-account-id>:role/<role-name>`
|
||||
- Copy the ARN directly from the [IAM Console](https://console.aws.amazon.com/iam/) in your management account
|
||||
- **External ID mismatch.** Compare the **ExternalId** parameter in your StackSet with the External ID shown in the Prowler wizard. They must match exactly.
|
||||
- **StackSet not deployed.** Confirm the StackSet exists and its instances reached **CREATE_COMPLETE**. If you deployed the roles manually, verify [trusted access for CloudFormation StackSets](#member-account-role-stackset) is enabled.
|
||||
- **IP-based policies.** If your accounts restrict access by IP, allow the [Prowler Cloud egress IPs](/security/networking).
|
||||
|
||||
### Authentication Failed
|
||||
### Authentication Fails or Times Out
|
||||
|
||||
*"Authentication failed. Please verify the StackSet deployment and Role ARN"*
|
||||
*"Authentication failed. Please verify the StackSet deployment and Role ARN"* or *"Authentication timed out"*
|
||||
|
||||
- Verify the management account role exists and was created in [Step 1](#step-1-create-the-management-account-role)
|
||||
- Confirm the trust policy includes the correct External ID from the wizard
|
||||
- Check the role has all Organizations discovery permissions listed in [Step 1](#step-1-create-the-management-account-role)
|
||||
- Double-check the Role ARN format and account ID for typos
|
||||
- Verify the deployment account role exists and is named exactly `ProwlerScan`.
|
||||
- Confirm the trust policy includes the correct External ID from the wizard.
|
||||
- Check the role has the Organizations discovery permissions listed in [Deploy the Roles Manually](#management-account-role).
|
||||
- Double-check the Role ARN format and account ID for typos.
|
||||
- Retry — the role can take up to **60 seconds** to propagate, and a second attempt often succeeds. For very large organizations (500+ accounts), allow extra time for discovery.
|
||||
|
||||
### Authentication Timed Out
|
||||
### Invalid Organization ID or Role ARN
|
||||
|
||||
*"Authentication timed out"*
|
||||
*"Must be a valid AWS Organization ID"* or *"Must be a valid IAM Role ARN"*
|
||||
|
||||
- Retry the authentication step — the second attempt often succeeds
|
||||
- Check for AWS API rate limiting on the Organizations service
|
||||
- For very large organizations (500+ accounts), allow extra time for discovery
|
||||
|
||||
### Connection Test Fails for All Accounts
|
||||
|
||||
No accounts pass the connection test.
|
||||
|
||||
- Verify the CloudFormation StackSet was deployed — complete [Step 2](#step-2-deploy-the-cloudformation-stackset) and wait for stack instances to reach **CREATE_COMPLETE**
|
||||
- Check that the **ExternalId** parameter in the StackSet matches the External ID shown in the Prowler wizard
|
||||
- If your accounts use IP-based IAM policies, allow [Prowler Cloud public IPs](/user-guide/tutorials/prowler-cloud-public-ips)
|
||||
|
||||
### Connection Test Fails for Some Accounts
|
||||
|
||||
Some accounts show a red icon while others pass.
|
||||
|
||||
- Expand the StackSet deployment to include the OUs containing the failing accounts
|
||||
- Suspended accounts cannot be scanned — deselect them and proceed
|
||||
- Ensure the [STS regional endpoint](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) is enabled in the account's region
|
||||
- After fixing, click **Test Connections** — only the failed accounts will be re-tested
|
||||
|
||||
### No Accounts Connected Successfully
|
||||
|
||||
*"No accounts connected successfully. Fix the connection errors and retry before launching scans."*
|
||||
|
||||
- Hover over the red icon on each account to see the specific error
|
||||
- Fix the underlying issues using the guidance above
|
||||
- Click **Test Connections** to retry
|
||||
- Organization ID format: `o-` followed by 10–32 lowercase alphanumeric characters (e.g., `o-abc123def4`).
|
||||
- Role ARN format: `arn:aws:iam::<12-digit-account-id>:role/ProwlerScan`.
|
||||
- Copy both directly from the AWS Console to avoid typos.
|
||||
|
||||
### Failed to Apply Discovery
|
||||
|
||||
*"Failed to apply discovery"*
|
||||
|
||||
- Check the `blocked_reasons` field for any blocked accounts
|
||||
- Retry the operation
|
||||
- If the error persists, contact [Prowler Support](mailto:support@prowler.com)
|
||||
- Check the `blocked_reasons` field for any blocked accounts and retry the operation.
|
||||
- If the error persists, contact [Prowler Support](mailto:support@prowler.com).
|
||||
|
||||
## Deploy the Roles Manually
|
||||
|
||||
The wizard's **Create Stack** button is the fastest path, but you can create both roles yourself — for example with Terraform or your own CloudFormation — and paste the management account Role ARN into [Step 2](#step-2-authenticate-with-your-management-account). Both roles must be named `ProwlerScan`, since Prowler expects a consistent role name across all accounts.
|
||||
|
||||
<Note>
|
||||
**Prefer Terraform?** You can deploy the ProwlerScan role across the organization with Terraform instead of CloudFormation. See the [StackSets deployment guide](/user-guide/providers/aws/organizations#deploying-prowler-iam-roles-across-aws-organizations) for the module.
|
||||
</Note>
|
||||
|
||||
### Management Account Role
|
||||
|
||||
The management account role lets Prowler discover your Organization structure — listing accounts, OUs, and hierarchy — and scan the management account itself. StackSets with service-managed permissions do not deploy to the management account, so this role is always created separately from the member-account StackSet.
|
||||
|
||||
1. Sign in to the [AWS IAM Console](https://console.aws.amazon.com/iam/) in your **management account** (or delegated administrator account).
|
||||
2. Go to **Roles > Create role** and select **Custom trust policy**.
|
||||
3. Paste the following trust policy, replacing `<YOUR_EXTERNAL_ID>` with the External ID shown in the Prowler wizard:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::232136659152:root"
|
||||
},
|
||||
"Action": "sts:AssumeRole",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"sts:ExternalId": "<YOUR_EXTERNAL_ID>"
|
||||
},
|
||||
"StringLike": {
|
||||
"aws:PrincipalArn": "arn:aws:iam::232136659152:role/prowler*"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
4. Attach the AWS managed policies **SecurityAudit** and **ViewOnlyAccess** so Prowler can scan the management account for security findings.
|
||||
5. Add an inline policy with the Organizations discovery permissions:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "ProwlerOrganizationDiscovery",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"organizations:DescribeAccount",
|
||||
"organizations:DescribeOrganization",
|
||||
"organizations:ListAccounts",
|
||||
"organizations:ListAccountsForParent",
|
||||
"organizations:ListOrganizationalUnitsForParent",
|
||||
"organizations:ListRoots",
|
||||
"organizations:ListTagsForResource"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "ProwlerStackSetManagement",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"organizations:RegisterDelegatedAdministrator",
|
||||
"iam:CreateServiceLinkedRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<Tip>
|
||||
You can restrict the `Resource` field to your specific Organization ARN (e.g., `arn:aws:organizations::123456789012:organization/o-abc123def4`) instead of `"*"` to minimize the blast radius.
|
||||
</Tip>
|
||||
|
||||
6. Name the role **`ProwlerScan`** and click **Create role**. The ARN follows the format `arn:aws:iam::<account-id>:role/ProwlerScan` — paste it into the wizard.
|
||||
|
||||
### Member Account Role (StackSet)
|
||||
|
||||
Deploy the ProwlerScan role to every member account with a [CloudFormation StackSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html), so you don't create the role manually in each account.
|
||||
|
||||
<Note>
|
||||
**Trusted access required.** CloudFormation StackSets must have trusted access enabled in your management account. Verify this under **AWS Organizations > Settings > Trusted access for AWS CloudFormation StackSets**.
|
||||
</Note>
|
||||
|
||||
1. In your management account, navigate to **CloudFormation > StackSets > Create StackSet** ([open directly](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacksets/create)).
|
||||
2. Choose **Service-managed permissions** so AWS Organizations deploys the role automatically across current and future member accounts.
|
||||
3. Select **Amazon S3 URL** as the template source and paste:
|
||||
```
|
||||
https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml
|
||||
```
|
||||
4. Set the **ExternalId** parameter to the External ID shown in the Prowler wizard.
|
||||
5. Choose your deployment targets (entire organization or specific OUs) and regions, then click **Create StackSet**.
|
||||
6. Open the **Stack instances** tab and confirm every instance shows **Status: CURRENT** and **Stack status: CREATE_COMPLETE**. Deployment typically takes **2–5 minutes**; large organizations (500+ accounts) may take longer.
|
||||
|
||||
The StackSet role uses read-only access only (`SecurityAudit`, `ViewOnlyAccess`, plus a small set of additional read-only permissions). Prowler makes no changes to your accounts. See the [CloudFormation template](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml) for the full list. When you add new accounts under the targeted OU or root, the StackSet deploys the role automatically, and Prowler's 6-hour sync onboards them end-to-end.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### What Is an External ID?
|
||||
|
||||
An **External ID** is a security token that Prowler generates unique to your tenant. When Prowler assumes the IAM role in your AWS account, it presents this External ID to prove its identity.
|
||||
|
||||
This prevents the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) — a scenario where an unauthorized party could trick AWS into granting access to your account. By requiring the External ID, only your specific Prowler tenant can assume the role. Prowler generates it automatically and displays it in the wizard for you to copy.
|
||||
|
||||
### Two Roles Architecture
|
||||
|
||||
Prowler uses **two IAM roles**, both named `ProwlerScan` but deployed in different places:
|
||||
|
||||
| Role | Where it lives | What it does |
|
||||
|------|---------------|--------------|
|
||||
| **ProwlerScan** (management account) | Your management (or delegated administrator) account | Discovers the Organization structure **and** scans that account. Includes additional Organizations discovery permissions. |
|
||||
| **ProwlerScan** (member accounts) | Every member account | Scans the account for security findings. |
|
||||
|
||||
Both roles share the name `ProwlerScan` because Prowler expects a consistent role name across all accounts. The single CloudFormation stack in [Step 2](#step-2-authenticate-with-your-management-account) deploys both at once.
|
||||
|
||||
<Frame caption="Both roles share the same name `ProwlerScan`. The management account role includes additional Organization discovery permissions.">
|
||||
<img src="/images/organizations/two-roles-architecture.svg" alt="Two Roles Architecture: ProwlerScan in management account (discovery + scanning) and ProwlerScan in member accounts (via StackSet, scanning only)" />
|
||||
</Frame>
|
||||
|
||||
### What Is a CloudFormation StackSet?
|
||||
|
||||
A [CloudFormation StackSet](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) deploys the same CloudFormation template across multiple AWS accounts in a single operation. Prowler uses a service-managed StackSet to deploy the **ProwlerScan** IAM role into every member account of your organization, so you don't create the role manually in each account. StackSets do not deploy to the management account, which is why that role is created separately.
|
||||
|
||||
## What's Next
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 'Azure Management Groups'
|
||||
description: 'Onboard all Azure subscriptions in your management groups through a single guided wizard'
|
||||
tag: "Coming Soon"
|
||||
---
|
||||
|
||||
Onboarding Azure management groups through a single guided wizard is coming soon to Prowler Cloud.
|
||||
|
||||
Today, Azure subscriptions are onboarded individually. See [Getting Started with Azure](/user-guide/providers/azure/getting-started-azure) and [Bulk Provider Provisioning](/user-guide/tutorials/bulk-provider-provisioning) to automate onboarding multiple subscriptions.
|
||||
|
||||
Keep an eye on the [changelog](https://github.com/prowler-cloud/prowler/releases) for updates.
|
||||
@@ -0,0 +1,442 @@
|
||||
---
|
||||
title: 'GCP Organizations'
|
||||
description: 'Onboard all GCP projects in your organization through a single guided wizard'
|
||||
---
|
||||
|
||||
import { VersionBadge } from "/snippets/version-badge.mdx"
|
||||
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
|
||||
|
||||
<VersionBadge version="5.37.0" />
|
||||
|
||||
Prowler Cloud onboards every Google Cloud project in your organization through a single guided wizard. Instead of connecting projects one by one, you can discover every folder and project under your Google Cloud organization, select the ones you want to monitor, test connectivity, and launch scans — all from the Prowler Cloud UI.
|
||||
|
||||
<SubscriptionBanner>
|
||||
For Command-Line Interface (CLI) scanning of a whole organization, see [Scanning a Specific GCP Organization](/user-guide/providers/gcp/organization).
|
||||
</SubscriptionBanner>
|
||||
|
||||
To follow this guide you need an active [Prowler Cloud](https://cloud.prowler.com) account and a Google Cloud credential with read access granted **at the organization node**.
|
||||
|
||||
## Overview
|
||||
|
||||
### Individual Projects vs Organizations
|
||||
|
||||
| Approach | Best for | How it works |
|
||||
|----------|----------|--------------|
|
||||
| **Individual projects** | A few Google Cloud projects | Connect each project one by one with its own credential. |
|
||||
| **GCP Organizations** | 10+ projects, or any organization-managed estate | Connect once with an organization-level credential, discover every folder and project automatically, and scan them in bulk. |
|
||||
|
||||
### How It Works
|
||||
|
||||
Onboarding runs in four stages:
|
||||
|
||||
1. **Grant read access** to one credential at your organization node, and enable the Cloud Resource Manager Application Programming Interface (API).
|
||||
2. **Discover** — Prowler walks your hierarchy through the Cloud Resource Manager API and returns every active folder and project.
|
||||
3. **Select and connect** — choose the projects to monitor. Prowler creates one provider per project and tests every connection.
|
||||
4. **Launch scans** — apply a scan schedule across the connected projects.
|
||||
|
||||
<Note>
|
||||
**No roles are deployed into your projects.** Unlike AWS Organizations onboarding, GCP onboarding deploys nothing in Google Cloud. Prowler reuses the organization credential you provide as the credential of every project it onboards, so a single grant covers discovery and scanning.
|
||||
</Note>
|
||||
|
||||
## Before You Start
|
||||
|
||||
### Grant Read Access at the Organization Node
|
||||
|
||||
Discovery reads three Cloud Resource Manager resources: the organization itself, the folders beneath it, and the projects in each folder. Grant these permissions to the credential **directly on the organization**, not on a project:
|
||||
|
||||
| Permission | Used for |
|
||||
|------------|----------|
|
||||
| `resourcemanager.organizations.get` | Reading the organization and its display name. |
|
||||
| `resourcemanager.folders.list` | Walking the folder hierarchy. |
|
||||
| `resourcemanager.projects.list` | Listing the projects in the organization and in every folder. |
|
||||
|
||||
The **Browser (`roles/browser`)** predefined role covers all three. Scanning each project additionally needs the permissions described in [GCP Authentication in Prowler](/user-guide/providers/gcp/authentication#required-permissions) — **Viewer (`roles/viewer`)**, **Service Usage Consumer (`roles/serviceusage.serviceUsageConsumer`)**, and the custom `ProwlerRole`. Binding those at the organization node too means every project you onboard is scannable without a per-project grant:
|
||||
|
||||
```bash
|
||||
ORG_ID=123456789012
|
||||
MEMBER="serviceAccount:prowler@<credentials-project-id>.iam.gserviceaccount.com"
|
||||
|
||||
# Discovery: read the organization, its folders, and its projects
|
||||
gcloud organizations add-iam-policy-binding "$ORG_ID" \
|
||||
--member="$MEMBER" --role="roles/browser"
|
||||
|
||||
# Scanning: read resources in every project under the organization
|
||||
gcloud organizations add-iam-policy-binding "$ORG_ID" \
|
||||
--member="$MEMBER" --role="roles/viewer"
|
||||
|
||||
gcloud organizations add-iam-policy-binding "$ORG_ID" \
|
||||
--member="$MEMBER" --role="roles/serviceusage.serviceUsageConsumer"
|
||||
```
|
||||
|
||||
### Enable the Cloud Resource Manager API
|
||||
|
||||
Enable the Cloud Resource Manager API in the project that owns the credential — the service account's host project, or the quota project for user credentials:
|
||||
|
||||
```bash
|
||||
gcloud services enable cloudresourcemanager.googleapis.com \
|
||||
--project <credentials-project-id>
|
||||
```
|
||||
|
||||
### Find Your Organization ID
|
||||
|
||||
Prowler identifies your organization by its numeric Google Cloud organization ID:
|
||||
|
||||
```bash
|
||||
gcloud organizations list
|
||||
```
|
||||
|
||||
In the Google Cloud console, the ID sits in the **ID** column next to the organization on the [Manage Resources](https://console.cloud.google.com/cloud-resource-manager) page, above the folders and projects it holds:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-console-org-id.png" alt="Manage Resources page in the Google Cloud console, with the organization ID highlighted next to the organization" />
|
||||
</Frame>
|
||||
|
||||
## Step 1: Start the Organization Wizard
|
||||
|
||||
### Open the Wizard
|
||||
|
||||
1. Navigate to **Providers** and click **Add Provider**.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/cloud-providers-add.png" alt="Providers page showing the Add Provider button" />
|
||||
</Frame>
|
||||
|
||||
2. Select **Google Cloud** as the provider.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/select-gcp-provider.png" alt="Provider selection modal with Google Cloud highlighted" />
|
||||
</Frame>
|
||||
|
||||
3. Choose **Add Multiple Projects With GCP Organization**.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/select-gcp-organizations-method.png" alt="Method selector showing Add Multiple Projects With GCP Organization option highlighted" />
|
||||
</Frame>
|
||||
|
||||
<Note>
|
||||
In Prowler Local Server the organization option is marked **Cloud** and opens an upgrade panel instead of the wizard. Organization-level onboarding is a Prowler Cloud feature; the single-project method remains available.
|
||||
</Note>
|
||||
|
||||
### Enter Organization Details
|
||||
|
||||
- **Organization ID**: the numeric ID of your Google Cloud organization (for example, `123456789012`). Non-numeric values are rejected before submission.
|
||||
- **Name** (optional): a display name for the organization in Prowler. If left blank, Prowler uses the name stored in Google Cloud.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-organization-details-form.png" alt="Organization Details form with the Google Cloud organization ID and Name fields" />
|
||||
</Frame>
|
||||
|
||||
Click **Next** to proceed to the authentication phase. Prowler matches the organization by ID, so submitting an organization that is already onboarded reuses it instead of creating a duplicate.
|
||||
|
||||
## Step 2: Authenticate with Google Cloud
|
||||
|
||||
The **Authentication Details** step collects the credential Prowler uses to read your hierarchy and, later, to scan each project. Choose one of two methods.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-authentication-details.png" alt="Authentication Details step showing the Service Account Key and Client ID methods" />
|
||||
</Frame>
|
||||
|
||||
### Service Account Key
|
||||
|
||||
Paste the full contents of a service account key file into **Service Account Key**. The field validates that the pasted text is a JSON object before submission.
|
||||
|
||||
To create the key for the service account you granted access to:
|
||||
|
||||
```bash
|
||||
gcloud iam service-accounts keys create prowler-key.json \
|
||||
--iam-account=prowler@<credentials-project-id>.iam.gserviceaccount.com
|
||||
```
|
||||
|
||||
### Client ID, Client Secret and Refresh Token
|
||||
|
||||
Use this method to authenticate as a Google account rather than a service account. It takes three values from an authorized-user credential:
|
||||
|
||||
- **Client ID**
|
||||
- **Client Secret**
|
||||
- **Refresh Token**
|
||||
|
||||
Running `gcloud auth application-default login` writes all three to `~/.config/gcloud/application_default_credentials.json`. The account must hold the roles listed in [Grant Read Access at the Organization Node](#grant-read-access-at-the-organization-node).
|
||||
|
||||
<Warning>
|
||||
Every project you onboard inherits this credential. Revoking it, rotating the key, or deleting the service account stops the scans of every project in the organization.
|
||||
</Warning>
|
||||
|
||||
### Authenticate and Discover
|
||||
|
||||
Click **Authenticate**. Prowler then:
|
||||
|
||||
- Creates the organization and stores the credential securely.
|
||||
- Triggers an asynchronous discovery that walks your hierarchy through the Cloud Resource Manager API.
|
||||
- Shows a **"Gathering GCP Projects..."** spinner while it waits.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-gathering-projects.png" alt="Gathering GCP Projects spinner shown while discovery runs" />
|
||||
</Frame>
|
||||
|
||||
Discovery usually takes seconds to a couple of minutes, depending on how many folders and projects your organization holds.
|
||||
|
||||
#### When Discovery Takes Too Long
|
||||
|
||||
Prowler waits up to **3 minutes** for a result. Past that, the wizard stops waiting — but the discovery keeps running in Google Cloud — and offers two actions:
|
||||
|
||||
- **Keep waiting** — resume the same discovery. Nothing is re-read from Google Cloud.
|
||||
- **Retry** — start a fresh discovery, which reads your hierarchy again.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-discovery-timeout.png" alt="Discovery timeout notice offering Keep waiting and Retry" />
|
||||
</Frame>
|
||||
|
||||
If discovery fails outright, the wizard explains why and offers **Retry discovery**. See [Troubleshooting](#troubleshooting) for each message.
|
||||
|
||||
## Step 3: Select Projects to Scan
|
||||
|
||||
### Understanding the Tree View
|
||||
|
||||
Once discovery completes, the wizard renders your organization as a hierarchical tree:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-tree-view-projects.png" alt="Hierarchical tree view showing folders and projects with selection checkboxes" />
|
||||
</Frame>
|
||||
|
||||
- **Folders** nest under the organization; projects created directly under the organization appear at the top level.
|
||||
- **Selecting a folder** selects every selectable project beneath it. A folder whose projects are only partly selected renders in an indeterminate state.
|
||||
- **Individual overrides**: deselect single projects even when the parent folder is selected.
|
||||
- The header tracks the selection as **"X of Y projects selected"**.
|
||||
- Only **ACTIVE** folders and projects appear. Projects pending deletion are not listed.
|
||||
- Folder hierarchies are read up to **10 levels** deep. Deeper organizations report an error at discovery — see [Troubleshooting](#troubleshooting).
|
||||
|
||||
### Blocked Projects
|
||||
|
||||
A project is shown grayed out and cannot be selected when onboarding it would conflict with something Prowler already stores. Hover the project to see the reason:
|
||||
|
||||
| Reason | What it means |
|
||||
|--------|---------------|
|
||||
| `organization_conflict` | The project is already connected under a **different** Prowler organization. |
|
||||
| `organization_node_conflict` | The project is already grouped under a different folder in Prowler — for example, it moved in Google Cloud after it was onboarded. |
|
||||
| `provider_type_conflict` | A provider with the same identifier exists in Prowler for another cloud provider. |
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-blocked-project.png" alt="Blocked project row with the reason shown in a tooltip" />
|
||||
</Frame>
|
||||
|
||||
### Folders With Nothing to Select
|
||||
|
||||
A folder that holds no projects, or whose projects are all blocked, is shown disabled with the note *"No projects available to select in this folder."* The folder still expands, so you can see the blocked projects it holds and why they are blocked.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-inert-folder.png" alt="Disabled folder row noting that no projects are available to select" />
|
||||
</Frame>
|
||||
|
||||
### Custom Aliases
|
||||
|
||||
Each project row carries an editable name, prefilled with the project's display name. The alias is used only inside Prowler — it does not rename anything in Google Cloud. Folder names are read-only: Prowler stores the folder display name from Google Cloud.
|
||||
|
||||
### Projects That Already Have Credentials
|
||||
|
||||
Applying your selection stores the organization credential on every selected project. When a selected project is already connected to Prowler with its own credential, that credential is **overwritten** — so the wizard asks first, naming the affected projects:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-replace-credentials-apply.png" alt="Replace existing credentials modal listing the projects whose credentials will be replaced" />
|
||||
</Frame>
|
||||
|
||||
Click **Replace and continue** to proceed, or **Cancel** to adjust your selection.
|
||||
|
||||
<Note>
|
||||
**Your existing data is safe.** A project already connected as an individual provider is **linked** to the organization, never duplicated: its historical scans and findings are preserved, and it does not count twice toward your subscription.
|
||||
</Note>
|
||||
|
||||
## Step 4: Test Connections
|
||||
|
||||
Click **Test Connections** to verify that Prowler can authenticate against each selected project. Prowler creates one provider per project — identified by its Google Cloud project ID — and then tests every connection.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-test-connections.png" alt="Connection testing in progress with status icons on each project" />
|
||||
</Frame>
|
||||
|
||||
Each project shows a real-time status indicator:
|
||||
|
||||
- **Spinner** — test in progress
|
||||
- **Green checkmark (✓)** — connection successful
|
||||
- **Red icon (✗)** — connection failed (hover to see the error)
|
||||
|
||||
If every project connects successfully, you advance to the next step automatically.
|
||||
|
||||
### When Some Tests Fail
|
||||
|
||||
An error banner appears: **"There was a problem connecting to some projects. Hover each project to check the error."** You have two options:
|
||||
|
||||
**a) Fix and retry:**
|
||||
|
||||
1. Confirm the credential holds **Viewer** and **Service Usage Consumer** on the failing projects (or on the organization).
|
||||
2. Confirm the Identity and Access Management (IAM) API is enabled as described in [GCP Authentication in Prowler](/user-guide/providers/gcp/authentication#project-level-settings).
|
||||
3. Click **Test Connections** again — only the **failed projects are re-tested**. Projects that already passed are not tested again.
|
||||
|
||||
**b) Skip and continue:**
|
||||
|
||||
Click **Skip Connection Validation** to proceed with the projects that connected successfully. Failed projects stay onboarded and visible on the Providers page, but they are not scanned. This option appears only when at least one project connected.
|
||||
|
||||
If **no project** connects, the banner instead reads *"No projects connected successfully. Fix the connection errors and retry before launching scans."* and you cannot proceed. Fix the underlying problem — see [Troubleshooting](#troubleshooting) — and retry.
|
||||
|
||||
## Step 5: Launch Scans
|
||||
|
||||
The Organizations wizard uses the same schedule controls described in [Scan Scheduling](/user-guide/tutorials/prowler-scan-scheduling#schedule-options).
|
||||
|
||||
Click **Save**, **Save and launch scan**, or **Launch scan**, depending on the selected schedule option. A toast notification confirms whether the schedule was saved, scans were launched, or both, and links to the **Scans** page. Prowler then redirects to the **Providers** page. Scans launch only for projects that passed connection testing.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-launch-scan.png" alt="Launch Scan step showing Projects Connected confirmation and the scan schedule selector" />
|
||||
</Frame>
|
||||
|
||||
After launching:
|
||||
|
||||
- Scans appear on the **Scans** page as they start and complete.
|
||||
- Results populate the **Overview** and **Findings** pages.
|
||||
- On the **Providers** page, your projects are grouped under the organization and, when they live in a folder, under that folder.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-providers-grouping.png" alt="Providers page showing projects grouped under GCP folders and the organization" />
|
||||
</Frame>
|
||||
|
||||
## Manage Your Organization After Onboarding
|
||||
|
||||
Open the row actions menu on the organization row on the **Providers** page.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-organization-row-actions.png" alt="Row actions menu on a GCP organization row" />
|
||||
</Frame>
|
||||
|
||||
| Action | What it does |
|
||||
|--------|--------------|
|
||||
| **Edit Organization Name** | Renames the organization in Prowler. Leave it blank to fall back to the name stored in Google Cloud. |
|
||||
| **Update Credentials** | Reopens the Authentication Details step to store a new credential. |
|
||||
| **Edit Scan Schedule** | Applies one schedule to every connected project in the organization. |
|
||||
| **Test Connections (N)** | Re-tests every project in the organization. |
|
||||
| **Delete Organization** | Deletes the organization and cascades to its providers. |
|
||||
|
||||
### Onboard Projects Created Later
|
||||
|
||||
Projects added to your Google Cloud organization after onboarding are not picked up automatically. Run the wizard again with the same organization ID: discovery returns the current hierarchy, already-connected projects come back preselected, and the new ones are ready to select.
|
||||
|
||||
### Update Organization Credentials
|
||||
|
||||
Choosing **Update Credentials** re-enters the Authentication Details step. Because the organization already holds a credential, Prowler warns before overwriting it and names how many providers re-authenticate with the new one:
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-replace-credentials-setup.png" alt="Replace existing credentials modal showing how many providers re-authenticate" />
|
||||
</Frame>
|
||||
|
||||
Storing a new credential runs a fresh discovery, so any discovery already in progress is discarded — discovery authenticates with the credential it started from.
|
||||
|
||||
### Delete an Organization or Folder
|
||||
|
||||
Deleting an organization or a folder **cascades to every provider grouped under it**, along with their scans and findings. Both dialogs state how many providers are affected before you confirm.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/organizations/gcp/gcp-delete-organization.png" alt="Delete organization dialog showing how many providers are deleted with it" />
|
||||
</Frame>
|
||||
|
||||
Deletion runs in the background. Prowler confirms with a **"Deletion started"** notification; if any part of it fails, the affected rows reappear on a later refresh.
|
||||
|
||||
<Danger>
|
||||
Deleting an organization **permanently deletes every project provider grouped under it**, including their historical scans and findings. This action cannot be undone.
|
||||
</Danger>
|
||||
|
||||
### When Grouping Is Unavailable
|
||||
|
||||
If Prowler cannot read your hierarchy while loading the Providers page, a notice reads *"Organization grouping is incomplete. Some providers may appear ungrouped."* Your providers are still listed, just flat. Reload the page to try again.
|
||||
|
||||
## Billing Impact
|
||||
|
||||
Each Google Cloud project you connect through the Organizations wizard counts as one **provider** in your Prowler Cloud subscription.
|
||||
|
||||
- **Already-connected projects**: linking an existing provider to the organization does **not** add billing. The existing provider is reused.
|
||||
- **Large organizations**: connecting a 500-project organization results in up to 500 providers on your subscription. Review your plan limits before proceeding.
|
||||
- **Deleted providers**: a project you later remove no longer counts toward your subscription.
|
||||
|
||||
For pricing details, see [Prowler Cloud Pricing](https://prowler.com/pricing).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### That Organization ID Is Not Valid
|
||||
|
||||
*"That organization ID is not valid. Copy the numeric ID from the Google Cloud console and try again."*
|
||||
|
||||
Google Cloud rejected the ID. Use only the digits — no `organizations/` prefix and no domain name. Run `gcloud organizations list` and copy the `ID` column.
|
||||
|
||||
### No Organization With That ID Was Found
|
||||
|
||||
*"No organization with that ID was found. Check the ID, and that the service account has been granted access to the organization."*
|
||||
|
||||
Either the ID belongs to another organization, or the credential cannot see this one. Confirm the binding was created **on the organization** and not on a project:
|
||||
|
||||
```bash
|
||||
gcloud organizations get-iam-policy <organization-id> \
|
||||
--flatten="bindings[].members" \
|
||||
--filter="bindings.members:<service-account-email>" \
|
||||
--format="table(bindings.role)"
|
||||
```
|
||||
|
||||
### The Service Account Cannot List Folders and Projects
|
||||
|
||||
*"The service account cannot list this organization's folders and projects. Grant it the Folder Viewer and Project Viewer roles at the organization level, then try again."*
|
||||
|
||||
The credential authenticated but lacks read access to the hierarchy. Grant **Browser (`roles/browser`)** at the organization node, as described in [Grant Read Access at the Organization Node](#grant-read-access-at-the-organization-node), and confirm the Cloud Resource Manager API is enabled in the credential's project.
|
||||
|
||||
### Authentication Failed
|
||||
|
||||
*"Authentication failed. Please verify the service account permissions or credentials, then try again."*
|
||||
|
||||
- For a service account key, confirm the key is still active and the pasted JSON is the full key file.
|
||||
- For client credentials, confirm the refresh token has not been revoked — `gcloud auth application-default login` issues a new one.
|
||||
- Confirm the service account itself is not disabled or deleted.
|
||||
|
||||
### Google Cloud Did Not Respond
|
||||
|
||||
*"Google Cloud did not respond while reading the organization. Nothing is wrong with your credentials — try again in a few minutes."*
|
||||
|
||||
A transient Cloud Resource Manager error. Click **Retry discovery**.
|
||||
|
||||
### The Folder Hierarchy Is Too Deep
|
||||
|
||||
*"This organization's folder hierarchy is deeper than Prowler can read. Contact support so we can help you onboard it."*
|
||||
|
||||
Prowler reads up to 10 levels of nested folders. Contact [Prowler Support](mailto:support@prowler.com).
|
||||
|
||||
### Discovery Never Finishes
|
||||
|
||||
The wizard stops waiting after 3 minutes, but the discovery keeps running in Google Cloud. Click **Keep waiting** to resume the same discovery rather than **Retry**, which starts over and re-reads your whole hierarchy.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### How Projects Map to Prowler Providers
|
||||
|
||||
Each selected project becomes one Prowler provider:
|
||||
|
||||
| Prowler field | Comes from |
|
||||
|---------------|------------|
|
||||
| Provider identifier | The Google Cloud project ID (for example, `prowler-prod-1`). |
|
||||
| Alias | The name you typed in the tree, or the project's display name. |
|
||||
| Credential | A copy of the organization credential. |
|
||||
|
||||
Folders that hold selected projects become grouping rows on the Providers page. You select projects only — Prowler derives the folder ancestors itself.
|
||||
|
||||
### Organization Credential vs Project Credential
|
||||
|
||||
One credential, stored twice: on the organization, where discovery reads it, and on each project provider, where scans read it. That is why replacing the organization credential re-authenticates every project under it, and why the wizard asks before overwriting a project's own credential.
|
||||
|
||||
## What's Next
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Prowler Cloud" icon="cloud" href="/user-guide/tutorials/prowler-app">
|
||||
Full guide to using Prowler Cloud features.
|
||||
</Card>
|
||||
<Card title="GCP Organizations (CLI)" icon="terminal" href="/user-guide/providers/gcp/organization">
|
||||
CLI-based scanning of a specific Google Cloud organization.
|
||||
</Card>
|
||||
<Card title="GCP Authentication" icon="key" href="/user-guide/providers/gcp/authentication">
|
||||
Credential types and the permissions Prowler needs in Google Cloud.
|
||||
</Card>
|
||||
<Card title="Bulk Provider Provisioning" icon="upload" href="/user-guide/tutorials/bulk-provider-provisioning">
|
||||
Script-based bulk provisioning for advanced automation.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: 'Prowler Cloud Public Egress IPs'
|
||||
description: 'Query the dedicated Prowler Cloud egress IPv4 address to allowlist scans across AWS, Azure, GCP, Kubernetes clusters, and other customer network controls.'
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Prowler Cloud uses a dedicated egress IPv4 address for all outbound connections to customer infrastructure. This enables organizations to implement network-level security controls by whitelisting Prowler's IP address.
|
||||
|
||||
## Use Cases
|
||||
|
||||
Whitelisting Prowler's egress IP address enables:
|
||||
|
||||
- **Credential Usage Control**: Restrict where cloud provider credentials can be used from across AWS, Azure, GCP, and other providers
|
||||
- **Kubernetes Security**: Limit inbound HTTPS traffic to clusters by allowing only Prowler's IP address
|
||||
- **Compliance Requirements**: Meet security policies requiring allowlisting of external services
|
||||
|
||||
## Query the Egress IP Address
|
||||
|
||||
Retrieve Prowler Cloud's current egress IP address using the following command:
|
||||
|
||||
```bash
|
||||
dig egress.prowler.com +short
|
||||
```
|
||||
|
||||
This command returns the IPv4 address that Prowler Cloud uses for all outbound connections to customer infrastructure.
|
||||
|
||||
<Note>
|
||||
The egress IP address is stable, but it is recommended to periodically verify it remains current by querying `egress.prowler.com`.
|
||||
</Note>
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Billing and Customer Plans in Prowler for MSPs and MSSPs"
|
||||
sidebarTitle: "Billing and Plans"
|
||||
---
|
||||
|
||||
Each customer carries its own billing plan, set when the customer is created and changed later from the **Customers** page. This page covers both, and where the resulting revenue is reported.
|
||||
|
||||
## Permissions
|
||||
|
||||
Managing customer plans requires a role with **Manage billing**, held today by both **Superadmin** and **Organization Admin**. See [Managing Your Team](/user-guide/tutorials/prowler-for-msps-team).
|
||||
|
||||
## Customer Plans
|
||||
|
||||
Plans are chosen in the **Set Their Billing Plan** step of the Add Customer wizard. A customer starts on a trial or on one of the paid plans, billed monthly or annually.
|
||||
|
||||
Each plan card in the wizard shows its own price, included usage and overage rate. For current pricing, see [prowler.com/pricing](https://prowler.com/pricing).
|
||||
|
||||
### Provider Accounts on the Annual Plan
|
||||
|
||||
The annual plan is paid upfront for a fixed number of cloud provider accounts, between **1 and 20**. You set that count when you pick the plan. The monthly plan does not require an upfront provider account count.
|
||||
|
||||
## Change a Customer's Plan
|
||||
|
||||
Open the actions menu on a customer's row and choose **Change plan**.
|
||||
|
||||
<Warning>
|
||||
**Plan changes are one way: trial to paid.** The action is only offered while a customer is on trial or its trial has expired. Once a customer holds a paid subscription, **Change plan** no longer appears on the row, and the trial is never a valid target.
|
||||
</Warning>
|
||||
|
||||
The **Change Plan** dialog opens on **Choose your plan**, with the same **Monthly** and **Annual** toggle used when the customer was created.
|
||||
|
||||
|
||||
|
||||
Select a plan and confirm with **Change Plan**. Choosing the annual plan also asks for the upfront provider account count. The change is submitted to Prowler Cloud and applied asynchronously; the customer's row updates once it lands. If it fails, use the reported problem to identify the cause:
|
||||
|
||||
| Problem | Cause |
|
||||
|---|---|
|
||||
| Cloud accounts count is required | The annual plan was selected without a provider account count. |
|
||||
| Cloud accounts count out of range | The count is outside 1–20. |
|
||||
| Company name is required | The customer record has no usable company name. |
|
||||
| Customer not found | The customer no longer exists or is not linked to a tenant. |
|
||||
|
||||
## Revenue Reporting
|
||||
|
||||
Billing figures surface in two places.
|
||||
|
||||
**On the Customers page**, stat cards above the table summarize **Billing active** — how many customers hold an active subscription — and **Total MTD** per currency, with a percentage change against last month. The cards appear once a customer has billing activity.
|
||||
|
||||
|
||||
|
||||
**On the Dashboard**, the **Billing Overview** card reports monthly expenses against the previous month and splits revenue for the period into annual, monthly and overage, giving the same picture across every customer.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Onboarding Customers" icon="building" href="/user-guide/tutorials/prowler-for-msps-customers">
|
||||
Add customers and open their Prowler Cloud tenants.
|
||||
</Card>
|
||||
<Card title="Your Partner Organization" icon="briefcase" href="/user-guide/tutorials/prowler-for-msps-organization">
|
||||
Lifecycle, settings, Partner Code and closing your organization.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Customizing Your Branding in Prowler for MSPs and MSSPs"
|
||||
sidebarTitle: "Branding"
|
||||
---
|
||||
|
||||
Upload and save your company logo, then preview its intended placement alongside Prowler branding. Branding is managed from **Settings → Branding** and requires a role with **Manage settings**.
|
||||
|
||||
## Upload a Logo
|
||||
|
||||
Open **Settings → Branding**, click **Upload Logo**, and pick your file. The logo replaces the placeholder in Settings immediately and a confirmation appears.
|
||||
|
||||
|
||||
|
||||
### Logo Requirements
|
||||
|
||||
| Requirement | Value |
|
||||
|---|---|
|
||||
| **Formats** | PNG or SVG |
|
||||
| **Maximum file size** | 512 KB |
|
||||
| **Dimensions** | 200 × 60 pixels — a hard limit for PNG, not checked for SVG |
|
||||
|
||||
<Warning>
|
||||
Two limits on this screen are looser than what the server accepts:
|
||||
|
||||
* The upload dialog accepts files up to 1 MB, but anything above **512 KB** is rejected.
|
||||
* The page describes 200 × 60 pixels as a recommended size. For PNG it is a **maximum**: a larger PNG is rejected with *"PNG dimensions must not exceed 200×60 px."* SVG is exempt from the dimension check.
|
||||
|
||||
Keep PNG logos within both limits to avoid an upload that appears to start and then fails.
|
||||
</Warning>
|
||||
|
||||
A wide, horizontal logo with a transparent background renders best. SVG stays crisp at every size, is not subject to the dimension limit, and is the better choice where you have it.
|
||||
|
||||
<Note>
|
||||
Uploaded SVG files are sanitized on the server. Scripts, external references and other active content are stripped before the file is stored.
|
||||
</Note>
|
||||
|
||||
## Replace or Remove a Logo
|
||||
|
||||
Uploading a new file replaces the saved logo. **Remove Logo** deletes it and returns the Settings preview to the *Your Logo* placeholder.
|
||||
|
||||
## Logo Placement Preview
|
||||
|
||||
Below the upload controls, **Logo Placement Preview** renders your logo underneath the Prowler wordmark to show the intended placement. With no logo uploaded, the slot shows a *Your Logo* placeholder.
|
||||
|
||||
<Note>
|
||||
The saved logo is currently displayed only in the upload area and placement preview on this Settings page. It is not applied elsewhere in Partner Portal, Prowler Cloud or customer reports.
|
||||
</Note>
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Your Partner Organization" icon="briefcase" href="/user-guide/tutorials/prowler-for-msps-organization">
|
||||
Lifecycle, settings, Partner Code and closing your organization.
|
||||
</Card>
|
||||
<Card title="Managing Your Team" icon="users" href="/user-guide/tutorials/prowler-for-msps-team">
|
||||
Invite team members and assign roles.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: "Onboarding Customers and Accessing Their Tenants"
|
||||
sidebarTitle: "Onboarding Customers"
|
||||
---
|
||||
|
||||
Adding a customer in Prowler for MSPs and MSSPs provisions a Prowler Cloud tenant for that organization and links it to yours. From then on you can open that tenant from the console and work inside it on the customer's behalf.
|
||||
|
||||
## Add a Customer
|
||||
|
||||
If you are a Superadmin, select **Customers** in the sidebar, then click **Add Customer** to open a three-step wizard.
|
||||
|
||||
<Note>
|
||||
In the Partner Portal UI, the **Add Customer** action is currently shown to Superadmins. Organization Admins manage existing customers but do not see the action.
|
||||
</Note>
|
||||
|
||||
<Steps>
|
||||
<Step title="Create A Customer Profile">
|
||||
Enter the **Customer Business Name** and confirm the **Region**. The name must be unique within your partner organization; a duplicate is rejected inline. Click **Next**.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Set Their Billing Plan">
|
||||
Under **Choose your plan**, switch between **Monthly** and **Annual** and pick the plan the customer starts on. Click **Create Customer**. See [Billing and Customer Plans](/user-guide/tutorials/prowler-for-msps-billing) for what the annual plan asks for.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Launch Their Customer Workspace">
|
||||
Wait while the tenant is created and linked to your organization. A banner then confirms that the customer was created on trial or that paid-plan enrollment was submitted. Click **Go To Organization** to head straight there and start connecting cloud providers, or **Close** to return to the customer list.
|
||||
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Customer creation waits for tenant provisioning to finish. A successful submission adds the customer as **Active**. If you selected a paid plan, enrollment continues asynchronously and the billing status updates when it completes.
|
||||
|
||||
## The Customers View
|
||||
|
||||
**My Customers** lists every customer you can reach.
|
||||
|
||||
|
||||
|
||||
Each row carries:
|
||||
|
||||
| Column | What it shows |
|
||||
|---|---|
|
||||
| **Customer Business Name** | The customer's name |
|
||||
| **Providers** | Icons for each cloud provider connected in their tenant |
|
||||
| **Cloud Accounts** | Number of provider accounts under scan |
|
||||
| **Resources** | Resources discovered by the latest scan |
|
||||
| **Failed Findings** | Failed findings from the latest scan |
|
||||
| **Billing Type** | The customer's current plan, shown as **Trial**, **Pro Monthly** or **Pro Annual** |
|
||||
| **MTD** | Month-to-date spend |
|
||||
| **Last Month Expenses** | Previous month's total |
|
||||
| **Status** | The customer's current status |
|
||||
| **Last scan completed** | When the most recent scan finished |
|
||||
|
||||
Above the table, search by name and filter by provider or status. The download button at the top right of the table exports the list.
|
||||
|
||||
## Open a Customer's Prowler Cloud Tenant
|
||||
|
||||
Open the actions menu at the end of a customer's row and choose **Access Organization**. You are redirected into that customer's tenant in Prowler Cloud, signed in as yourself acting on their behalf.
|
||||
|
||||
While you are in the tenant you see what a customer administrator sees, and every action is recorded in the Prowler Cloud audit log against both your identity and the customer you are acting for.
|
||||
|
||||
Opening a tenant requires a role with **Access tenants**. The action fails with a clear message if you lack permission, if the customer no longer exists, or if the tenant is not ready.
|
||||
|
||||
|
||||
|
||||
**Change plan** only appears while the customer is on trial or its trial has expired. See [Billing and Customer Plans](/user-guide/tutorials/prowler-for-msps-billing).
|
||||
|
||||
## Edit a Customer
|
||||
|
||||
Choose **Edit** from the row actions to open the **Edit customer** panel and rename the customer. The new name must still be unique within the partner organization.
|
||||
|
||||
## Link an Existing Customer with Your Partner Code
|
||||
|
||||
Each approved partner organization carries a **Partner Code**, shown on **Settings → Profile** with the helper text *"Share this code with customers to link their accounts."* A customer who already runs Prowler Cloud can use that code to request a link to you, rather than having you provision a fresh tenant.
|
||||
|
||||
<Note>
|
||||
The customer-side flow that consumes the Partner Code is rolling out progressively in Prowler Cloud. Confirm availability with your Prowler contact before sharing the code.
|
||||
</Note>
|
||||
|
||||
## Customer Self-Access
|
||||
|
||||
Your customers keep signing in to [cloud.prowler.com](https://cloud.prowler.com) with their own users. Your access is additive — it neither replaces nor restricts theirs.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Billing and Customer Plans" icon="credit-card" href="/user-guide/tutorials/prowler-for-msps-billing">
|
||||
Customer plans and revenue reporting.
|
||||
</Card>
|
||||
<Card title="Managing Your Team" icon="users" href="/user-guide/tutorials/prowler-for-msps-team">
|
||||
Invite team members and assign roles.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: "Managing Your Partner Organization"
|
||||
sidebarTitle: "Your Partner Organization"
|
||||
---
|
||||
|
||||
Your partner organization is the top-level container in Prowler for MSPs and MSSPs. It holds your team, your branding, your Partner Code and every customer whose Prowler Cloud tenant you operate.
|
||||
|
||||
## Lifecycle
|
||||
|
||||
A partner organization moves through four states:
|
||||
|
||||
| State | Meaning |
|
||||
|---|---|
|
||||
| **Pending email verification** | The first administrator has signed up but has not yet clicked the verification link. |
|
||||
| **Pending approval** | Email verified. Prowler is reviewing the application. |
|
||||
| **Active** | Approved. The organization can sign in, invite team members and onboard customers. |
|
||||
| **Rejected** | Prowler reviewed and declined the application. The account cannot sign in. |
|
||||
|
||||
A rejection email carries the reason, categorized as **Incomplete documentation**, **Not eligible**, **Duplicate** or **Other**.
|
||||
|
||||
## Settings
|
||||
|
||||
Open **Settings** from the sidebar. The tabs depend on your role. Users with **Manage settings** see **Profile**, **Branding**, **Security** and a disabled **Notifications** tab. Users without **Manage settings** see only **Security**.
|
||||
|
||||
Every signed-in user can change their own password. Editing the organization itself requires a role with **Manage settings**.
|
||||
|
||||
### Profile
|
||||
|
||||
The **Profile** tab shows the **Partner Information** card: your organization name, its current status, the date it joined, the Partner Code and an editable **Company Name**.
|
||||
|
||||
|
||||
|
||||
* **Partner Code** — a read-only, Prowler-issued identifier in the form `PRW-00000`. The helper text reads *"Share this code with customers to link their accounts."* Copy it with the button at the end of the row.
|
||||
* **Company Name** — the display name used in the console, in invitations and in outbound email. Edit it and click **Save Changes**.
|
||||
|
||||
### Branding
|
||||
|
||||
Upload your logo. See [Customizing Your Branding](/user-guide/tutorials/prowler-for-msps-branding).
|
||||
|
||||
### Security
|
||||
|
||||
Change your own password. Users with **Manage settings** can also see the Danger zone described below, but only the partner owner can submit a deletion request. An Organization Admin sees the password form only.
|
||||
|
||||
## Customer Capacity
|
||||
|
||||
Each partner organization has a cap on how many customers it can hold at once. The default is **50**. To raise it, contact Prowler.
|
||||
|
||||
## Closing Your Organization
|
||||
|
||||
Deleting a partner organization is a request, not an immediate action.
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the Danger zone">
|
||||
Go to **Settings → Security**. The Danger zone requires **Manage settings**, and submitting its **Delete Partner** request is restricted to the partner owner.
|
||||
</Step>
|
||||
|
||||
<Step title="File the request">
|
||||
Enter a required **Reason for deletion**. The UI accepts 10–1000 characters, and the API rejects reasons shorter than 10 characters. Then type `DELETE` in the confirmation field to enable the button and submit.
|
||||
</Step>
|
||||
|
||||
<Step title="Wait for review">
|
||||
Filing the request notifies the Prowler team and sends a confirmation to the requester. The Danger zone then reports that a deletion request is already pending review. You and your team keep full access while it is pending.
|
||||
</Step>
|
||||
|
||||
<Step title="Offboard with Prowler">
|
||||
The Prowler team coordinates the offboarding from there, including what happens to each customer tenant and when your organization is closed. Closing removes the partner organization, its team memberships and its branding assets, and invalidates every session.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Note>
|
||||
Closing a partner organization does not delete customer data in Prowler Cloud on its own. The Prowler team confirms the handling of each customer tenant as part of the offboarding.
|
||||
</Note>
|
||||
|
||||
## Ownership
|
||||
|
||||
One user is the **owner** of the partner organization — by default, whoever signed up. Ownership transfer is Prowler-assisted rather than self-service: contact Prowler to request it. Prowler staff can transfer ownership only when the partner has no customer organizations and the target is an active Superadmin. The previous owner keeps the Superadmin role, and the current owner cannot be removed from the team while they hold ownership.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Managing Your Team" icon="users" href="/user-guide/tutorials/prowler-for-msps-team">
|
||||
Invite team members and assign roles.
|
||||
</Card>
|
||||
<Card title="Customizing Your Branding" icon="palette" href="/user-guide/tutorials/prowler-for-msps-branding">
|
||||
Upload your logo.
|
||||
</Card>
|
||||
<Card title="Onboarding Customers" icon="building" href="/user-guide/tutorials/prowler-for-msps-customers">
|
||||
Add customers and open their Prowler Cloud tenants.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: "Sign Up and Sign In to Prowler for MSPs and MSSPs"
|
||||
sidebarTitle: "Sign Up and Sign In"
|
||||
---
|
||||
|
||||
Sign-up for Prowler for MSPs and MSSPs is self-service, but activation requires approval from the Prowler team. The first administrator registers the partner organization; every other team member joins by invitation.
|
||||
|
||||
## Sign Up
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the sign-up page">
|
||||
Go to [partners.prowler.com/sign-up](https://partners.prowler.com/sign-up), fill in **Full name**, **Company name**, **Email**, **Password** and **Confirm password**, then click **Create account**.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Verify your email">
|
||||
Prowler sends a verification email containing a one-time link valid for **24 hours**. Click it to confirm the address; your partner organization then moves to **Pending approval**.
|
||||
|
||||
If the link expires, request a new one at [partners.prowler.com/resend-verification](https://partners.prowler.com/resend-verification). Issuing a fresh link invalidates any earlier unused link for the same account.
|
||||
</Step>
|
||||
|
||||
<Step title="Wait for approval">
|
||||
Prowler reviews every new application. You receive an email when the organization is approved — its status becomes **Active** — or when it is rejected, along with the reason.
|
||||
</Step>
|
||||
|
||||
<Step title="Sign in">
|
||||
Once approved, sign in at [partners.prowler.com](https://partners.prowler.com) with the email and password you chose. You land on the Dashboard.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Password Requirements
|
||||
|
||||
Every password in the console — at sign-up, when accepting an invitation, and on reset — must satisfy all of the following:
|
||||
|
||||
| Requirement | Rule |
|
||||
|---|---|
|
||||
| **Length** | At least 12 characters |
|
||||
| **Uppercase** | At least 1 uppercase letter |
|
||||
| **Lowercase** | At least 1 lowercase letter |
|
||||
| **Number** | At least 1 digit |
|
||||
| **Special character** | At least 1 special character |
|
||||
| **Not common** | Rejected if it appears on the common-password list |
|
||||
|
||||
## Sign In
|
||||
|
||||
Sign in at [partners.prowler.com](https://partners.prowler.com) with your email and password, then click **Login**.
|
||||
|
||||
|
||||
|
||||
Sign-in fails while the partner organization is not yet active:
|
||||
|
||||
| Message | What it means |
|
||||
|---|---|
|
||||
| Invalid email or password | The credentials do not match an account. |
|
||||
| Please verify your email before signing in | Email verification is still outstanding. Open the verification email or request a fresh link. |
|
||||
| Your partner application is still under review | Prowler has not approved the application yet. |
|
||||
| Your partner application was not approved | The application was rejected. The account cannot sign in. |
|
||||
|
||||
## Reset a Forgotten Password
|
||||
|
||||
Click **Forgot Password?** on the sign-in screen and enter your email. Prowler sends a reset link valid for **15 minutes**. The reset page asks for a new password and a confirmation; on success you return to sign-in.
|
||||
|
||||
<Note>
|
||||
The confirmation banner appears whether or not the email matches an account, so the screen never reveals which addresses are registered. Requesting a new link invalidates any earlier unused one.
|
||||
</Note>
|
||||
|
||||
## Sessions
|
||||
|
||||
Portal sessions currently use a sliding **23-hour** lifetime. Continued use may renew the session window, but you should expect to sign in again after extended inactivity. Selecting **Remember me** does not provide a seven-day Portal session.
|
||||
|
||||
If session refresh or validation fails, you are redirected to the sign-in screen. Sign in again to continue.
|
||||
|
||||
## Sign Out
|
||||
|
||||
Open the user avatar in the top-right corner of any page and select **Sign out**. The session is cleared and you return to the sign-in form.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Managing Your Team" icon="users" href="/user-guide/tutorials/prowler-for-msps-team">
|
||||
Invite team members and assign roles.
|
||||
</Card>
|
||||
<Card title="Your Partner Organization" icon="briefcase" href="/user-guide/tutorials/prowler-for-msps-organization">
|
||||
Lifecycle, settings, Partner Code and closing your organization.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: "Managing Your Team in Prowler for MSPs and MSSPs"
|
||||
sidebarTitle: "Managing Your Team"
|
||||
---
|
||||
|
||||
Each partner organization has its own team and its own role catalog. Administrators invite team members by email and assign each one a role that governs what they can do.
|
||||
|
||||
## Roles
|
||||
|
||||
Two roles ship with every partner organization:
|
||||
|
||||
* **Superadmin** — full account management. Invites members, adds and manages customers, edits branding and settings, and opens customer tenants.
|
||||
* **Organization Admin** — manages customers and billing, and opens customer tenants. Cannot invite members, change organization settings, or add new customers.
|
||||
|
||||
Each role is a set of permission flags:
|
||||
|
||||
| Permission | What it allows | Superadmin | Organization Admin |
|
||||
|---|---|:---:|:---:|
|
||||
| **Manage members** | Invite, re-invite, disable, enable and remove team members | ✓ | |
|
||||
| **Manage settings** | Edit the organization profile and branding | ✓ | |
|
||||
| **Manage billing** | Manage customer plans | ✓ | ✓ |
|
||||
| **Manage organizations** | Edit existing customer details | ✓ | ✓ |
|
||||
| **Access tenants** | Open a customer's Prowler Cloud tenant | ✓ | ✓ |
|
||||
|
||||
<Note>
|
||||
The Prowler Cloud-side permission level for a team member is provisioned automatically as **Manager** and is managed in Prowler Cloud, not here. There is no Cloud role to pick at invitation time.
|
||||
</Note>
|
||||
|
||||
## Invite a Team Member
|
||||
|
||||
<Steps>
|
||||
<Step title="Open Team">
|
||||
Select **Team** in the sidebar. The entry only appears for roles with **Manage members**.
|
||||
</Step>
|
||||
|
||||
<Step title="Send the invitation">
|
||||
Click **Invite User**, enter the **Email**, pick a **User Role**, then click **Send Invite**. Each role option in the selector carries a one-line description of what it grants.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Track the invitation">
|
||||
The team table lists **Name**, **Email**, **Role**, **Status** and **User Event** for members and pending invitations. A pending invitation may display as **Expired** after its expiry passes. Accepted invitations become member rows, while revoked invitations are no longer shown.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
The invitee receives an email with a one-time link, valid for **7 days**, that opens a public acceptance page. There they set their full name and a password, accept, and are sent to the sign-in screen.
|
||||
|
||||
An email address can hold only one pending invitation at a time.
|
||||
|
||||
## Re-Invite or Revoke
|
||||
|
||||
For a **Pending** or **Expired** invitation, **Re-invite** sends a fresh link and resets the expiry. **Revoke** invalidates the invitation immediately — the recipient can no longer accept it.
|
||||
|
||||
To re-issue an invitation that is still pending, use **Re-invite** rather than sending a second one.
|
||||
|
||||
## Disable, Enable or Remove a Member
|
||||
|
||||
Active members carry a **Disable** action. Disabling revokes access immediately but keeps the row in the table, flagged as disabled, so the audit trail survives.
|
||||
|
||||
A disabled member can be:
|
||||
|
||||
* **Enabled** — access is restored as it was.
|
||||
* **Re-invited** — a fresh invitation brings them back as a new active member. The invite dialog opens pre-filled with their address and its title changes to **Re-invite user**.
|
||||
|
||||
<Warning>
|
||||
The organization owner cannot be removed from the team while they hold ownership. Transfer ownership first.
|
||||
</Warning>
|
||||
|
||||
## Notes
|
||||
|
||||
* The first administrator is created during sign-up and becomes the owner.
|
||||
* An email address can hold only one active membership in a given partner organization.
|
||||
* Permissions are scoped to one partner organization. A session for one organization carries no permissions in another.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Onboarding Customers" icon="building" href="/user-guide/tutorials/prowler-for-msps-customers">
|
||||
Add customers and open their Prowler Cloud tenants.
|
||||
</Card>
|
||||
<Card title="Billing and Customer Plans" icon="credit-card" href="/user-guide/tutorials/prowler-for-msps-billing">
|
||||
Customer plans and revenue reporting.
|
||||
</Card>
|
||||
</Columns>
|
||||
@@ -133,7 +133,7 @@ Only **Detection Finding** (`class_uid: 2004`) records are accepted. Other OCSF
|
||||
|
||||
The **Manage Ingestions** RBAC permission controls access to the ingestion endpoints. Without this permission, findings cannot be submitted via the API or `--push-to-cloud`.
|
||||
|
||||
For more information about RBAC permissions, refer to the [Prowler App RBAC documentation](/user-guide/tutorials/prowler-app-rbac).
|
||||
For more information about RBAC permissions, refer to the [Prowler Cloud RBAC documentation](/user-guide/tutorials/prowler-app-rbac).
|
||||
|
||||
## Using the CLI
|
||||
|
||||
|
||||
@@ -21,11 +21,11 @@ Before creating or editing scan schedules, ensure that:
|
||||
|
||||
## Schedule Options
|
||||
|
||||
A Prowler Cloud or Enterprise subscription supports the following custom recurring schedule options. Prowler self-hosted runs a daily scan automatically and does not expose custom cadence controls.
|
||||
A Prowler Cloud or Prowler Private Cloud subscription supports the following custom recurring schedule options. Prowler Local Server runs a daily scan automatically and does not expose custom cadence controls.
|
||||
|
||||
| Schedule Option | Description | Cloud & Enterprise | Self-Hosted |
|
||||
|-----------------|-------------|--------------------|-------------|
|
||||
| Daily | Runs one scan every day at the selected time. | Yes | Yes |
|
||||
| Schedule Option | Description | Prowler Cloud & Prowler Private Cloud | Prowler Local Server |
|
||||
|-----------------|-------------|---------------------------------------|----------------------|
|
||||
| Daily | Runs one scan every day at the selected time. | Yes | Automatic |
|
||||
| Every 48 hours | Runs one scan every 48 hours, anchored to the selected time. | Yes | — |
|
||||
| Weekly | Runs one scan every week on the selected day and time. | Yes | — |
|
||||
| Monthly | Runs one scan every month on the selected day, from day 1 to day 28. | Yes | — |
|
||||
@@ -84,7 +84,7 @@ To bulk edit provider schedules:
|
||||
4. Click **Edit Scan Schedule (N)**, where **N** is the number of selected providers.
|
||||
5. Save the schedule.
|
||||
|
||||
For AWS Organizations and Organizational Unit rows, **Edit Scan Schedule** applies the schedule to the connected child providers in that group.
|
||||
For organization rows and their grouping rows — AWS organizational units, GCP folders — **Edit Scan Schedule** applies the schedule to the connected child providers in that group.
|
||||
|
||||
<Warning>
|
||||
Bulk schedule edits apply one schedule to every selected provider. If the wrong providers are selected, Prowler applies the same cadence to unintended providers. To recover, reopen bulk edit with the correct selection or update affected provider schedules individually.
|
||||
|
||||
@@ -17,7 +17,7 @@ checks_v4_v3_to_v2_mapping = {
|
||||
"apigateway_restapi_public": "extra745",
|
||||
"apigateway_restapi_logging_enabled": "extra722",
|
||||
"apigateway_restapi_waf_acl_attached": "extra744",
|
||||
“apigatewayv2_api_access_logging_enabled": "extra7156",
|
||||
"apigatewayv2_api_access_logging_enabled": "extra7156",
|
||||
"apigatewayv2_api_authorizers_enabled": "extra7157",
|
||||
"appstream_fleet_default_internet_access_disabled": "extra7193",
|
||||
"appstream_fleet_maximum_session_duration": "extra7190",
|
||||
|
||||
Reference in new issue
Block a user