ben.carrasco/prowler
1
0 Fork 0
mirror of https://github.com/prowler-cloud/prowler.git synced 2026-10-29 06:44:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge master

Browse Source
This commit is contained in:
mintlify-bot committed 2026-08-10 07:45:51 +00:00
2 parents abc5bedc45 3ca3a977a9
commit aecac60c12
2428 files changed
+134745 -24745
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/user-guide/ai-agents/claude-code.mdx
+294
View File
@@ -0,0 +1,294 @@
---
title: "Connect Claude Code to Prowler MCP Server"
sidebarTitle: "Claude Code"
---
Connect [Claude Code](https://www.claude.com/product/claude-code) to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp`.
## Where Claude Code Runs
Claude Code runs in two places. Both read the same configuration file, so you set it up **once from a terminal** and it works in both.
| Surface | How you open it | Reads | Covered by |
|---|---|---|---|
| **Claude Code CLI** | `claude` in a terminal | `~/.claude.json` | This guide |
| **Claude Code in the desktop app** | The **Code** tab inside the Claude app | `~/.claude.json` — the same file | This guide, [set up from a terminal](#claude-code-in-the-desktop-app-code-tab) |
| **Claude app Chat** | The **Chat** tab inside the Claude app | `claude_desktop_config.json` | [Claude App Chat](/user-guide/ai-agents/claude-desktop) — a separate setup |
<Warning>
**The Chat tab is not Claude Code.** It is a different product surface with its own configuration file and its own connection method (a local bridge). Nothing on this page applies to it. If you want Prowler in Chat, use the [Claude App Chat](/user-guide/ai-agents/claude-desktop) guide instead.
</Warning>
## Choose Your Setup
There are two ways to connect. Both end with the same MCP Server connection, the difference is what comes with it.
| | 🔌 **Prowler Plugin** | ⚙️ **MCP Connection Only** |
|---|---|---|
| **What you get** | The MCP connection **plus** the official Prowler skills for cloud security tasks | The MCP connection |
| **Setup** | Two slash commands, prompts for the API key | One `claude mcp add` command |
| **Guided workflows** | ✅ Skills drive multi-step security work end to end | ❌ You drive the conversation |
| **Best for** | Structured cloud security work, such as taking an account to compliance | Ad-hoc queries and your own workflows |
| **Where to use it** | Claude Code CLI | Claude Code CLI, and the **recommended setup for the desktop app's [Code tab](#claude-code-in-the-desktop-app-code-tab)** |
<Note>
**The plugin already includes the MCP connection.** If you install the plugin, do **not** also run `claude mcp add` — you would end up with the server configured twice.
</Note>
## Prerequisites
- **Claude Code** installed and signed in. See the [official install guide](https://www.claude.com/product/claude-code).
- **A Prowler Cloud account.** The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
## Get Your Prowler API Key
Create an API key in Prowler Cloud and copy it. The key begins with `pk_` and is shown only once. Check the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide for details.
---
# Option 1: Install the Prowler Plugin
<Warning>
**Preview**: this plugin is under active development. Please report issues on [GitHub](https://github.com/prowler-cloud/prowler/issues) or join the [Slack community](https://goto.prowler.com/slack) for feedback.
</Warning>
End-to-end cloud security from inside Claude Code, powered by the Prowler MCP server. The plugin bundles the official Prowler skills, task-specific workflows that let Claude carry out multi-step security work against a Prowler Cloud-connected account, rather than answering one question at a time.
### Included Skills
| Skill | What it does |
| --- | --- |
| `prowler:framework-compliance-triage` | Walks an account through a compliance assessment and remediates findings until the chosen security or industry framework is compliant. |
<Note>
More skills are on the way. Installing the plugin keeps you current — new skills arrive with plugin updates, no extra configuration required.
</Note>
## Installation (Claude Code CLI)
<Tabs>
<Tab title="From GitHub (recommended)">
Inside a Claude Code session:
```text
/plugin marketplace add prowler-cloud/prowler
/plugin install prowler@prowler-plugins
```
</Tab>
<Tab title="From a local clone">
If you already have the repository checked out:
```text
/plugin marketplace add /absolute/path/to/prowler
/plugin install prowler@prowler-plugins
```
</Tab>
</Tabs>
On first install, Claude Code prompts for your **Prowler API key**. The value is stored securely (macOS keychain or `~/.claude/.credentials.json`) and used to authenticate against Prowler Cloud.
## Verify the Installation
In a Claude Code session:
```text
/mcp → "prowler" appears as a connected server
/plugin → "prowler" enabled, with the bundled Prowler skills listed
```
If `/mcp` reports the `prowler` server as failed, the most common cause is a rejected API key, re-issue one in Prowler Cloud and reinstall the plugin so it re-prompts.
## Usage
Describe the security task you want done and Claude selects the matching skill.
### Framework Compliance Triage
Mention the framework you want to comply with:
- *"Make my AWS production account compliant with CIS 4.0."*
- *"Make my current Terraform project compliant with Prowler ThreatScore Compliance Framework based on the latest scan results."*
- *"Help me get to 100% on PCI-DSS for this GCP project."*
You pick a **primary tool** (Terraform, gh / az / aws CLI, web console, or mixed) and a **mode**:
<CardGroup cols={2}>
<Card title="Claude-assisted (default)" icon="hand">
Claude shows each fix — target resource, exact commands, side effects, reversibility — and waits for your go-ahead before applying.
</Card>
<Card title="Claude autonomous" icon="robot">
Claude presents a single up-front plan grouped by shared fixes, waits for one confirmation, then proceeds. It pauses mid-loop if a fix has wide blast radius or a finding is not applicable.
</Card>
</CardGroup>
Claude tracks progress in a markdown report under `.prowler/` at your project root — one file per framework × account. Open it any time to see exactly where the flow is. When all findings are addressed, Claude proposes a fresh Prowler scan to verify everything end-to-end.
## Uninstalling
```text
/plugin uninstall prowler@prowler-plugins
/plugin marketplace remove prowler-plugins
```
The stored API key is removed automatically.
---
# Option 2: Connect the MCP Server Only
Choose this when you want Prowler's tools available without the Prowler skills.
## Add the Server
Claude Code connects to remote HTTP MCP servers natively and supports custom headers, so no bridge is required.
```bash
export PROWLER_API_KEY="pk_your_api_key_here"
claude mcp add --transport http prowler https://mcp.prowler.com/mcp \
--header "Authorization: Bearer $PROWLER_API_KEY" \
--scope user
```
<Frame>
<img src="/images/prowler-mcp/claude/claude-code-mcp-add.png" alt="Terminal showing the claude mcp add command and its confirmation output" />
</Frame>
<Warning>
**Always pass `--scope user`.** The default scope is `local`, which binds the server to the single directory you ran the command in. A locally-scoped server does not load when you open Claude Code anywhere else — this is the most common reason Prowler tools appear to vanish.
</Warning>
| Scope | Loads in | Shared | Stored in |
|-------|----------|--------|-----------|
| `user` | All your projects | No | `~/.claude.json`, top-level `mcpServers` |
| `project` | Current project only | Yes, via version control | `.mcp.json` in the project root |
| `local` (default) | Current project only | No | `~/.claude.json`, under that project's entry |
When the same server name exists in more than one scope, precedence is **local → project → user**. The winning entry is used whole; fields are not merged.
<Warning>
Avoid `--scope project` for Prowler. That writes `.mcp.json` into your repository, and committing the file would publish your API key.
</Warning>
<Note>
**Local server:** Replace the URL with your own HTTP endpoint. Everything else stays the same.
</Note>
## Verify the Connection
```bash
claude mcp get prowler # shows which scope holds the definition
claude mcp list # lists all servers and their status
```
Inside a Claude Code session, run `/mcp` to see connected servers and their tools.
<Frame>
<img src="/images/prowler-mcp/claude/claude-code-mcp-command.png" alt="Claude Code session showing the /mcp command output with the Prowler server connected" />
</Frame>
## Start Using Prowler MCP
- *"Show me all critical findings from my AWS accounts"*
- *"What does the S3 bucket public access check do?"*
- *"Onboard this new AWS account in my Prowler organization"*
<Frame>
<img src="/images/prowler-mcp/claude/claude-code-prowler-query.png" alt="Claude Code answering a question about critical findings using Prowler MCP tools" />
</Frame>
---
# Claude Code in the Desktop App (Code Tab)
The **Code** tab in the Claude desktop app runs the same Claude Code as the CLI, and reads the same `~/.claude.json`. There is no separate Prowler setup for it — you configure it **from a terminal** and the Code tab picks it up.
<Note>
**Use [Option 2](#option-2-connect-the-mcp-server-only) with `--scope user` here.** It is the recommended setup for the Code tab. The Prowler plugin ([Option 1](#option-1-install-the-prowler-plugin)) is not the recommended route for the desktop app — install it in the Claude Code CLI instead.
</Note>
<Warning>
**You cannot do this from inside the app.** The desktop app has no interface for adding an MCP server to a Claude Code session. **Settings → Connectors** configures the **Chat** tab, not the **Code** tab, so anything added there never reaches Claude Code. Trying to configure it from the app is the main reason this appears not to work.
</Warning>
<Steps>
<Step title="Add the server at user scope from a terminal">
In a normal terminal — not inside the app:
```bash
export PROWLER_API_KEY="pk_your_api_key_here"
claude mcp add --transport http prowler https://mcp.prowler.com/mcp \
--header "Authorization: Bearer $PROWLER_API_KEY" \
--scope user
```
`--scope user` is what makes this work. It writes to `~/.claude.json`, the file the Code tab reads.
</Step>
<Step title="Confirm it landed at user scope">
```bash
claude mcp get prowler
```
The scope must be `user`. A `local`-scoped server is bound to the directory you ran the command in and will not load in an app session opened elsewhere.
</Step>
<Step title="Restart the Claude app">
Quit the app completely and reopen it. Configuration is read at startup.
</Step>
<Step title="Verify in the Code tab">
Open a **Code** tab session and ask for a Prowler tool: "Do you have access to the Prowler MCP tools?", it should respond with a list of available tools or confirming that it has access.
</Step>
</Steps>
---
# Claude App Chat (Chat Tab)
Not covered by this page. The **Chat** tab is a separate surface: it does not read `~/.claude.json`, so a server added with `claude mcp add` appears in the CLI and in the Code tab but **never** in Chat. That is expected behavior, not a broken setup.
Chat reads `claude_desktop_config.json` and reaches the Prowler MCP Server through a local bridge.
<Card title="Connect the Claude App Chat" icon="comment" href="/user-guide/ai-agents/claude-desktop" horizontal>
Separate guide: local bridge and its own configuration file
</Card>
---
# Troubleshooting
| Symptom | Likely cause | Fix |
| --- | --- | --- |
| `/mcp` shows `prowler` as failed | Rejected API key | Generate a new one in Prowler Cloud. With the plugin, reinstall it to re-prompt. |
| No MCP servers configured | Server added at `local` scope from another directory | Run `claude mcp get prowler`, then re-add with `--scope user`. |
| A stale entry overrides a working one | Precedence is local → project → user | `claude mcp remove prowler --scope local` |
| Tools appear in the CLI but not in the app's **Code** tab | Server added at `local` scope, or the app was not restarted | Re-add with `--scope user`, then quit and reopen the app. See [Claude Code in the Desktop App](#claude-code-in-the-desktop-app-code-tab). |
| Tools appear in the **Code** tab but not the **Chat** tab | Chat is a different surface with its own config file | Expected. Set Chat up separately, see [Claude App Chat](/user-guide/ai-agents/claude-desktop). |
| No way to add the server from inside the app | The app has no MCP interface for Claude Code sessions | Configure it from a terminal with `--scope user`, then restart the app. See [Claude Code in the Desktop App](#claude-code-in-the-desktop-app-code-tab). |
| Skill not invoked when expected | The prompt didn't match any skill's description | Name the task explicitly. For compliance triage, mention the framework plus "compliance" or "compliant". |
| "Framework not supported" | Prowler Hub does not list the framework for that provider | Open an issue or PR at [github.com/prowler-cloud/prowler](https://github.com/prowler-cloud/prowler). |
### Authentication Fails With 401
- Confirm the header value includes the `Bearer ` prefix.
- Check that `PROWLER_API_KEY` was set when you ran `claude mcp add` — the shell expands it at that moment and stores the resulting literal value. If the variable was empty, the stored header reads `Bearer ` with nothing after it. Verify with `claude mcp get prowler`.
- Confirm the key has not been revoked in Prowler Cloud.
## Next Steps
<CardGroup cols={2}>
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
Explore all available tools and capabilities
</Card>
<Card title="All MCP Clients" icon="plug" href="/getting-started/basic-usage/prowler-mcp">
Configuration reference for every supported client
</Card>
</CardGroup>
## Getting Help
- Search for existing [GitHub issues](https://github.com/prowler-cloud/prowler/issues)
- Ask for help in our [Slack community](https://goto.prowler.com/slack)
- Report a new issue on [GitHub](https://github.com/prowler-cloud/prowler/issues/new)
docs/user-guide/ai-agents/claude-desktop.mdx
+142
View File
@@ -0,0 +1,142 @@
---
title: "Connect the Claude App Chat to Prowler MCP Server"
sidebarTitle: "Claude App (Chat)"
---
Connect the **Chat** tab of the Claude desktop app to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp`.
<Warning>
**This page covers the Chat tab only.** Looking for **Claude Code** — either the CLI or the app's **Code** tab? Those are a different surface, with a different configuration file and a different connection method. See [Connect Claude Code](/user-guide/ai-agents/claude-code).
</Warning>
## Prerequisites
- **Claude desktop app** installed and signed in.
- **Node.js and npm**, to install the bridge.
- **A Prowler Cloud account.** The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
## Why "Add Custom Connector" Does Not Work
The app's **Settings → Connectors → Add custom connector** dialog is the obvious place to paste an MCP URL, but it does not fit the Prowler Cloud MCP Server for two independent reasons:
1. **Connectors authenticate with OAuth.** Authenticating with a fixed API key sent as a request header is a separate mechanism that Anthropic documents as **beta**, rolled out on request. Without it, the dialog offers a URL and OAuth client credentials, with nowhere to supply `Authorization: Bearer pk_...`.
2. **Connectors do not connect from your machine.** Claude reaches your MCP server from Anthropic's cloud infrastructure rather than your local device. A Prowler MCP Server on `localhost`, behind a VPN, or restricted by an IP allowlist is unreachable that way regardless of authentication.
Use a local bridge instead, as described below.
## Step 1: Get Your Prowler API Key
Create an API key in Prowler Cloud and copy it. The key begins with `pk_` and is shown only once. Check the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide for details.
## Step 2: Install the Bridge
`mcp-remote` presents the remote HTTP server to Claude as a local STDIO server and injects the `Authorization` header. Install a pinned version into a dedicated directory:
```bash
mkdir -p ~/.local/share/prowler-mcp-bridge
cd ~/.local/share/prowler-mcp-bridge
npm init -y
npm install --save-exact mcp-remote@0.1.38
```
<Warning>
Do not configure Claude to run `npx mcp-remote` directly. `npx` can fetch and execute a new version on every launch, which means unreviewed code runs with access to your API key. Install a pinned version and point Claude at the installed binary.
</Warning>
<Note>
`mcp-remote` is community-maintained and is not an Anthropic product. Review it before use.
</Note>
## Step 3: Edit the Configuration File
In the Claude app, go to **Settings → Developer** and click **Edit Config**. This reveals `claude_desktop_config.json`:
- **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
- **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
<Frame>
<img src="/images/prowler-mcp/claude/claude-desktop-developer-settings.png" alt="Claude app Settings Developer tab showing the Edit Config button" />
</Frame>
Add the following, replacing the `command` path with the absolute path to the installed binary and the placeholder with your API key:
```json
{
"mcpServers": {
"prowler": {
"command": "/absolute/path/to/.local/share/prowler-mcp-bridge/node_modules/.bin/mcp-remote",
"args": [
"https://mcp.prowler.com/mcp",
"--header",
"Authorization: Bearer ${PROWLER_API_KEY}"
],
"env": {
"PROWLER_API_KEY": "pk_your_api_key_here"
}
}
}
}
```
<Note>
**Local server:** Replace the URL with your own HTTP endpoint. Everything else stays the same.
</Note>
## Step 4: Restart the App
Quit the Claude app completely and reopen it. Configuration is read at startup.
## Step 5: Start Using Prowler MCP
Open a Chat conversation and ask questions that use the Prowler tools:
- *"Show me all critical findings from my AWS accounts"*
- *"What does the S3 bucket public access check do?"*
- *"Summarize my CIS compliance status by provider"*
<Frame>
<img src="/images/prowler-mcp/claude/claude-desktop-prowler-tools.png" alt="Claude app chat showing the Prowler MCP tools available" />
</Frame>
## Troubleshooting
### Server Does Not Appear After Editing the Config
- Quit and reopen the app entirely — closing the window is not enough on macOS.
- Confirm `claude_desktop_config.json` is valid JSON.
- Confirm the `command` path points at a real executable. A wrong path surfaces as the server failing to start rather than as an auth error.
### Tools Appear in Claude Code but Not in Chat
Expected. The Chat tab does not read `~/.claude.json`, so servers added with `claude mcp add` never appear here. The Chat tab needs an entry in `claude_desktop_config.json`, which is what this guide sets up.
### Authentication Fails With 401
- Confirm the header value includes the `Bearer ` prefix.
- Confirm the key has not been revoked in Prowler Cloud.
### Checking the Logs
- **macOS:** `~/Library/Logs/Claude/mcp*.log`
- **Windows:** `%APPDATA%\Claude\logs\mcp*.log`
```bash
tail -f ~/Library/Logs/Claude/mcp*.log
```
## Next Steps
<CardGroup cols={2}>
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
Explore all available tools and capabilities
</Card>
<Card title="All MCP Clients" icon="plug" href="/getting-started/basic-usage/prowler-mcp">
Configuration reference for every supported client
</Card>
</CardGroup>
## Getting Help
- Search for existing [GitHub issues](https://github.com/prowler-cloud/prowler/issues)
- Ask for help in our [Slack community](https://goto.prowler.com/slack)
- Report a new issue on [GitHub](https://github.com/prowler-cloud/prowler/issues/new)
docs/user-guide/ai-agents/codex.mdx
+188
View File
@@ -0,0 +1,188 @@
---
title: "Connect Codex / ChatGPT Desktop to Prowler MCP Server"
sidebarTitle: "Codex / ChatGPT"
---
Connect [OpenAI Codex](https://learn.chatgpt.com/docs/extend/mcp) to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp` so Codex can query findings, inspect checks, and manage your Prowler providers.
## Which Codex Surfaces Work
Codex keeps MCP servers in one file, `~/.codex/config.toml`. You can set it up from either the **Codex / ChatGPT desktop app** or the **Codex CLI** — both write to that same file, so pick whichever you already use.
| Surface | Set it up here | Notes |
|---------|----------------|-------|
| **[Codex / ChatGPT desktop app](https://learn.chatgpt.com/docs/app)** (macOS, Windows) | ✅ Yes | **Settings → MCP servers** |
| **Codex CLI** (terminal) | ✅ Yes | `codex mcp` commands |
| **Codex IDE extension** (VS Code) | Inherits | Works automatically once the app or CLI is configured |
| **ChatGPT on the web** | ❌ No | Does not read local Codex configuration |
<Note>
**Codex and ChatGPT share one desktop app.** Since July 2026 the standalone Codex app and the ChatGPT desktop app are the same application: Codex is a dedicated coding surface inside it, alongside Chat and Work. If you already had the Codex app, updating turns it into the new ChatGPT desktop app and it still opens in Codex. Either way, this guide applies.
Not to be confused with **ChatGPT Classic**, the name given to the previous-generation ChatGPT desktop app.
</Note>
<Note>
**Configure once, use everywhere.** The Codex documentation states that the ChatGPT desktop app, Codex CLI, and IDE extension "share this configuration. Once you configure your MCP servers, you can switch among those clients without redoing setup." Set the server up in the app or the CLI and the IDE extension picks it up with no extra work.
</Note>
## Prerequisites
- **The Codex / ChatGPT desktop app, or Codex CLI 0.46.0 or later.** Remote MCP servers over streamable HTTP were added to the CLI in 0.46.0 — check with `codex --version` and upgrade if needed.
- **A Prowler Cloud account.** The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
## Step 1: Get Your Prowler API Key
Create an API key in Prowler Cloud and copy it. The key begins with `pk_` and is shown only once. Check the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide for details.
## Step 2: Add the Prowler MCP Server
The Prowler MCP Server needs two request headers: `Authorization` to authenticate you, and `User-Agent` because Codex does not send one by default.
Each tab below is a complete setup — follow the one that matches the surface you use.
<Tabs>
<Tab title="Codex / ChatGPT desktop app">
1. Open **Settings** and select **Plugins → MCPs**
2. Click **Add server**
3. Enter `prowler` as the name and choose type **Streamable HTTP**
4. Enter the URL `https://mcp.prowler.com/mcp`
5. Add two headers:
| Header | Value |
|--------|-------|
| `Authorization` | `Bearer pk_your_api_key_here` |
| `User-Agent` | `codex` |
6. Save the server
<Frame>
<img src="/images/prowler-mcp/codex/codex-app-mcp-servers.png" alt="Codex / ChatGPT desktop app Settings showing the MCP servers panel with the Add server dialog and both headers filled in" />
</Frame>
<Note>
**Enter the key directly here rather than using an environment variable.** Codex can read credentials from an environment variable, but desktop applications do not reliably inherit variables exported in a shell profile — on macOS an app launched from Finder or the Dock typically sees none of them. Pasting the key into the dialog is the approach that works consistently in the app.
</Note>
<Warning>
**This stores your API key in plain text** in `~/.codex/config.toml`. Treat that file accordingly: exclude it from dotfile repositories and config sync, and create the key from an account with the minimum permissions you need so its exposure is limited. Revoke and re-issue the key in Prowler Cloud if the file is ever shared.
</Warning>
</Tab>
<Tab title="Codex CLI">
Register the server:
```bash
codex mcp add prowler --url https://mcp.prowler.com/mcp
```
Codex confirms with `Added global MCP server 'prowler'.`
Then add both headers by hand, since `codex mcp add` has no flag for headers. Open `~/.codex/config.toml` and complete the entry:
```toml
[mcp_servers.prowler]
url = "https://mcp.prowler.com/mcp"
http_headers = { Authorization = "Bearer pk_your_api_key_here", "User-Agent" = "codex" }
```
<Note>
**Write the key literally rather than using an environment variable.** This is the form that works across every Codex surface. All of them read this same file, but only the CLI reliably sees variables exported in your shell profile — see the warning below.
</Note>
<Warning>
**This stores your API key in plain text** in `~/.codex/config.toml`. Treat that file accordingly: exclude it from dotfile repositories and config sync, and create the key from an account with the minimum permissions you need so its exposure is limited. Revoke and re-issue the key in Prowler Cloud if the file is ever shared.
</Warning>
</Tab>
</Tabs>
Restart Codex once you are done.
<Note>
**Local server:** Replace the URL with your own HTTP endpoint. Everything else stays the same.
</Note>
## Step 3: Verify the Connection
Run `/mcp` in the app or in a CLI session to list connected servers and their tools.
<Frame>
<img src="/images/prowler-mcp/codex/codex-mcp-slash-command.png" alt="Codex composer showing the /mcp command output with Prowler tools listed" />
</Frame>
From the CLI you can also inspect the stored entry directly:
```bash
codex mcp list # one row per server, with status and auth
codex mcp get prowler # full entry, header values masked
```
<Warning>
**Verify rather than assume.** Codex silently ignores unrecognized keys in `config.toml` — a misspelled key name produces no error at all, and the server simply never receives your credentials. Always confirm with `codex mcp get prowler` after editing the file by hand.
</Warning>
## Step 4: Start Using Prowler MCP
Ask Codex questions that use the Prowler tools:
- *"Show me all critical findings from my AWS accounts"*
- *"What does the S3 bucket public access check do?"*
- *"List my connected Prowler providers and their last scan date"*
<Frame>
<img src="/images/prowler-mcp/codex/codex-prowler-query.png" alt="Codex answering a question about critical findings using Prowler MCP tools" />
</Frame>
## Troubleshooting
### Startup Fails With HTTP 403 Forbidden
Codex reports a handshake failure on startup, with an HTML error page rather than a JSON response:
```
⚠ MCP client for `prowler` failed to start: MCP startup failed: handshaking with MCP server
failed: ... unexpected server response: HTTP 403: <html>
<head><title>403 Forbidden</title></head>
```
The `User-Agent` header is missing. Codex's HTTP client does not send one, and requests without it are rejected before reaching the MCP server. Note this is a **403**, not a 401 — so it is not an API key problem. Add the header as shown in [Step 2](#step-2-add-the-prowler-mcp-server); the value itself does not matter, only that the header is present.
### Authentication Fails With 401
- Run `codex mcp get prowler` and confirm the entry has the headers you expect. Values are masked, but a missing header shows as `-`.
- If you used a literal header, confirm the value starts with `Bearer ` and contains the full key.
- **If it works in the CLI but fails in the desktop app or the VS Code extension, you are almost certainly using an environment variable.** Those surfaces do not inherit your shell profile. Switch that entry to a literal `Authorization` header as shown in [Step 2](#step-2-add-the-prowler-mcp-server).
- If you use an environment variable, verify it is set in the environment Codex was launched from: `echo $PROWLER_API_KEY`.
- With `env_http_headers` the variable must include the `Bearer ` prefix. With `bearer_token_env_var` it must **not** — Codex adds the prefix itself.
- Confirm the key has not been revoked in Prowler Cloud.
### Server Not Listed
- Confirm your Codex CLI version is 0.46.0 or later with `codex --version`.
- Run `codex mcp get prowler`. If it reports the server is not found, the entry was not written or the TOML table name is misspelled.
- Check for a typo in the key names. Codex ignores unknown keys without warning.
### Project-Scoped Config Is Ignored
A `.codex/config.toml` inside a project is loaded **only when the project is trusted**. If your entry lives there and does nothing, trust the project or move the entry to `~/.codex/config.toml`.
### Tools Do Not Appear After Editing the Config
Restart Codex. Configuration is read at startup. In the app, quit completely and reopen it, sometimes just closing the window is not enough.
## Next Steps
<CardGroup cols={2}>
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
Explore all available tools and capabilities
</Card>
<Card title="All MCP Clients" icon="plug" href="/getting-started/basic-usage/prowler-mcp">
Configuration reference for every supported client
</Card>
</CardGroup>
## Getting Help
- Search for existing [GitHub issues](https://github.com/prowler-cloud/prowler/issues)
- Ask for help in our [Slack community](https://goto.prowler.com/slack)
- Report a new issue on [GitHub](https://github.com/prowler-cloud/prowler/issues/new)
docs/user-guide/ai-agents/cursor.mdx
+171
View File
@@ -0,0 +1,171 @@
---
title: "Connect Cursor to Prowler MCP Server"
sidebarTitle: "Cursor"
---
Connect [Cursor](https://cursor.com/docs/mcp) to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp` so the Cursor agent can query findings, inspect security checks, and manage your Prowler providers while you work.
Cursor supports remote MCP servers over HTTP natively, so no bridge or local installation is required.
## Prerequisites
- **Cursor** installed and authenticated. See the [official install guide](https://cursor.com/download).
- **A Prowler Cloud account.** The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
## Step 1: Get Your Prowler API Key
Create an API key in Prowler Cloud and copy it. The key begins with `pk_` and is shown only once. Check the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide for details.
## Step 2: Add the Prowler MCP Server
Cursor reads MCP servers from an `mcp.json` file. Choose the scope that fits your use case:
| Scope | File | Applies to |
|-------|------|------------|
| **Global** | `~/.cursor/mcp.json` | Every project you open in Cursor |
| **Project** | `.cursor/mcp.json` in the project root | That project only |
Both files are merged. If the same server name appears in both, the project-level entry takes priority.
For Prowler, the **global** scope is usually the right choice — your findings are not tied to a single repository, and it keeps the API key out of any project directory that might be committed.
<Steps>
<Step title="Open the MCP settings">
From Agent Window open **Customize** in the Cursor sidebar, then select the MCP section.
On earlier versions, press `Cmd + Shift + J` (macOS) or `Ctrl + Shift + J` (Windows/Linux) to open Cursor Settings, then click **Tools & MCP** in the sidebar.
</Step>
<Step title="Add a new MCP server">
Click **New MCP Server** (or **Add Custom MCP**). Cursor opens `mcp.json` in the editor.
<Frame>
<img src="/images/prowler-mcp/cursor/cursor-customize-page.png" alt="Cursor Customize page with the MCP section open" />
</Frame>
</Step>
<Step title="Add the Prowler configuration">
Paste the following, replacing the placeholder with your API key:
```json
{
"mcpServers": {
"prowler": {
"url": "https://mcp.prowler.com/mcp",
"headers": {
"Authorization": "Bearer <your-api-key-here>"
}
}
}
}
```
Save the file. Cursor picks up the change and connects to the server.
<Frame>
<img src="/images/prowler-mcp/cursor/cursor-mcp-json.png" alt="Cursor editor showing the completed mcp.json with the Prowler server entry" />
</Frame>
</Step>
</Steps>
<Note>
**Local server:** Replace the URL with your own HTTP endpoint. Everything else stays the same.
</Note>
### Keeping the API Key Out of the File
Cursor resolves variables in the `command`, `args`, `env`, `url`, and `headers` fields, so you can reference an environment variable instead of writing the key into `mcp.json`:
```json
{
"mcpServers": {
"prowler": {
"url": "https://mcp.prowler.com/mcp",
"headers": {
"Authorization": "Bearer ${env:PROWLER_API_KEY}"
}
}
}
}
```
Export the variable in your shell profile (`~/.zshrc`, `~/.bashrc`, or equivalent):
```bash
export PROWLER_API_KEY="pk_your_api_key_here"
```
<Note>
The syntax is `${env:NAME}`, not a bare `${NAME}`. Restart Cursor after changing your shell profile so it inherits the new value.
</Note>
<Warning>
The `envFile` option does **not** work for remote servers — it is STDIO-only. Use `${env:...}` interpolation with variables set in your shell profile instead.
</Warning>
This form is strongly recommended when using a **project-scoped** `.cursor/mcp.json`, since that file may be committed to version control.
## Step 3: Verify the Connection
Return to the MCP settings. The `prowler` server should be listed as enabled, with the Prowler tools shown beneath it.
<Frame>
<img src="/images/prowler-mcp/cursor/cursor-prowler-connected.png" alt="Cursor MCP settings showing the Prowler server connected with its tools listed" />
</Frame>
## Step 4: Start Using Prowler MCP
Open the chat panel and ask questions that use the Prowler tools:
- *"Show me all critical findings from my AWS accounts"*
- *"What does the S3 bucket public access check do?"*
- *"Which of my providers failed the most CIS checks in the last scan?"*
Cursor asks for approval before running an MCP tool the first time.
<Frame>
<img src="/images/prowler-mcp/cursor/cursor-prowler-query.png" alt="Cursor chat answering a question about critical findings using Prowler MCP tools" />
</Frame>
You can toggle individual tools on or off from the tools list at the top of the chat panel, which is useful for keeping the active tool count down.
## Troubleshooting
### Server Does Not Connect
- Check that `mcp.json` is valid JSON. A trailing comma or missing brace prevents the whole file from loading.
- Open **MCP Logs** in the Output panel for the specific error.
- Confirm the URL is exactly `https://mcp.prowler.com/mcp`.
### Authentication Fails With 401
- Verify the header value includes the `Bearer ` prefix: `"Bearer pk_..."`, not just the key.
- Confirm the key has not been revoked in Prowler Cloud.
- If using `${env:PROWLER_API_KEY}`, check the variable is set in the environment Cursor inherits. Restart Cursor after editing your shell profile — a value exported only in an already-open terminal will not reach the app.
### The Entire `mcp.json` Is Ignored
Remove any `"type": "streamable-http"` field. One such entry causes the Cursor CLI to drop every server in the file silently.
### Some Prowler Tools Are Missing
Cursor limits how many tools it exposes to the agent at once. With several MCP servers enabled you may exceed it, and some tools become unavailable. Disable servers you are not using, or turn off individual tools from the chat panel's tools list.
## Next Steps
<CardGroup cols={2}>
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
Explore all available tools and capabilities
</Card>
<Card title="All MCP Clients" icon="plug" href="/getting-started/basic-usage/prowler-mcp">
Configuration reference for every supported client
</Card>
</CardGroup>
## Getting Help
- Search for existing [GitHub issues](https://github.com/prowler-cloud/prowler/issues)
- Ask for help in our [Slack community](https://goto.prowler.com/slack)
- Report a new issue on [GitHub](https://github.com/prowler-cloud/prowler/issues/new)
docs/user-guide/ai-agents/index.mdx
+49
View File
@@ -0,0 +1,49 @@
---
title: "Connect Your AI Agent to Prowler"
sidebarTitle: "Overview"
description: "Pick your AI agent and follow its guide to connect it to the Prowler Cloud MCP Server."
---
Connect your AI agent to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp` so it can query findings, inspect security checks, and manage your Prowler providers.
Pick your agent below. Each guide is a full walkthrough with screenshots, verification steps, and the caveats specific to that client.
<CardGroup cols={2}>
<Card title="Claude Code" icon="terminal" href="/user-guide/ai-agents/claude-code">
Plugin and MCP-only choices, and which Claude surfaces work
</Card>
<Card title="Claude Desktop App (Chat)" icon="comment" href="/user-guide/ai-agents/claude-desktop">
The Chat tab, via a local bridge
</Card>
<Card title="Codex / ChatGPT Desktop App" icon="code" href="/user-guide/ai-agents/codex">
ChatGPT Desktop App, Codex CLI, the VS Code extension through same config file
</Card>
<Card title="Cursor" icon="arrow-pointer" href="/user-guide/ai-agents/cursor">
Agentic code editor. Global and project scopes
</Card>
<Card title="VS Code / Copilot" icon="microsoft" href="/user-guide/ai-agents/vscode">
Agent mode with secure key prompts
</Card>
</CardGroup>
## Before You Start
All guides need the same two things:
- A **Prowler Cloud account** with at least one cloud provider connected. [Sign up](https://cloud.prowler.com) if you do not have one.
- A **Prowler API key**, created in Prowler Cloud. The key begins with `pk_` and is shown only once. See the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide.
<Note>
Using an agent that is not listed here? Any MCP-compatible client can connect. See the [generic configuration reference](/getting-started/basic-usage/prowler-mcp#cloud-mcp-server-configuration-recommended) for the raw connection details.
</Note>
## Next Steps
<CardGroup cols={2}>
<Card title="What Is Prowler MCP" icon="cloud" href="/getting-started/products/prowler-mcp">
How the MCP Server fits into Prowler
</Card>
<Card title="Configuration Reference" icon="gear" href="/getting-started/basic-usage/prowler-mcp">
Cloud and local server options, all clients
</Card>
</CardGroup>
docs/user-guide/ai-agents/vscode.mdx
+145
View File
@@ -0,0 +1,145 @@
---
title: "Connect VS Code and GitHub Copilot to Prowler MCP Server"
sidebarTitle: "VS Code / Copilot"
---
Connect [Visual Studio Code](https://code.visualstudio.com/docs/agents/reference/mcp-configuration) and GitHub Copilot agent mode to the Prowler Cloud MCP Server at `https://mcp.prowler.com/mcp` so Copilot can query findings, inspect security checks, and manage your Prowler providers.
## Prerequisites
- **VS Code 1.102 or later.** MCP support became generally available in 1.102.
- **GitHub Copilot** enabled, with access to agent mode.
- **A Prowler Cloud account.** The free tier is enough to start. Sign up at [cloud.prowler.com](https://cloud.prowler.com).
## Step 1: Get Your Prowler API Key
Create an API key in Prowler Cloud and copy it. The key begins with `pk_` and is shown only once. Check the [API Keys](/user-guide/tutorials/prowler-app-api-keys#creating-api-keys) guide for details.
## Step 2: Add the Prowler MCP Server
VS Code stores MCP servers in an `mcp.json` file. Choose the scope that fits your use case:
| Scope | How to open it | Applies to |
|-------|----------------|------------|
| **User** | Command palette → **MCP: Open User Configuration** | Every workspace |
| **Workspace** | `.vscode/mcp.json` in the project root | That workspace only |
For Prowler, the **user** scope is usually the right choice — your findings are not tied to a single repository, and it keeps the API key out of any project directory that might be committed.
<Steps>
<Step title="Open the MCP configuration">
Open the command palette with `Cmd + Shift + P` (macOS) or `Ctrl + Shift + P` (Windows/Linux), then run **MCP: Open User Configuration**.
VS Code opens your user-level `mcp.json`. Use this command rather than navigating to the file by hand — the file lives inside your active profile folder, and the path differs per profile.
<Frame>
<img src="/images/prowler-mcp/vscode/vscode-command-palette.png" alt="VS Code command palette showing the MCP: Open User Configuration command" />
</Frame>
</Step>
<Step title="Add the Prowler configuration">
Paste the following. This version prompts you for the API key on first use and stores it securely, so the key is never written into the file:
```json
{
"inputs": [
{
"type": "promptString",
"id": "prowler-api-key",
"description": "Prowler API Key",
"password": true
}
],
"servers": {
"prowler": {
"type": "http",
"url": "https://mcp.prowler.com/mcp",
"headers": {
"Authorization": "Bearer ${input:prowler-api-key}"
}
}
}
}
```
Save the file.
<Frame>
<img src="/images/prowler-mcp/vscode/vscode-mcp-json.png" alt="VS Code editor showing the completed mcp.json with the Prowler server entry" />
</Frame>
</Step>
<Step title="Enter your API key">
Start the server. VS Code prompts for the Prowler API key. Paste it and press Enter — VS Code stores it securely and does not ask again.
</Step>
</Steps>
<Warning>
**The root key is `servers`, not `mcpServers`.** VS Code uses a different schema from Cursor, Claude, and most other clients. Copying a `mcpServers` snippet from elsewhere silently fails to register the server.
</Warning>
<Note>
**Local server:** Replace the URL with your own HTTP endpoint. Everything else stays the same.
</Note>
## Step 3: Verify the Connection
Run **MCP: List Servers** from the command palette. The `prowler` server should appear as running.
<Frame>
<img src="/images/prowler-mcp/vscode/vscode-list-servers.png" alt="VS Code MCP: List Servers output showing the Prowler server running" />
</Frame>
Select the server to start, stop, or restart it, and to view its output log if the connection fails.
## Step 4: Start Using Prowler MCP
Open the Chat view and switch the mode selector to **Agent**. Click the tools icon to confirm the Prowler tools are available, then ask:
- *"Show me all critical findings from my AWS accounts"*
- *"What does the S3 bucket public access check do?"*
- *"Summarize my CIS compliance status by provider"*
<Frame>
<img src="/images/prowler-mcp/vscode/vscode-agent-tools.png" alt="VS Code Copilot Chat in agent mode showing the Prowler tools in the tools picker" />
</Frame>
Copilot asks for confirmation before running an MCP tool for the first time.
## Troubleshooting
### Server Does Not Appear
- Confirm the root key is `servers`, not `mcpServers`.
- Confirm each server entry has `"type": "http"`.
- Check that `mcp.json` is valid JSON.
- Verify your VS Code version is 1.102 or later.
### Authentication Fails With 401
- Verify the header value includes the `Bearer ` prefix.
- Confirm the key has not been revoked in Prowler Cloud.
- If you mistyped the key at the prompt, run **MCP: List Servers**, select `prowler`, and restart it to be prompted again.
### Tools Do Not Appear in Chat
- Make sure the Chat view is in **Agent** mode. MCP tools are not available in Ask mode.
- Open the tools picker and confirm the Prowler tools are enabled.
## Next Steps
<CardGroup cols={2}>
<Card title="Tools Reference" icon="wrench" href="/getting-started/basic-usage/prowler-mcp-tools">
Explore all available tools and capabilities
</Card>
<Card title="All MCP Clients" icon="plug" href="/getting-started/basic-usage/prowler-mcp">
Configuration reference for every supported client
</Card>
</CardGroup>
## Getting Help
- Search for existing [GitHub issues](https://github.com/prowler-cloud/prowler/issues)
- Ask for help in our [Slack community](https://goto.prowler.com/slack)
- Report a new issue on [GitHub](https://github.com/prowler-cloud/prowler/issues/new)
docs/user-guide/cli/tutorials/configuration_file.mdx
+4
View File
@@ -64,6 +64,7 @@ The following list includes all the AWS checks with configurable variables that
| `dynamodb_table_cross_account_access` | `trusted_account_ids` | List of Strings | `[]` |
| `ec2_elastic_ip_shodan` | `shodan_api_key` | String | `null` |
| `ec2_instance_older_than_specific_days` | `max_ec2_instance_age_in_days` | Integer | `180` |
| `ec2_instance_stopped_older_than_specific_days` | `max_ec2_instance_stopped_days` | Integer | `30` |
| `ec2_instance_secrets_user_data` | `secrets_ignore_patterns` | List of Strings | `[]` |
| `ec2_launch_template_no_secrets` | `secrets_ignore_patterns` | List of Strings | `[]` |
| `ec2_securitygroup_allow_ingress_from_internet_to_any_port` | `ec2_allowed_instance_owners` | List of Strings | `["amazon-elb"]` |
@@ -79,6 +80,7 @@ The following list includes all the AWS checks with configurable variables that
| `elasticache_redis_cluster_backup_enabled` | `minimum_snapshot_retention_period` | Integer | `7` |
| `elb_is_in_multiple_az` | `elb_min_azs` | Integer | `2` |
| `elbv2_is_in_multiple_az` | `elbv2_min_azs` | Integer | `2` |
| `elbv2_listener_pqc_tls_enabled` | `elbv2_listener_pqc_tls_allowed_policies` | List of Strings | See `config.yaml` |
| `eventbridge_bus_cross_account_access` | `trusted_account_ids` | List of Strings | `[]` |
| `eventbridge_schema_registry_cross_account_access` | `trusted_account_ids` | List of Strings | `[]` |
| `glue_etl_jobs_no_secrets_in_arguments` | `secrets_ignore_patterns` | List of Strings | `[]` |
@@ -392,6 +394,8 @@ aws:
max_security_group_rules: 50
# aws.ec2_instance_older_than_specific_days --> by default is 6 months (180 days)
max_ec2_instance_age_in_days: 180
# aws.ec2_instance_stopped_older_than_specific_days --> by default is 30 days
max_ec2_instance_stopped_days: 30
# aws.ec2_securitygroup_allow_ingress_from_internet_to_any_port
# allowed network interface types for security groups open to the Internet
ec2_allowed_interface_types:
docs/user-guide/cli/tutorials/custom-checks-metadata.mdx
+2 -2
View File
@@ -5,13 +5,13 @@ description: "Use --custom-checks-metadata-file in Prowler CLI to override defau
In certain organizations, the severity of specific checks might differ from the default values defined in the check's metadata. For instance, while `s3_bucket_level_public_access_block` could be deemed `critical` for some organizations, others might assign a different severity level to it.
The custom metadata option offers a means to override default metadata set by Prowler
The custom metadata option offers a means to override default metadata set by Prowler.
You can utilize `--custom-checks-metadata-file` followed by the path to your custom checks metadata YAML file.
## Available Fields
The list of supported check's metadata fields that can be override are listed as follows:
The list of supported check's metadata fields that can be overridden are listed as follows:
- Severity
- CheckTitle
docs/user-guide/cli/tutorials/dashboard.mdx
+5 -5
View File
@@ -3,7 +3,7 @@ title: "Run the Prowler local dashboard from CSV outputs"
description: "Launch the built-in Prowler dashboard to visualize CSV scan output locally or in Docker, exposing an interactive UI on port 11666 for review."
---
Prowler allows you to run your own local dashboards using the csv outputs provided by Prowler
Prowler Local Dashboard is a local web dashboard built from the CSV outputs produced by Prowler CLI. Launch it with:
```sh
prowler dashboard
@@ -13,7 +13,7 @@ prowler dashboard
You can expose the `dashboard` server in another address using the `HOST` environment variable.
</Note>
To run Prowler local dashboard with Docker, use:
To run Prowler Local Dashboard with Docker, use:
```sh
docker run -v /your/local/dir/prowler-output:/home/prowler/output --env HOST=0.0.0.0 --publish 127.0.0.1:11666:11666 toniblyx/prowler:latest dashboard
@@ -37,7 +37,7 @@ This page allows for multiple functions:
- Apply filters:
- Assesment Date
- Assessment Date
- Account
- Region
- Severity
@@ -46,7 +46,7 @@ This page allows for multiple functions:
- Status
- Category
- See which files has been scanned to generate the dashboard by placing your mouse on the `?` icon:
- See which files have been scanned to generate the dashboard by placing your mouse on the `?` icon:
{" "}
<img src="/images/cli/dashboard/dashboard-files-scanned.png" />
@@ -68,7 +68,7 @@ This page shows all the info related to the compliance selected. Multiple filter
To add your own compliance to compliance page, add a file with the compliance name (using `_` instead of `.`) to the path `/dashboard/compliance`.
In this file use the format present in the others compliance files to create the table. Example for CIS 2.0:
In this file use the format present in the other compliance files to create the table. Example for CIS 2.0:
```python
import warnings
docs/user-guide/cli/tutorials/integrations.mdx
+2 -2
View File
@@ -34,9 +34,9 @@ To configure the Slack Integration, follow the next steps:
2. Optionally, create a Slack Channel (you can use an existing one)
3. Integrate the created Slack App to your Slack channel:
- Click on the channel, go to the Integrations tab, and Add an App.
- Click the channel, go to the Integrations tab, and Add an App.
![Slack App Channel Integration](/images/cli/integrate-slack-app.png)
4. Set the following environment variables that Prowler will read:
- `SLACK_API_TOKEN`: the *Slack App OAuth Token* that was previously get.
- `SLACK_API_TOKEN`: the *Slack App OAuth Token* that was previously obtained.
- `SLACK_CHANNEL_NAME`: the name of your Slack Channel where Prowler will send the message.
docs/user-guide/cli/tutorials/logging.mdx
+1 -1
View File
@@ -3,7 +3,7 @@ title: 'Prowler CLI logging levels and log file output'
description: 'Configure Prowler CLI log levels with --log-level and route DEBUG, INFO, WARNING, ERROR, or CRITICAL messages to a file with --log-file for troubleshooting.'
---
Prowler has a logging feature to be as transparent as possible, so that you can see every action that is being performed whilst the tool is being executing.
Prowler has a logging feature to be as transparent as possible, so that you can see every action that is being performed whilst the tool is being executed.
## Set Log Level
docs/user-guide/cli/tutorials/mutelist.mdx
+3 -3
View File
@@ -319,11 +319,11 @@ The DynamoDB Table must have the following String keys:
The Mutelist Table must have the following columns:
- Accounts (String): This field can contain either an Account ID or an `*` (which applies to all the accounts that use this table as an mutelist).
- Accounts (String): This field can contain either an Account ID or an `*` (which applies to all the accounts that use this table as a mutelist).
- Checks (String): This field can contain either a Prowler Check Name or an `*` (which applies to all the scanned checks).
- Regions (List): This field contains a list of regions where this mutelist rule is applied (it can also contains an `*` to apply all scanned regions).
- Regions (List): This field contains a list of regions where this mutelist rule is applied (it can also contain an `*` to apply all scanned regions).
- Resources (List): This field contains a list of regular expressions (regex) that applies to the resources that are wanted to be muted.
@@ -359,7 +359,7 @@ Make sure that the credentials that Prowler uses can invoke the Lambda Function:
Resource: arn:aws:lambda:REGION:ACCOUNT_ID:function:FUNCTION_NAME
```
The Lambda Function can then generate an Mutelist dynamically. Here is the code an example Python Lambda Function that generates an Mutelist:
The Lambda Function can then generate a Mutelist dynamically. Here is the code of an example Python Lambda Function that generates a Mutelist:
```
def handler(event, context):
docs/user-guide/cli/tutorials/parallel-execution.mdx
+3 -3
View File
@@ -134,9 +134,9 @@ Write-Host "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') - All jobs completed"
Output will be stored in `C:\Users\YOUR-USER\Documents\output\`
## Combining the output files
## Combining the Output Files
Guidance is provided for the CSV file format. From the ouput directory, execute either the following Bash or PowerShell script. The script will collect the output from the CSV files, only include the header from the first file, and then output the result as CombinedCSV.csv in the current working directory.
Guidance is provided for the CSV file format. From the output directory, execute either the following Bash or PowerShell script. The script will collect the output from the CSV files, only include the header from the first file, and then output the result as CombinedCSV.csv in the current working directory.
There is no logic implemented in terms of which CSV files it will combine. If you have additional CSV files from other actions, such as running a quick inventory, you will need to move that out of the current (or any nested) directory, or move the output you want to combine into its own folder and run the script from there.
@@ -185,7 +185,7 @@ $combinedCsv | Export-Csv -Path "CombinedCSV.csv" -NoTypeInformation
## TODO: Additional Improvements
Some services need to instantiate another service to perform a check. For instance, `cloudwatch` will instantiate Prowler's `iam` service to perform the `cloudwatch_cross_account_sharing_disabled` check. When the `iam` service is instantiated, it will perform the `__init__` function, and pull all the information required for that service. This provides an opportunity for an improvement in the above script to group related services together so that the `iam` services (or any other cross-service references) isn't repeatedily instantiated by grouping dependant services together. A complete mapping between these services still needs to be further investigated, but these are the cross-references that have been noted:
Some services need to instantiate another service to perform a check. For instance, `cloudwatch` will instantiate Prowler's `iam` service to perform the `cloudwatch_cross_account_sharing_disabled` check. When the `iam` service is instantiated, it will perform the `__init__` function, and pull all the information required for that service. This provides an opportunity for an improvement in the above script to group related services together so that the `iam` services (or any other cross-service references) aren't repeatedly instantiated by grouping dependent services together. A complete mapping between these services still needs to be further investigated, but these are the cross-references that have been noted:
* inspector2 needs lambda and ec2
* cloudwatch needs iam
docs/user-guide/cli/tutorials/quick-inventory.mdx
+1 -1
View File
@@ -19,7 +19,7 @@ Currently, it is only available for AWS provider.
By default, it extracts resources from all the regions, you could use `-f`/`--filter-region` to specify the regions to execute the analysis.
</Note>
- This feature specify both the number of resources for each service and for each resource type.
- This feature specifies both the number of resources for each service and for each resource type.
- Also, it creates by default a CSV and JSON to see detailed information about the resources extracted.
docs/user-guide/cli/tutorials/reporting.mdx
+2 -2
View File
@@ -50,7 +50,7 @@ prowler <provider> -M csv json-ocsf json-asff -o <custom_report_directory>
Both flags can be used simultaneously to provide a custom directory and filename. `console prowler <provider> -M csv json-ocsf json-asff \ -F <custom_report_name> -o <custom_report_directory>`
</Note>
## Output timestamp format
## Output Timestamp Format
By default, the timestamp format of the output files is ISO 8601. This can be changed with the flag `--unix-timestamp` generating the timestamp fields in pure unix timestamp format.
@@ -115,7 +115,7 @@ The CSV format follows a standardized structure across all providers. The follow
#### CSV Headers Mapping
The following table shows the mapping between the CSV headers and the the providers fields:
The following table shows the mapping between the CSV headers and the providers fields:
| Open Source Consolidated| AWS| GCP| AZURE| KUBERNETES
|----------|----------|----------|----------|----------
docs/user-guide/compliance/tutorials/compliance.mdx
+68 -15
View File
@@ -3,12 +3,15 @@ title: 'Prowler compliance frameworks and reports'
description: 'Run Prowler compliance scans against CIS, NIST, ISO 27001, PCI-DSS, SOC 2, and more, then download CSV or PDF reports from Prowler Cloud, App, or CLI.'
---
Prowler maps every security check to one or more industry-standard compliance frameworks, so a single scan produces both technical findings and framework-aligned evidence. The same evaluation runs identically whether scans are launched from Prowler Cloud, Prowler App, or Prowler CLI.
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
import { VersionBadge } from "/snippets/version-badge.mdx"
Prowler maps every security check to one or more industry-standard compliance frameworks, so a single scan produces both technical findings and framework-aligned evidence. The same evaluation runs identically whether scans are launched from Prowler Cloud, Prowler Local Server, or Prowler CLI.
Out of the box, Prowler covers frameworks such as CIS Benchmarks, NIST 800-53, NIST CSF, NIS2, ENS RD2022, ISO 27001, PCI-DSS, SOC 2, GDPR, HIPAA, AWS Well-Architected, BSI C5, CSA CCM, MITRE ATT&CK, KISA ISMS-P, FedRAMP, and Prowler ThreatScore. The full catalog is available at [Prowler Hub](https://hub.prowler.com/compliance).
<Note>
For the unified compliance score methodology used across frameworks, see [Prowler ThreatScore Documentation](/user-guide/compliance/tutorials/threatscore).
For the unified compliance score methodology used across frameworks, see [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore).
</Note>
<CardGroup cols={2}>
@@ -20,23 +23,28 @@ For the unified compliance score methodology used across frameworks, see [Prowle
</Card>
</CardGroup>
## Prowler Cloud
## Prowler Cloud and Prowler Local Server
The Compliance section in Prowler Cloud and Prowler App centralizes compliance posture across every connected provider. It aggregates scan results, surfaces Prowler ThreatScore, and exposes detailed requirement-level evidence for each supported framework.
The Compliance section in Prowler Cloud and Prowler Local Server centralizes compliance posture across every connected provider. It aggregates scan results, surfaces Prowler ThreatScore, and exposes detailed requirement-level evidence for each supported framework.
### Accessing the Compliance Section
To open the compliance overview, follow these steps:
1. Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) or to a self-hosted Prowler App instance.
1. Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) or to a Prowler Local Server instance.
2. Select **Compliance** from the left navigation.
The page lists every framework evaluated by the most recent completed scan of the selected provider.
The Compliance page is organized into two tabs:
<img src="/images/compliance/prowler-app-compliance-overview.png" alt="Compliance overview page in Prowler Cloud and App showing filters, the Prowler ThreatScore card, and the framework grid" width="900" />
* **Single Scan:** Lists every framework evaluated by one completed scan of one provider. This is the experience described in the rest of this guide, and the default view in Prowler Local Server.
* **Multiple Scans:** Aggregates one framework across several scans at once, either across provider types ([Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)) or across every provider of the same type ([Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)).
<SubscriptionBanner label="Multiple Scans tab" />
<img src="/images/compliance/prowler-app-compliance-overview.png" alt="Compliance overview page in Prowler Cloud and Prowler Local Server showing filters, the Prowler ThreatScore card, and the framework grid" width="900" />
<Note>
Compliance results require at least one completed scan. If no scan has finished yet, Prowler Cloud and App display a notice prompting to launch or wait for a scan to complete.
Compliance results require at least one completed scan. If no scan has finished yet, Prowler Cloud and Prowler Local Server display a notice prompting to launch or wait for a scan to complete.
</Note>
### Filtering Compliance Results
@@ -49,7 +57,7 @@ The scan selector lists completed scans across all connected providers. Each ent
#### Region Filter
The region multi-select narrows results to one or more regions detected in the selected scan. Use it to evaluate compliance posture for a specific geography or account boundary. The filter applies to:
The region multi-select narrows results to one or more regions detected in the selected scan. Use it to evaluate compliance posture for a specific geography or regulatory boundary. The filter applies to:
* The framework grid scores and pass/fail counts.
* The detailed requirement view inside each framework.
@@ -74,7 +82,7 @@ When the selected scan includes Prowler ThreatScore data, a dedicated card appea
Selecting the card opens the ThreatScore framework detail page, covered in [Working With the Framework Detail Page](#working-with-the-framework-detail-page).
For a complete explanation of the methodology, formula, and weighting, see [Prowler ThreatScore Documentation](/user-guide/compliance/tutorials/threatscore).
For a complete explanation of the methodology, formula, and weighting, see [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore).
### Exploring the Framework Grid
@@ -94,6 +102,49 @@ Select any card to open the framework detail page.
Score color coding follows three thresholds: red for severely low compliance, amber for partial compliance, and green for healthy posture. Hover over the score for the exact percentage.
</Note>
### Tracking Frameworks With the Compliance Watchlist
<VersionBadge version="5.38.0" />
<SubscriptionBanner label="Compliance Watchlist" />
The compliance catalog lists dozens of frameworks, while an organization usually tracks a handful. In Prowler Cloud, Compliance Watchlist keeps that handful in front: pin the frameworks that matter and narrow every compliance surface down to them. The watchlist is shared by the whole organization: one list per tenant, not a per-user bookmark, so every member sees the same pinned frameworks.
#### Pinning a Framework
Every framework card carries a pin button in its top-right corner. Select the pin to add the framework to the watchlist, and select it again to remove it. Pinning is available on the three compliance surfaces:
* **Single Scan:** The framework grid of the selected scan.
* **Across provider types:** The universal framework cards in the **Multiple Scans** tab.
* **Across providers:** The framework cards inside each provider type group in the **Multiple Scans** tab.
<img src="/images/compliance/prowler-app-compliance-single-scan-pins.png" alt="Single Scan framework grid where every card carries a pin button, with the pinned frameworks showing a filled pin" width="900" />
<Note>
Universal frameworks (CSA CCM, CIS Controls, DORA) are a single watchlist entry. Pinning one of them from any surface shows it as pinned on the others.
</Note>
#### Filtering With the Watchlist
Two controls sit above the tabs, because both tabs read the same watchlist:
* **Show only watchlist:** A toggle that hides every framework not in the watchlist, on both tabs at once. When the filter leaves a section with nothing to show, the section explains that no pinned framework matches and offers to clear the filter.
* **Watchlist selector:** A searchable multi-select over the full framework catalog, grouped by provider. Use it to pin or unpin several frameworks in one place instead of visiting each card.
<img src="/images/compliance/prowler-app-compliance-watchlist-editor.png" alt="Watchlist selector open above the compliance tabs, showing the searchable framework catalog grouped by provider with the pinned frameworks selected" width="900" />
In Prowler Cloud, the compliance framework chips in the finding details panel follow the watchlist as well, so triage points to the same frameworks the organization tracks.
#### Reviewing the Watchlist on the Overview Page
The **Compliance Watchlist** card on the Overview page lists exactly the pinned frameworks with their current score, computed from the latest completed scan per provider. Selecting an entry opens the framework detail page. Until a framework is pinned, the card is empty and prompts to start pinning from the Compliance section.
<img src="/images/compliance/prowler-app-overview-compliance-watchlist.png" alt="Compliance Watchlist card on the Overview page listing the six pinned frameworks with their scores" width="312" />
<Note>
In Prowler Local Server, where the watchlist is not available, the card keeps its previous behavior and ranks every framework with scan data.
</Note>
### Working With the Framework Detail Page
The detail page provides everything needed to evaluate a single framework: aggregate metrics, top failure sections, and a requirement-by-requirement view.
@@ -144,7 +195,7 @@ Frameworks without a custom layout fall back to the generic details panel, which
### Downloading Compliance Reports
Prowler Cloud and App expose two formats:
Prowler Cloud and Prowler Local Server expose two formats:
* **CSV report:** Every requirement, every check, and every finding for the selected scan and filters. Available for all supported frameworks.
* **PDF report:** Curated executive-style report. Currently supported for Prowler ThreatScore, ENS RD2022, NIS2, and CSA CCM. Additional PDF reports are added in subsequent Prowler releases.
@@ -169,7 +220,7 @@ Region filters disable the per-card download dropdown to avoid generating partia
#### Downloading the Full Scan Output
To export every framework, finding, and resource at once, use the **Scan Jobs** section instead. The ZIP archive contains the CSV, JSON-OCSF, and HTML reports plus a `compliance/` subfolder with one CSV per framework. See [Prowler App — Getting Started](/user-guide/tutorials/prowler-app) for details.
To export every framework, finding, and resource at once, use the **Scan Jobs** section instead. The ZIP archive contains the CSV, JSON-OCSF, and HTML reports plus a `compliance/` subfolder with one CSV per framework. See [Prowler Cloud — Getting Started](/user-guide/tutorials/prowler-app) for details.
### API Access
@@ -182,7 +233,7 @@ Use the API to integrate compliance evidence into ticketing systems, executive d
## Prowler CLI
Prowler CLI evaluates the same compliance frameworks as Prowler Cloud and App, and produces detailed CSV outputs alongside the standard scan results. By default, it runs every supported framework and prints a status summary at the end of the scan:
Prowler CLI evaluates the same compliance frameworks as Prowler Cloud and Prowler Local Server, and produces detailed CSV outputs alongside the standard scan results. By default, it runs every supported framework and prints a status summary at the end of the scan:
<img src="/images/cli/compliance/compliance.png" />
@@ -262,6 +313,8 @@ To request a new framework or contribute one, see [Creating a New Security Compl
## Related Documentation
* [Prowler ThreatScore Documentation](/user-guide/compliance/tutorials/threatscore)
* [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)
* [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
* [Creating a New Security Compliance Framework in Prowler](/developer-guide/security-compliance-framework)
* [Prowler App — Getting Started](/user-guide/tutorials/prowler-app)
* [Prowler Cloud — Getting Started](/user-guide/tutorials/prowler-app)
docs/user-guide/compliance/tutorials/cross-provider-compliance.mdx
+147
View File
@@ -0,0 +1,147 @@
---
title: 'Cross-Provider Compliance'
sidebarTitle: 'Cross-Provider Compliance'
description: 'Aggregate a single-provider compliance framework across every provider of the same type, review the consolidated roll-up and per-provider coverage, and download a combined PDF report.'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
<VersionBadge version="5.37.0" />
Cross-Provider Compliance aggregates one **single-provider compliance framework** — CIS AWS, CIS GCP, ENS for Azure — across every provider of that type into a single view. It answers the question a per-scan report cannot: **"How compliant is my whole AWS estate against CIS AWS, together?"**
<SubscriptionBanner />
This view is the sibling of [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance), which aggregates a *universal* framework across different provider types. Both live in the **Multiple Scans** tab and share the same roll-up rules, scan selection, and report flow. Only the column axis changes, from provider type to individual provider.
## How Cross-Provider Compliance Works
For a chosen framework and provider type, Prowler Cloud:
1. Selects **one scan per provider**: the latest completed scan of every provider of that type you are allowed to see.
2. Aggregates the requirement results across those scans.
3. Computes a **roll-up status** for each requirement and an overall pass / fail / manual summary.
4. Exposes a **per-provider breakdown** so a failing provider is immediately attributable.
## Accessing the Cross-Provider View
<Steps>
<Step title="Open the Compliance section">
Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) and select **Compliance** from the left navigation.
</Step>
<Step title="Open the Multiple Scans tab">
**Multiple Scans** is the landing tab of the Compliance page in Prowler Cloud. Scroll to the **Across providers** section, below the **Across provider types** cards.
</Step>
<Step title="Expand a provider type">
Each provider type is a collapsible group headed by its counts (frameworks available and providers registered). Expanding it reveals one card per single-provider framework available for that type.
</Step>
</Steps>
<img src="/images/compliance/prowler-app-compliance-multiple-scans.png" alt="Multiple Scans tab showing the Across provider types cards and the Across providers section, with the AWS group collapsed and its framework and provider counts" width="900" />
<Note>
A provider type appears only when it has two or more providers registered **and** at least one of them has a completed scan: that scan is where the framework catalog of the provider type is read from. With a single provider the aggregation is identical to the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
Framework cards in this section carry no score: they enumerate which frameworks can be aggregated for a provider type, and the roll-up numbers are computed on the detail page. Two catalogs stay out of the section, because each already has its own view:
* **Universal frameworks:** Aggregated in the **Across provider types** section above. See [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance).
* **Prowler ThreatScore:** Reviewed per scan in the **Single Scan** tab. See [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore).
<img src="/images/compliance/prowler-app-across-providers-expanded.png" alt="Across providers section with the AWS group expanded, showing one card per single-provider framework with its View across providers link and provider count" width="900" />
## Pinning Frameworks to the Watchlist
<VersionBadge version="5.38.0" />
Framework cards inside each provider type group carry a pin button that adds the framework to the organization's [Compliance Watchlist](/user-guide/compliance/tutorials/compliance#tracking-frameworks-with-the-compliance-watchlist). With the **Show only watchlist** toggle enabled, each group lists only its pinned frameworks, and a group whose frameworks are all filtered out explains that no pinned framework matches instead of expanding into an empty accordion.
<img src="/images/compliance/prowler-app-compliance-watchlist-filtered.png" alt="Multiple Scans tab with Show only watchlist enabled, where the AWS group of the Across providers section lists only its pinned framework" width="900" />
## Which Providers Are Listed and Which Contribute
The **Across providers** section and the detail page count different things, so their numbers often differ:
* The section describes your **catalog**: the group header and each framework card report how many providers of that type exist in Prowler Cloud, after the filters you applied.
* The detail page describes your **evidence**: only providers with a completed scan become a column in the aggregation, because every number on that page is computed from scan results.
A card can therefore read `17 providers` while its detail page reports two providers aggregated from two scans. The other 15 providers exist in Prowler Cloud but have no completed scan, so there is nothing of theirs to aggregate. This is the expected state right after onboarding an AWS Organization: the discovery wizard registers every member it finds in the organization as a provider, and providers not scanned yet count toward the catalog while contributing nothing to the roll-up. See [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations) for that onboarding flow.
What decides whether a provider contributes is **having a completed scan**, not its connection status:
* **Completed scans only:** Failed, cancelled, and in-progress scans are ignored, so a provider whose latest scan is still running keeps contributing its previous completed one.
* **Disconnected providers still count:** A provider whose credentials stopped working contributes its last completed scan. The posture it shows is as old as that scan.
* **Newly connected providers do not:** A provider contributes nothing until its first scan completes.
To confirm which providers made it into an aggregation, read the coverage summary in the detail page header and the coverage card, which lists one row per contributing provider.
<Warning>
The **Providers** filter on the detail page lists every provider of the type, including ones that have never been scanned. Narrowing to providers with no completed scan leaves the view with no evidence to aggregate: the coverage card reports nothing scanned, requirements show no per-provider status, and any report generated for that selection is empty. Clear the filter or select providers that have already been scanned.
</Warning>
## Working With the Framework Detail Page
Selecting a card opens a detail page with the same layout as the cross-provider-type detail, with the column axis swapped from provider type to provider:
* **Header:** States the framework, the provider type, and the real coverage behind the numbers, as a count of aggregated providers and scans. The **Report** button generates the combined PDF.
* **Requirements Status:** Donut chart with the consolidated `Pass`, `Fail`, and `Manual` counts.
* **Coverage card:** Ranks each contributing provider's individual posture, so the weakest one is visible at a glance. Every row is one provider of the type, labeled with its alias and unique identifier (UID).
* **Top Failed Sections:** Ranks the framework sections with the most failing requirements, with deep links into the requirements accordion.
* **Requirements accordion:** Each requirement shows its roll-up badge plus the status of every contributing provider, labeled with the provider alias and unique identifier (UID). With one or two providers the statuses appear as inline chips; from three onwards the row condenses into per-status counts (for example, `Fail ×3 Pass ×6`), and selecting the counts opens the full provider-by-provider breakdown. Expanding a requirement queries the findings of every contributing scan and merges them into a single table.
<img src="/images/compliance/prowler-app-across-providers-detail.png" alt="Cross-Provider Compliance detail page for CIS AWS 7.0 showing the header with the aggregated providers and scans, the Report button, the Providers and Provider group filters, and the Requirements Status, coverage, and Top Failed Sections cards above the requirements accordion" width="900" />
<Note>
Checks are not labeled per provider type as in the cross-provider-type view. Every provider of the same type shares one check set, so a single list of checks covers the whole aggregation.
</Note>
### Filtering the Roll-Up
Two filters control which providers feed the aggregation:
* **Providers:** Narrow to specific providers of the type, listed by alias and UID.
* **Provider group:** Narrow to the providers belonging to one or more provider groups.
The provider type is fixed by the framework, so there is no type filter here. Filters applied on the overview carry through into the detail page and the PDF report.
## Understanding the Roll-Up Status
Results roll up in two stages, with a strict **FAIL > PASS > MANUAL** precedence.
**Per provider, per requirement:**
* If any check fails → the provider contributes **FAIL** for that requirement.
* Else if every check passes → **PASS**.
* Otherwise (no pass/fail evidence) → **MANUAL**.
**Across providers, per requirement (the roll-up badge):**
* If at least one contributing provider is **FAIL** → the requirement is **FAIL**.
* Else if at least one contributing provider is **PASS** → **PASS**.
* Otherwise → **MANUAL**.
<Note>
Only providers that **actually contributed a result** for a requirement are counted. A provider whose scan produced no result for a specific requirement does not degrade that requirement to Manual, which keeps the roll-up focused on real evidence.
</Note>
Scan selection and permission scoping match the cross-provider-type view: the aggregation always reflects each provider's most recent completed scan, restricted to the providers your role is allowed to see. To review how provider visibility is granted, see [Role-Based Access Control (RBAC)](/user-guide/tutorials/prowler-app-rbac).
## Downloading the Combined PDF Report
The **Report** button produces a single PDF across every contributing provider of the type: a cover page listing the providers, an executive summary with the consolidated roll-up, charts, a requirements index, and detailed findings grouped by requirement and provider.
<img src="/images/compliance/prowler-app-across-providers-report.png" alt="Report dropdown on the Cross-Provider Compliance detail page showing the Generate new report option" width="420" />
Generation is asynchronous and behaves exactly like the cross-provider-type report — background job, toast notification when ready, and **Report → Download latest** to reuse a report already generated for the current filters. See [Downloading the Combined PDF Report](/user-guide/compliance/tutorials/cross-provider-type-compliance#downloading-the-combined-pdf-report) for the full flow, including report reuse and the findings cap.
<Note>
A report is tied to the exact set of scans it was built from. When any contributing provider completes a new scan, the previous report no longer matches the current selection and Prowler Cloud offers to generate an up-to-date one.
</Note>
## Related Documentation
* [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)
* [Compliance](/user-guide/compliance/tutorials/compliance)
* [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
docs/user-guide/compliance/tutorials/cross-provider-type-compliance.mdx
+233
View File
@@ -0,0 +1,233 @@
---
title: 'Cross-Provider Type Compliance'
sidebarTitle: 'Cross-Provider Type Compliance'
description: 'Aggregate a universal compliance framework across every compatible provider with a completed scan, review the consolidated roll-up and per-provider breakdown, and download a combined PDF report.'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
<VersionBadge version="5.34.0" />
Cross-Provider Type Compliance consolidates a single **universal compliance framework** across your compatible providers with completed scans into one unified view. Instead of reviewing the same framework on AWS, Azure, Google Cloud, and other supported providers as separate reports, Prowler takes the most recent completed scan of every compatible provider, aggregates them by requirement, and produces a single roll-up posture with a per-provider breakdown and a combined executive PDF.
<SubscriptionBanner />
## What Is a Universal Compliance Framework
Most Prowler compliance frameworks target a single provider (for example, CIS AWS or CIS Azure). A **universal** framework declares its requirements once in a single JSON and maps each requirement to checks for many providers at the same time, so the same CSA CCM control maps to both AWS and Azure checks. Universal frameworks live at the top of the compliance catalog (`prowler/compliance/<framework>.json`), as opposed to the legacy per-provider frameworks under `prowler/compliance/<provider>/`. For real definitions, see [`csa_ccm_4.0.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/csa_ccm_4.0.json), [`cis_controls_8.1.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/cis_controls_8.1.json), and [`dora_2022_2554.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/dora_2022_2554.json) in the Prowler repository.
Prowler currently ships three universal frameworks: [CSA CCM](https://hub.prowler.com/compliance/csa_ccm_4.0), [CIS Controls](https://hub.prowler.com/compliance/cis_controls_8.1), and [DORA](https://hub.prowler.com/compliance/dora_2022_2554). Each framework page on Prowler Hub lists the full requirement-to-check mapping per provider.
## How Cross-Provider Type Compliance Works
Cross-Provider Type Compliance uses this structure to answer a single question: **"How compliant is my whole estate against this framework, regardless of provider?"** For a chosen universal framework, Prowler Cloud:
1. Selects **one scan per compatible provider**: by default, the latest completed scan of each provider the framework supports and that you are allowed to see.
2. Aggregates the requirement results across those scans, folding multiple providers of the same type together.
3. Computes a **roll-up status** for each requirement and an overall pass / fail / manual summary for the framework.
4. Exposes a **per-provider breakdown** so you can see exactly which provider is failing a given control.
<Note>
Cross-Provider Type Compliance never mixes different frameworks. It aggregates one universal framework at a time across providers. To review a single provider in isolation, use the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
### Supported Universal Frameworks
The Cross-Provider Type Compliance view currently supports the following universal frameworks. The compatible providers are the ones each framework declares checks for; a provider only contributes to the roll-up when it has a completed scan.
| Framework | Version | Compatible providers |
|-----------|---------|----------------------|
| [**CSA CCM**](https://hub.prowler.com/compliance/csa_ccm_4.0) (Cloud Controls Matrix) | 4.0 | AWS, Azure, Google Cloud, Alibaba Cloud, Oracle Cloud |
| [**CIS Controls**](https://hub.prowler.com/compliance/cis_controls_8.1) | 8.1 | AWS, Azure, Google Cloud, Microsoft 365, Kubernetes, GitHub, Google Workspace, Okta, Oracle Cloud, Alibaba Cloud, Cloudflare, MongoDB Atlas, OpenStack, Vercel |
| [**DORA**](https://hub.prowler.com/compliance/dora_2022_2554) (Digital Operational Resilience Act) | 2022/2554 | AWS, Azure, Google Cloud, Alibaba Cloud, Cloudflare |
The catalog grows as new universal frameworks ship in Prowler. Browse the full compliance catalog at [Prowler Hub](https://hub.prowler.com/compliance).
## Accessing the Cross-Provider Type View
<Steps>
<Step title="Open the Compliance section">
Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) and select **Compliance** from the left navigation.
</Step>
<Step title="Open the Multiple Scans tab">
In Prowler Cloud, **Multiple Scans** is the landing tab of the Compliance page, so it opens already selected. Select **Single Scan** at the top of the page to return to the per-scan compliance experience, which remains unchanged.
</Step>
</Steps>
<Note>
The **Across provider types** section requires at least one completed scan for a provider compatible with a universal framework. If none is available, that section shows a notice prompting you to launch or wait for a scan to complete. The **Across providers** section below it has its own requirements — see [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance).
</Note>
## Exploring the Overview
The Multiple Scans tab is organized into two sections, each labeled with the axis it aggregates across:
* **Across provider types:** One card per supported universal framework, aggregating every compatible provider type. This is the Cross-Provider Type Compliance experience described in the rest of this guide.
* **Across providers:** One card per single-provider framework (for example, CIS AWS) that can be aggregated across every provider of the same type. See [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance).
The **Across provider types** section presents one card per supported universal framework, each summarizing the consolidated posture across every contributing provider.
<img src="/images/compliance/prowler-app-compliance-multiple-scans.png" alt="Multiple Scans tab showing the provider filters, the Across provider types grid (CSA CCM, CIS Controls, DORA) with per-provider chips, scores, and failed and manual counts, and the Across providers section below it" width="900" />
Each **framework card** includes:
* **Framework logo, name, and version:** Identifies the universal standard (CSA CCM, CIS Controls, DORA).
* **Score:** The percentage of passing requirements over the total evaluated, aggregated across every contributing provider. Color coding follows three thresholds: red for severely low compliance, amber for partial compliance, and green for healthy posture.
* **Passing Requirements:** A `passed / total` counter with the aggregated roll-up.
* **Provider chips:** One icon per compatible provider. Providers with a completed scan appear active with their passing percentage; providers without a scan appear dimmed with a "no completed scan yet" tooltip so coverage gaps are obvious at a glance.
* **Failed and manual counts:** The number of failing and manual requirements in the roll-up.
Select any card to open the framework detail page.
### Pinning Universal Frameworks to the Watchlist
<VersionBadge version="5.38.0" />
Each universal framework card carries a pin button that adds the framework to the organization's [Compliance Watchlist](/user-guide/compliance/tutorials/compliance#tracking-frameworks-with-the-compliance-watchlist). A universal framework is a single watchlist entry, so pinning it here also shows it as pinned on the Single Scan grid of every compatible provider. The **Show only watchlist** toggle above the tabs narrows both sections of the Multiple Scans tab to the pinned frameworks.
<img src="/images/compliance/prowler-app-compliance-watchlist-pins.png" alt="Multiple Scans tab with the watchlist controls above the tabs and a filled pin on each universal framework card" width="900" />
### Filtering the Roll-Up
The filters bar controls which providers feed every card and detail view. Cross-Provider Type Compliance supports three filters:
* **Provider type:** Narrow the roll-up to specific provider types (for example, only AWS and Azure).
* **Providers:** Narrow to specific providers, listed by alias and unique identifier (UID).
* **Provider group:** Narrow to the providers belonging to one or more provider groups.
Select **Clear filters** to reset all filters. Filters applied on the overview are carried through into the detail page and the PDF report so the view stays consistent end to end.
<Note>
Filters narrow **which providers contribute** to the aggregation. They do not change how a requirement rolls up (see [Understanding the Roll-Up Status](#understanding-the-roll-up-status)).
</Note>
## Working With the Framework Detail Page
The detail page provides the full breakdown for a single universal framework: aggregate metrics, provider coverage, top failing sections, and a requirement-by-requirement view with per-provider status.
<img src="/images/compliance/prowler-app-cross-provider-detail.png" alt="Cross-Provider Type Compliance detail page for CSA CCM 4.0 showing the header with providers scanned and the Report button, the filters, and the Requirements Status, Provider Coverage, and Top Failed Sections summary cards" width="900" />
### Header
The header shows the framework name and version, a link to the framework page on [Prowler Hub](https://hub.prowler.com/compliance), and a summary such as *"X of Y compatible providers scanned · N scans aggregated"* so you always know the coverage behind the numbers. The **Report** button in the top-right generates and downloads the combined PDF (see [Downloading the Combined PDF Report](#downloading-the-combined-pdf-report)).
### Summary Cards
Below the header, three summary cards condense the framework state:
* **Requirements Status:** Donut chart with `Pass`, `Fail`, and `Manual` counts plus the total number of requirements, reflecting the consolidated roll-up.
* **Provider Coverage:** Shows which compatible providers contributed a scan and their individual posture, so coverage gaps and per-provider weak spots are visible at a glance.
* **Top Failed Sections:** Ranks the framework sections with the highest number of failing requirements, with deep links into the requirements accordion.
### Requirements Accordion
The accordion organizes every requirement of the framework. For each requirement you see:
* **Requirement ID and title:** The official identifier from the framework.
* **Roll-up status badge:** A single `Pass`, `Fail`, or `Manual` badge representing the consolidated status across all contributing providers.
* **Per-provider status:** The status each contributing provider returned for that requirement, so a single failing provider is immediately attributable. Up to five providers are shown as inline chips; beyond that the row condenses into per-status counts (for example, `Fail ×3 Pass ×6`), and selecting the counts opens the full provider-by-provider breakdown.
* **Provider-labeled checks:** When you expand a requirement, the underlying checks are labeled with the provider they belong to (each universal requirement maps to different check IDs per provider).
Expand a requirement to review the failing checks per provider, the affected resources, and remediation guidance. Findings are queried across every contributing scan and merged into a single table.
<img src="/images/compliance/prowler-app-cross-provider-requirements-accordion.png" alt="Expanded DORA requirement showing the per-provider Fail badges for AWS, Azure, and Google Cloud, the requirement description and attributes, the checks count, and the merged findings table with a Provider column" width="900" />
## Understanding the Roll-Up Status
Cross-Provider Type Compliance rolls up results in two stages, with a strict **FAIL > PASS > MANUAL** precedence.
**Per provider, per requirement:**
* If any check fails → the provider contributes **FAIL** for that requirement.
* Else if every check passes → **PASS**.
* Otherwise (no pass/fail evidence) → **MANUAL**.
Multiple providers of the same type (for example, three AWS providers) are folded together first, so a failure in any one of them marks that provider type as failing.
**Across providers, per requirement (the roll-up badge):**
* If at least one contributing provider is **FAIL** → the requirement is **FAIL**.
* Else if at least one contributing provider is **PASS** → **PASS**.
* Otherwise → **MANUAL**.
<Note>
Only providers that **actually contributed a result** for a requirement are counted. A provider that has a scan in the aggregation but produced no result for a specific requirement (for example, because the framework maps no checks to that provider for that control) does **not** degrade the requirement to Manual. This keeps the roll-up focused on real evidence.
</Note>
### How Scans Are Selected
By default, Cross-Provider Type Compliance auto-selects the **latest completed scan** of each compatible provider you are allowed to see. This means:
* The view always reflects your most recent posture per provider, without any manual scan selection.
* Adding a new compatible provider and running a scan automatically brings it into the roll-up.
* Provider visibility follows your role: only the providers your permissions allow are ever shown, and the roll-up is scoped accordingly. See [Role-Based Access Control (RBAC)](/user-guide/tutorials/prowler-app-rbac).
What makes a provider contribute is **having a completed scan**, not its current connection status:
* Only scans in the **completed** state are eligible. Failed, cancelled, and in-progress scans are ignored, so a provider whose latest scan is still running keeps contributing its previous completed one.
* A provider whose credentials stopped working still contributes its last completed scan. The posture it shows is as old as that scan.
* A provider connected but never scanned contributes nothing until its first scan completes. On the framework cards it appears dimmed instead of disappearing, so the coverage gap stays visible.
## Downloading the Combined PDF Report
The **Report** button on the detail page generates a single PDF that combines every contributing provider's latest scan for the framework into one executive document: a cover page listing every contributing provider, an executive summary with the consolidated roll-up, charts, a requirements index, and detailed findings grouped by requirement and provider.
### The Report Follows Your Filters
A report covers the exact set of scans your current filters resolve to. The provider type, providers, and provider group filters applied on the detail page determine which providers contribute, and the auto-select rule pins each contributing provider's latest completed scan. The PDF is built from that resolved scan set together with the framework.
As a result, each filter combination produces its own report. For example:
* No filters → a report covering every compatible provider that has a completed scan.
* `Provider type = AWS, Azure` → a report covering only your AWS and Azure scans.
* `Provider group = Production` → a report covering only the providers in that group.
Changing the filters and generating again produces a different, independent report. Each combination is tracked on its own, so switching filters back and forth never overwrites a previously generated report.
<Note>
Region filtering is **not** supported for the combined PDF report. The report recomputes status live across every region of the contributing scans, so a region-scoped request is rejected rather than producing a report that contradicts a region-filtered view.
</Note>
### Generating and Reusing a Report
Because the report aggregates many scans, it is generated **asynchronously**:
<Steps>
<Step title="Start the report">
Select **Report → Generate new report…**, optionally give it a name, and confirm. Prowler starts a background job and shows a "Report generation started" confirmation.
</Step>
<Step title="Wait for completion">
The button shows a "Generating report…" state while the job runs. Generation continues in the background: you can navigate away, and a toast notification appears when the report is ready, even after a page reload.
</Step>
<Step title="Download">
When the report is ready, select **Download** from the notification, or use **Report → Download latest** at any time to fetch the most recent report for the current filters.
</Step>
</Steps>
<img src="/images/compliance/prowler-app-cross-provider-report.png" alt="Report dropdown on the Cross-Provider Type Compliance detail page showing the Generate new report option" width="420" />
A report already generated for a given set of filters does not need to be generated again. When you open the detail page with a filter combination that was reported before, Prowler detects the existing report and surfaces **Report → Download latest** so you can download it immediately, without launching a new job. You only need to generate a fresh report when:
* You apply a filter combination that has never been reported before, or
* A contributing provider has completed a new scan since the report was generated. The report is tied to the specific scans it was built from, so a newer completed scan makes the previous report stale; Prowler recognizes it no longer matches the current selection and offers to generate an up-to-date one.
"Download latest" reuses an existing report only when it matches the framework, the exact resolved scan set for the current filters, and the same report options. This guarantees the PDF you download reflects the posture you are looking at, rather than a report generated for a different filter or an older scan.
<Note>
The PDF detail section renders only **failed** requirements by default so the report stays focused as an executive/auditor document. As with every Prowler PDF, the detail section is capped at the first 100 failed findings per check; use the per-scan CSV or JSON-OCSF exports for the complete, untruncated list. See [Downloading Compliance Reports](/user-guide/compliance/tutorials/compliance#downloading-compliance-reports) for the full PDF behavior and the `DJANGO_PDF_MAX_FINDINGS_PER_CHECK` setting.
</Note>
## Aggregating a Single-Provider Framework Across Providers
Universal frameworks answer the cross-provider-type question, but most compliance frameworks target a single provider type — CIS AWS, CIS GCP, ENS for Azure. The **Across providers** section of the Multiple Scans tab answers the sibling question for those frameworks: **"How compliant is my whole AWS estate against CIS AWS, together?"**
The aggregation works the same way, with the column axis swapped from provider type to individual provider, and it produces its own combined PDF report. See [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance) for the full guide.
## Related Documentation
* [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)
* [Compliance](/user-guide/compliance/tutorials/compliance)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
* [Creating a New Security Compliance Framework in Prowler](/developer-guide/security-compliance-framework)
* [Prowler Cloud — Getting Started](/user-guide/tutorials/prowler-app)
docs/user-guide/compliance/tutorials/threatscore.mdx
+8 -10
View File
@@ -3,18 +3,16 @@ title: "Prowler ThreatScore: unified compliance scoring"
description: "Prowler ThreatScore aggregates pass rate, severity, weight, and prevalence into a 0-100 compliance score for tracking cloud security posture over time."
---
## Introduction
The **Prowler ThreatScore** is a comprehensive compliance scoring system that provides a unified metric for assessing your organization's security posture across compliance frameworks. It aggregates findings from individual security checks into a single, normalized score ranging from 0 to 100.
Prowler ThreatScore is a comprehensive compliance scoring system that provides a unified metric for assessing security posture across compliance frameworks. It aggregates findings from individual security checks into a single, normalized score ranging from 0 to 100.
### Purpose
- **Unified View**: Get a single metric representing overall compliance health
- **Risk Prioritization**: Understand which areas pose the highest security risks
- **Progress Tracking**: Monitor improvements in compliance posture over time
- **Executive Reporting**: Provide clear, quantifiable security metrics to stakeholders
- **Unified view:** A single metric represents overall compliance health.
- **Risk prioritization:** Highlights which areas pose the highest security risks.
- **Progress tracking:** Monitors improvements in compliance posture over time.
- **Executive reporting:** Delivers clear, quantifiable security metrics to stakeholders.
## How ThreatScore Works
@@ -30,7 +28,7 @@ Pass Rate = (Number of PASS findings) / (Total findings)
The total number of checks performed (both PASS and FAIL) for a requirement. This represents the amount of evidence available - more findings provide greater confidence in the assessment.
### 3. Weight (`weight_i`)
A numerical value (1-1000) representing the business importance or criticality of the requirement within your organization's context.
A numerical value (1-1000) representing the business importance or criticality of the requirement within the organizational context.
### 4. Risk Level (`risk_i`)
A severity rating (1-5) indicating the potential impact of non-compliance with this requirement.
@@ -381,7 +379,7 @@ This comprehensive example demonstrates how:
### Example 4: Impact of Parameter Changes
Using the scenario, let's see how parameter changes affect the score:
Using the scenario, the following changes show how parameter adjustments affect the score:
#### Scenario A: Increase Encryption Risk Level
docs/user-guide/cookbooks/powerbi-cis-benchmarks.mdx
+4 -4
View File
@@ -14,7 +14,7 @@ The template and its source files live in the Prowler repository under [`contrib
The setup requires the following components:
* **Microsoft Power BI Desktop:** free download from Microsoft.
* **Prowler compliance CSV exports:** produced by Prowler CLI or downloaded from Prowler Cloud or Prowler App.
* **Prowler compliance CSV exports:** produced by Prowler CLI or downloaded from Prowler Cloud or Prowler Local Server.
* **Local directory:** holds the CSV exports that the template ingests at load time.
## Supported CIS Benchmarks
@@ -40,7 +40,7 @@ Download and install Microsoft Power BI Desktop from the official Microsoft site
### Step 2: Generate Compliance CSV Exports
Compliance CSV exports can be generated through Prowler CLI or downloaded from Prowler Cloud and Prowler App.
Compliance CSV exports can be generated through Prowler CLI or downloaded from Prowler Cloud and Prowler Local Server.
#### Option A: Prowler CLI
@@ -55,7 +55,7 @@ prowler kubernetes --compliance cis_1.12_kubernetes
The compliance CSV exports are written to `output/compliance/` by default.
#### Option B: Prowler Cloud or Prowler App
#### Option B: Prowler Cloud or Prowler Local Server
Open the Compliance section, select the desired CIS Benchmark, and download the CSV export.
@@ -160,7 +160,7 @@ A full walkthrough is available on YouTube:
<CardGroup cols={2}>
<Card title="Compliance Frameworks" icon="shield-check" href="/user-guide/compliance/tutorials/compliance">
Review the Compliance workflow across Prowler Cloud, Prowler App, and Prowler CLI.
Review the Compliance workflow across Prowler Cloud, Prowler Local Server, and Prowler CLI.
</Card>
<Card title="Prowler Dashboard" icon="chart-line" href="/user-guide/cli/tutorials/dashboard">
Explore the built-in local dashboard for Prowler CSV exports.
docs/user-guide/img/add-registry-url.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 235 KiB

After

Width:  |  Height:  |  Size: 195 KiB

docs/user-guide/img/image-authentication-filters.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 315 KiB

After

Width:  |  Height:  |  Size: 226 KiB

docs/user-guide/img/select-container-registry.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 316 KiB

After

Width:  |  Height:  |  Size: 214 KiB

docs/user-guide/providers/alibabacloud/getting-started-alibabacloud.mdx
+2 -2
View File
@@ -33,14 +33,14 @@ Before you begin, make sure you have:
### Step 1: Get Your Alibaba Cloud Account ID
1. Log in to the [Alibaba Cloud Console](https://home.console.alibabacloud.com/)
2. Click on your profile avatar in the top-right corner
2. Click your profile avatar in the top-right corner
3. Locate and copy your Account ID
![Get Account ID](/images/providers/alibaba-account-id.png)
### Step 2: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/aws/authentication.mdx
+5 -5
View File
@@ -8,9 +8,9 @@ Prowler requires AWS credentials to function properly. Authentication is availab
- Static Credentials
- Assumed Role
When using **Assumed Role**, the Prowler UI exposes two credential sources for calling `sts:AssumeRole`. The labels differ between Prowler Cloud and self-hosted Prowler App, but both map to the same underlying credential types:
When using **Assumed Role**, the Prowler UI exposes two credential sources for calling `sts:AssumeRole`. The labels differ between Prowler Cloud and Prowler Local Server, but both map to the same underlying credential types:
- **AWS SDK Default** (shown as *"Prowler Cloud will assume your IAM role"* in Prowler Cloud and *"AWS SDK Default"* in self-hosted Prowler App): Prowler uses the credentials already available to the API and worker containers through the [AWS SDK default credential chain](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html). This is the default in Prowler Cloud and requires extra configuration in self-hosted Prowler App (see [Configuring AWS SDK Default for Self-Hosted Prowler App](#configuring-aws-sdk-default-for-self-hosted-prowler-app)).
- **AWS SDK Default** (shown as *"Prowler Cloud will assume your IAM role"* in Prowler Cloud and *"AWS SDK Default"* in Prowler Local Server): Prowler uses the credentials already available to the API and worker containers through the [AWS SDK default credential chain](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html). This is the default in Prowler Cloud and requires extra configuration in Prowler Local Server (see [Configuring AWS SDK Default for Prowler Local Server](#configuring-aws-sdk-default-for-prowler-local-server)).
- **Access & Secret Key**: You paste an IAM user's `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and optionally `AWS_SESSION_TOKEN` into the form. Prowler uses those keys to call `sts:AssumeRole`.
## Required Permissions
@@ -82,9 +82,9 @@ This method grants permanent access and is the recommended setup for production
---
## Configuring AWS SDK Default for Self-Hosted Prowler App
## Configuring AWS SDK Default for Prowler Local Server
When self-hosting Prowler App with Docker Compose, the API and worker containers do not have AWS credentials by default. Selecting **AWS SDK Default** without configuring those credentials produces:
When running Prowler Local Server with Docker Compose, the API and worker containers do not have AWS credentials by default. Selecting **AWS SDK Default** without configuring those credentials produces:
```
AWSAssumeRoleError[1012]: AWS assume role error - An error occurred (InvalidClientTokenId) when calling the AssumeRole operation: The security token included in the request is invalid.
@@ -117,7 +117,7 @@ docker compose up -d --force-recreate api worker worker-beat
### Option 2: IAM Role (Host with Instance Metadata)
If you run Prowler App on an EC2 instance, ECS task, or EKS pod with an attached IAM role that can assume the scan role, no extra configuration is needed — `boto3` resolves credentials through instance or task metadata automatically.
If you run Prowler Local Server on an EC2 instance, ECS task, or EKS pod with an attached IAM role that can assume the scan role, no extra configuration is needed — `boto3` resolves credentials through instance or task metadata automatically.
### Trust Policy: Align `IAMPrincipal` With Your Identity
docs/user-guide/providers/aws/boto3-configuration.mdx
+1 -1
View File
@@ -50,6 +50,6 @@ For testing or modifying Prowler's behavior, use the following steps to confirm
* Run prowler with `--log-level DEBUG` and `--log-file debuglogs.txt`
* Search for retry attempts using `grep -i 'Retry needed' debuglogs.txt`
This approach follows the [AWS documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html#checking-retry-attempts-in-your-client-logs), which states that if a retry is performed, a message starting with "Retry needed” will be prompted.
This approach follows the [AWS documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html#checking-retry-attempts-in-your-client-logs), which states that if a retry is performed, a message starting with "Retry needed" will be prompted.
It is possible to determine the total number of calls made using `grep -i 'Sending http request' debuglogs.txt | wc -l`
docs/user-guide/providers/aws/cloudshell.mdx
+1 -1
View File
@@ -3,7 +3,7 @@ title: 'Install and Run Prowler in AWS CloudShell'
description: 'Install Prowler in AWS CloudShell on Amazon Linux 2023, run AWS security scans, and download output reports directly from the browser shell.'
---
## Following the migration of AWS CloudShell from Amazon Linux 2 to Amazon Linux 2023
## Following the Migration of AWS CloudShell from Amazon Linux 2 to Amazon Linux 2023
AWS CloudShell has migrated from Amazon Linux 2 to Amazon Linux 2023 [[1]](https://aws.amazon.com/about-aws/whats-new/2023/12/aws-cloudshell-migrated-al2023/) [[2]](https://docs.aws.amazon.com/cloudshell/latest/userguide/cloudshell-AL2023-migration.html). With this transition, Python 3.9 is now included by default in AL2023, eliminating the need for manual compilation.
docs/user-guide/providers/aws/getting-started-aws.mdx
+5 -5
View File
@@ -19,7 +19,7 @@ description: 'Onboard an AWS account to Prowler Cloud: locate your account ID, a
### Step 2: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
@@ -68,7 +68,7 @@ This method grants permanent access and is the recommended setup for production
For detailed instructions on how to create the role, see [Authentication > Assume Role](/user-guide/providers/aws/authentication#assume-role-recommended).
7. Once the role is created, go to the **IAM Console**, click on the "ProwlerScan" role to open its details:
7. Once the role is created, go to the **IAM Console**, click the "ProwlerScan" role to open its details:
![ProwlerScan role info](/images/providers/prowler-scan-pre-info.png)
@@ -76,13 +76,13 @@ For detailed instructions on how to create the role, see [Authentication > Assum
![New Role Info](/images/providers/get-role-arn.png)
9. Paste the ARN into the corresponding field in Prowler Cloud or Prowler App
9. Paste the ARN into the corresponding field in Prowler Cloud or Prowler Local Server
![Input the Role ARN](/images/providers/paste-role-arn-prowler.png)
10. Select the credential source Prowler should use to call `sts:AssumeRole`. The option label differs between deployments but both map to the same `aws-sdk-default` credential type:
- **"Prowler Cloud will assume your IAM role"** (default in Prowler Cloud) / **"AWS SDK Default"** (in self-hosted Prowler App): Prowler uses the credentials available in the API and worker environment through the [AWS SDK default credential chain](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html). In self-hosted Prowler App, these containers have no AWS credentials by default — see [Configuring AWS SDK Default for Self-Hosted Prowler App](/user-guide/providers/aws/authentication#configuring-aws-sdk-default-for-self-hosted-prowler-app) before choosing this option, or the connection test will fail with `InvalidClientTokenId`.
- **"Prowler Cloud will assume your IAM role"** (default in Prowler Cloud) / **"AWS SDK Default"** (in Prowler Local Server): Prowler uses the credentials available in the API and worker environment through the [AWS SDK default credential chain](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html). In Prowler Local Server, these containers have no AWS credentials by default — see [Configuring AWS SDK Default for Prowler Local Server](/user-guide/providers/aws/authentication#configuring-aws-sdk-default-for-prowler-local-server) before choosing this option, or the connection test will fail with `InvalidClientTokenId`.
- **Access & Secret Key**: Paste an IAM user's `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` (and optional `AWS_SESSION_TOKEN`) into the form. The IAM principal must be allowed to assume the target role and must match the `IAMPrincipal` parameter of the scan role template (default: `role/prowler*`).
11. Click "Next", then "Launch Scan"
@@ -111,7 +111,7 @@ AWS accounts can also be configured using static credentials (not recommended fo
For detailed instructions on how to create the credentials, see [Authentication > Credentials](/user-guide/providers/aws/authentication#credentials).
1. Complete the form in Prowler Cloud or Prowler App and click "Next"
1. Complete the form in Prowler Cloud or Prowler Local Server and click "Next"
![Filled credentials page](/images/providers/prowler-cloud-credentials-next.png)
docs/user-guide/providers/aws/img/select-auth-method.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 117 KiB

After

Width:  |  Height:  |  Size: 189 KiB

docs/user-guide/providers/aws/multiaccount.mdx
+3 -3
View File
@@ -3,7 +3,7 @@ title: 'Scan Multiple AWS Accounts with Prowler'
description: 'Run Prowler across many AWS accounts sequentially or in parallel using IAM assume role, ideal for auditing several accounts from one entry point.'
---
Prowler enables security scanning across multiple AWS accounts by utilizing the [Assume Role feature](/user-guide/providers/aws/role-assumption) and [integration with AWS Organizations feature](/user-guide/providers/aws/organizations).
Prowler enables security scanning across multiple AWS accounts by utilizing the [Assume Role feature](/user-guide/providers/aws/role-assumption) and [integration with AWS Organizations feature](/user-guide/providers/aws/organizations).
This approach allows execution from a single account with permissions to assume roles in the target accounts.
@@ -17,7 +17,7 @@ To scan specific accounts one at a time:
ACCOUNTS_LIST='11111111111 2222222222 333333333'
```
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with to yours, that is to be consistent throughout all accounts):
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with yours, that is to be consistent throughout all accounts):
```
ROLE_TO_ASSUME=<role_name>
@@ -36,7 +36,7 @@ Define the AWS accounts to be scanned with a variable:
ACCOUNTS_LIST='11111111111 2222222222 333333333'
```
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with to yours, that is to be consistent throughout all accounts). The following example executes scanning across three accounts in parallel:
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with yours, that is to be consistent throughout all accounts). The following example executes scanning across three accounts in parallel:
```
ROLE_TO_ASSUME=<role_name>
docs/user-guide/providers/aws/organizations.mdx
+37 -3
View File
@@ -3,10 +3,12 @@ title: 'AWS Organizations Integration with Prowler'
description: 'Integrate Prowler with AWS Organizations to auto-discover member accounts, enrich findings with account metadata, and deploy scan roles via StackSets.'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
<Info>
**Using Prowler Cloud?** You can onboard your entire AWS Organization through the UI with automatic account discovery, OU-aware tree selection, and bulk connection testing — no scripts or YAML files required.
See [AWS Organizations in Prowler Cloud](/user-guide/tutorials/prowler-cloud-aws-organizations) for the full walkthrough.
See [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations) in Prowler Cloud for the full walkthrough.
</Info>
Prowler can integrate with AWS Organizations to manage the visibility and onboarding of accounts centrally.
@@ -72,11 +74,43 @@ The additional fields in CSV header output are as follows:
## Deploying Prowler IAM Roles Across AWS Organizations
<VersionBadge version="5.35.0" />
When onboarding multiple AWS accounts into Prowler Cloud, it is important to deploy the Prowler Scan IAM Role in each account. The most efficient way to do this across an AWS Organization is by leveraging AWS CloudFormation StackSets, which rolls out infrastructure—like IAM roles—to all accounts centrally from the Management or Delegated Admin account.
When using Infrastructure as Code (IaC), Terraform is recommended to manage this deployment systematically.
### Native CloudFormation StackSet Deployment (Recommended)
### Recommended Approach
The [Prowler Scan IAM Role CloudFormation template](https://github.com/prowler-cloud/prowler/blob/master/permissions/templates/cloudformation/prowler-scan-role.yml) can deploy the role across your entire AWS Organization on its own—no third-party modules required. When launched in the **Management Account** (or a **Delegated Administrator** account) with `DeployStackSet=true` and `EnableOrganizations=true`, it creates a service-managed CloudFormation StackSet that rolls the ProwlerScan role out to every account under the target Organizational Unit (or the organization root), and keeps new accounts covered automatically through auto-deployment.
To deploy from the CloudFormation console: open **CloudFormation → Create stack → With new resources**, choose **Upload a template file** and select `prowler-scan-role.yml` (or paste its S3 URL), then set the parameters below on the **Specify stack details** step. Leave the **Configure stack options** step at its defaults.
Deploy a single CloudFormation Stack in the Management Account with the following parameters:
| Parameter | Description | Default |
| --- | --- | --- |
| `ExternalId` | External ID provided by Prowler Cloud to secure role assumption. | — |
| `DeployLocalRole` | Create the ProwlerScan role in this (Management) account. | `true` |
| `DeployStackSet` | Create a service-managed StackSet that deploys the role to member accounts. | `false` |
| `AWSOrganizationalUnitId` | Target OU (`ou-xxxx-yyyyyyyy`) or organization root (`r-xxxx`) for the StackSet. Required when `DeployStackSet=true`. | `""` |
| `DeployFromDelegatedAdmin` | Set to `true` when deploying from a Delegated Administrator account instead of the Management Account (uses `CallAs: DELEGATED_ADMIN`). | `false` |
| `EnableOrganizations` | Add AWS Organizations permissions to the Management Account role: read-only account discovery plus the StackSet-management permissions the deployment needs. Set to `true` when deploying in the Management Account. | `false` |
| `FailureTolerancePercentage` | Percentage of accounts in which the StackSet operation can fail before CloudFormation stops the operation. | `10` |
| `RetainStacksOnAccountRemoval` | Keep the role in an account after it leaves the Organization or OU. | `false` |
<Warning>
On the review step, select **"I acknowledge that AWS CloudFormation might create IAM resources with custom names"** — the template provisions the named `ProwlerScan` IAM role, so the stack requires the `CAPABILITY_NAMED_IAM` capability and fails without this acknowledgment. (The quick-create link handles this for you.)
</Warning>
<Note>
The service-managed StackSet does **not** deploy to the Management Account itself. Keeping `DeployLocalRole=true` ensures the role also exists there, so a single stack covers both the Management and member accounts.
Trusted access for CloudFormation StackSets must be enabled in the Organization (see the note at the top of this page) before `DeployStackSet` will work.
Deploying for the CLI or a self-hosted Prowler (not Prowler Cloud)? Also set `AccountId` to the account you assume the role from and `IAMPrincipal` to your identity — the defaults target Prowler Cloud. See [Aligning the trust policy with your identity](/user-guide/providers/aws/authentication#trust-policy-align-iamprincipal-with-your-identity).
</Note>
### Alternative: Deploy with Terraform
- **Use StackSets** from the **Management Account** (or a Delegated Admin/Security Account).
- **Use Terraform** to orchestrate the deployment.
docs/user-guide/providers/aws/regions-and-partitions.mdx
+1 -1
View File
@@ -65,7 +65,7 @@ When more than one source is set, precedence is:
3. `aws.disallowed_regions` in `config.yaml`
<Note>
For self-hosted App or API-triggered scans, set `PROWLER_AWS_DISALLOWED_REGIONS` in the runtime environment of the backend scan containers such as `api` and `worker`. The `ui` container does not enforce AWS region selection.
For Prowler Local Server or API-triggered scans, set `PROWLER_AWS_DISALLOWED_REGIONS` in the runtime environment of the backend scan containers such as `api` and `worker`. The `ui` container does not enforce AWS region selection.
</Note>
docs/user-guide/providers/aws/role-assumption.mdx
+9
View File
@@ -78,6 +78,15 @@ The template requires the following parameters:
- **AccountId:** *(Optional)* AWS Account ID that will assume the role (default: Prowler Cloud account)
- **IAMPrincipal:** *(Optional)* The IAM principal allowed to assume the role (default: `role/prowler*`)
<Warning>
From the CLI you assume the role with **your own** identity, not from Prowler Cloud. The `AccountId` and `IAMPrincipal` defaults target Prowler Cloud, so set **`AccountId`** to the account you run Prowler from and **`IAMPrincipal`** to your identity (for example `role/<name>` or `user/<name>`). Otherwise `sts:AssumeRole` fails with `AccessDenied`. See [Aligning the trust policy with your identity](/user-guide/providers/aws/authentication#trust-policy-align-iamprincipal-with-your-identity).
</Warning>
<Note>
To deploy the role across an entire AWS Organization from a single stack (Management Account role plus a service-managed StackSet for the member accounts), the template also accepts `DeployLocalRole`, `DeployStackSet`, `AWSOrganizationalUnitId`, `DeployFromDelegatedAdmin`, `EnableOrganizations`, `FailureTolerancePercentage`, and `RetainStacksOnAccountRemoval`. See [AWS Organizations in Prowler](/user-guide/providers/aws/organizations#native-cloudformation-stackset-deployment-recommended) for the full parameter reference.
</Note>
When running Prowler CLI, include the External ID using the `-I/--external-id` flag:
```sh
docs/user-guide/providers/aws/securityhub.mdx
+3 -3
View File
@@ -3,7 +3,7 @@ title: 'AWS Security Hub Integration with Prowler'
description: 'Send Prowler findings to AWS Security Hub by enabling the integration per region, then push results into ASFF for centralized security posture.'
---
Prowler natively supports **official integration** with [AWS Security Hub](https://aws.amazon.com/security-hub), allowing security findings to be sent directly. This integration enables **Prowler** to import its findings into AWS Security Hub.
Prowler natively supports **official integration** with [AWS Security Hub](https://aws.amazon.com/security-hub), allowing security findings to be sent directly. This integration enables **Prowler** to import its findings into AWS Security Hub.
To activate the integration, follow these steps in at least one AWS region within your AWS account:
@@ -79,7 +79,7 @@ aws securityhub enable-import-findings-for-product --region eu-west-1 --product-
```
<Note>
Specify the AWS region where you want to enable the integration. Ensure the region is correctly set within the ARN value. This command requires the`securityhub:securityhub:EnableImportFindingsForProduct` permission.
Specify the AWS region where you want to enable the integration. Ensure the region is correctly set within the ARN value. This command requires the `securityhub:EnableImportFindingsForProduct` permission.
</Note>
## Sending Findings to AWS Security Hub
@@ -101,7 +101,7 @@ prowler --security-hub --region eu-west-1
<Note>
It is recommended to send only fails to Security Hub and that is possible adding `--status FAIL` to the command. You can use, instead of the `--status FAIL` argument, the `--send-sh-only-fails` argument to save all the findings in the Prowler outputs but just to send FAIL findings to AWS Security Hub.
Since Prowler perform checks to all regions by default you may need to filter by region when running Security Hub integration, as shown in the example above. Remember to enable Security Hub in the region or regions you need by calling `aws securityhub enable-security-hub --region <region>` and run Prowler with the option `-f/--region <region>` (if no region is used it will try to push findings in all regions hubs). Prowler will send findings to the Security Hub on the region where the scanned resource is located.
Since Prowler performs checks to all regions by default you may need to filter by region when running Security Hub integration, as shown in the example above. Remember to enable Security Hub in the region or regions you need by calling `aws securityhub enable-security-hub --region <region>` and run Prowler with the option `-f/--region <region>` (if no region is used it will try to push findings in all regions hubs). Prowler will send findings to the Security Hub on the region where the scanned resource is located.
To have updated findings in Security Hub you have to run Prowler periodically. Once a day or every certain amount of hours.
docs/user-guide/providers/aws/v2_to_v3_checks_mapping.mdx
+1 -1
View File
@@ -20,7 +20,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",
docs/user-guide/providers/azure/authentication.mdx
+6 -4
View File
@@ -3,9 +3,9 @@ title: 'Azure Authentication in Prowler'
description: 'Authenticate Prowler for Azure with a service principal, az CLI, browser login, or managed identity, and grant the required Entra and RBAC permissions.'
---
Prowler for Azure supports multiple authentication types. Authentication methods vary between Prowler App and Prowler CLI:
Prowler for Azure supports multiple authentication types. Authentication methods vary between Prowler Cloud and Prowler CLI:
**Prowler App:**
**Prowler Cloud:**
- [**Service Principal Application**](#service-principal-application-authentication-recommended)
@@ -146,7 +146,7 @@ The checks requiring this `ProwlerRole` can be found in this [section](/user-gui
1. To create a new custom role, open a terminal and execute the following command:
```console
az role definition create --role-definition '{ 640ms  lun 16 dic 17:04:17 2024
az role definition create --role-definition '{
"Name": "ProwlerRole",
"IsCustom": true,
"Description": "Role used for checks that require read-only access to Azure resources and are not covered by the Reader role.",
@@ -211,13 +211,15 @@ For more detailed guidance on subscription management and permissions:
The following security checks require the `ProwlerRole` permissions for execution. Ensure the role is assigned to the identity assumed by Prowler before running these checks:
- `app_function_access_keys_configured`
- `app_function_application_insights_enabled`
- `app_function_ftps_deployment_disabled`
- `app_function_latest_runtime_version`
---
## Service Principal Application Authentication (Recommended)
This method is required for Prowler App and recommended for Prowler CLI.
This method is required for Prowler Cloud and recommended for Prowler CLI.
### Creating the Service Principal
For more information, see [Creating Prowler Service Principal](/user-guide/providers/azure/create-prowler-service-principal).
docs/user-guide/providers/azure/getting-started-azure.mdx
+5 -5
View File
@@ -17,7 +17,7 @@ Government cloud subscriptions (Azure Government) are not currently supported, b
</Note>
### Prerequisites
Before setting up Azure in Prowler App, you need to create a Service Principal with proper permissions.
Before setting up Azure in Prowler Cloud, you need to create a Service Principal with proper permissions.
For detailed instructions on how to create the Service Principal and configure permissions, see [Authentication > Service Principal](/user-guide/providers/azure/authentication#service-principal-application-authentication-recommended).
@@ -35,12 +35,12 @@ For detailed instructions on how to create the Service Principal and configure p
### Step 2: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Navigate to `Configuration` > `Providers`
![Providers Page](/images/prowler-app/cloud-providers-page.png)
3. Click on `Add Provider`
3. Click `Add Provider`
![Add a Provider](/images/prowler-app/add-cloud-provider.png)
@@ -54,14 +54,14 @@ For detailed instructions on how to create the Service Principal and configure p
### Step 3: Add Credentials to Prowler Cloud
For Azure, Prowler App uses a service principal application to authenticate. For more information about the process of creating and adding permissions to a service principal refer to this [section](/user-guide/providers/azure/authentication). When you finish creating and adding the [Entra](/user-guide/providers/azure/create-prowler-service-principal#assigning-proper-permissions) and [Subscription](/user-guide/providers/azure/subscriptions) scope permissions to the service principal, enter the `Tenant ID`, `Client ID` and `Client Secret` of the service principal application.
For Azure, Prowler Cloud uses a service principal application to authenticate. For more information about the process of creating and adding permissions to a service principal refer to this [section](/user-guide/providers/azure/authentication). When you finish creating and adding the [Entra](/user-guide/providers/azure/create-prowler-service-principal#assigning-proper-permissions) and [Subscription](/user-guide/providers/azure/subscriptions) scope permissions to the service principal, enter the `Tenant ID`, `Client ID` and `Client Secret` of the service principal application.
1. Go to your App Registration overview and copy the `Client ID` and `Tenant ID`
![App Overview](/images/providers/app-overview.png)
2. Go to Prowler App and paste:
2. Go to Prowler Cloud and paste:
- `Client ID`
- `Tenant ID`
docs/user-guide/providers/azure/subscriptions.mdx
+1 -1
View File
@@ -18,7 +18,7 @@ prowler azure --az-cli-auth --subscription-ids <subscription ID 1> <subscription
Prowler allows you to specify one or more subscriptions for scanning (up to N), enabling flexible audit configurations.
<Warning>
The multi-subscription feature is available only in the CLI. In Prowler App, each scan is limited to a single subscription.
The multi-subscription feature is available only in the CLI. In Prowler Cloud, each scan is limited to a single subscription.
</Warning>
## Assigning Permissions for Subscription Scans
docs/user-guide/providers/cloudflare/authentication.mdx
+4 -4
View File
@@ -57,8 +57,8 @@ Template URLs only pre-fill the token creation form. Review the permissions, con
### Step 1: Create a User API Token
1. Log into the [Cloudflare Dashboard](https://dash.cloudflare.com).
2. Click on the profile icon in the top right corner, then select "My Profile".
3. Click on the **API Tokens** tab.
2. Click the profile icon in the top right corner, then select "My Profile".
3. Click the **API Tokens** tab.
4. Click **Create Token**, then select **Create Custom Token** at the bottom of the page.
5. Configure the token with the following settings:
- **Token name:** A descriptive name (e.g., "Prowler Security Scanner")
@@ -103,8 +103,8 @@ API Keys provide full access to the Cloudflare account. While supported, this me
### Step 1: Get the Global API Key
1. Log into the [Cloudflare Dashboard](https://dash.cloudflare.com).
2. Click on the profile icon in the top right corner, then select "My Profile".
3. Click on the **API Tokens** tab.
2. Click the profile icon in the top right corner, then select "My Profile".
3. Click the **API Tokens** tab.
4. Scroll down to the **API Keys** section.
5. Click **View** next to **Global API Key**.
6. Enter the account password to reveal the key, then copy it.
docs/user-guide/providers/cloudflare/getting-started-cloudflare.mdx
+1 -1
View File
@@ -51,7 +51,7 @@ The Account ID is a 32-character hexadecimal string (e.g., `372e67954025e0ba6aaa
### Step 2: Open Prowler Cloud
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Navigate to "Configuration" > "Providers".
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/gcp/authentication.mdx
+2 -2
View File
@@ -56,7 +56,7 @@ This method uses the Google Cloud CLI to authenticate and is suitable for develo
### Setup Application Default Credentials
1. In the [GCP Console](https://console.cloud.google.com/), click on "Activate Cloud Shell"
1. In the [GCP Console](https://console.cloud.google.com/), click "Activate Cloud Shell"
![Activate Cloud Shell](/images/providers/access-console.png)
@@ -90,7 +90,7 @@ This method uses the Google Cloud CLI to authenticate and is suitable for develo
![Get the FileName](/images/providers/get-temp-file-credentials.png)
8. Extract the following values for Prowler Cloud/App:
8. Extract the following values for Prowler Cloud or Prowler Local Server:
- `client_id`
- `client_secret`
docs/user-guide/providers/gcp/getting-started-gcp.mdx
+2 -2
View File
@@ -14,7 +14,7 @@ description: 'Onboard a Google Cloud project to Prowler Cloud: retrieve the GCP
### Step 2: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
@@ -67,7 +67,7 @@ For Google Cloud, first enter your `GCP Project ID` and then select the authenti
2. Once authenticated, get the `Client ID`, `Client Secret` and `Refresh Token` from `~/.config/gcloud/application_default_credentials`.
3. Paste the `Client ID`, `Client Secret` and `Refresh Token` into Prowler App.
3. Paste the `Client ID`, `Client Secret` and `Refresh Token` into Prowler Cloud.
<img src="/images/gcp-credentials.png" alt="GCP Credentials" width="700" />
docs/user-guide/providers/gcp/img/launch-scan.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 296 KiB

docs/user-guide/providers/github/authentication.mdx
+3 -3
View File
@@ -13,7 +13,7 @@ Prowler offers three authentication methods. Fine-Grained Personal Access Tokens
| Method | Best For | Key Benefit |
|--------|----------|-------------|
| [**Fine-Grained Personal Access Token**](#fine-grained-personal-access-token-recommended) | Individual users, quick setup | Simple, user-scoped access |
| [**Fine-Grained Personal Access Token**](#fine-grained-personal-access-token-recommended-for-individual-use) | Individual users, quick setup | Simple, user-scoped access |
| [**GitHub App**](#github-app-credentials) | Organizations, automation, CI/CD | Organization-scoped, no personal account dependency |
| [**OAuth App Token**](#oauth-app-token) | Delegated user authorization | User-consented access flows |
@@ -272,7 +272,7 @@ Store the `.pem` private key securely. Anyone with this key can authenticate as
## Prowler Cloud Authentication
For step-by-step setup instructions for Prowler Cloud, see the [Getting Started Guide](/user-guide/providers/github/getting-started-github#prowler-cloudapp).
For step-by-step setup instructions for Prowler Cloud, see the [Getting Started Guide](/user-guide/providers/github/getting-started-github#prowler-cloud-and-prowler-local-server).
### Using Personal Access Token
@@ -302,7 +302,7 @@ For step-by-step setup instructions for Prowler Cloud, see the [Getting Started
3. Enter your GitHub App ID and upload the private key (`.pem` file).
For complete step-by-step instructions, see the [Getting Started Guide](/user-guide/providers/github/getting-started-github#prowler-cloudapp).
For complete step-by-step instructions, see the [Getting Started Guide](/user-guide/providers/github/getting-started-github#prowler-cloud-and-prowler-local-server).
---
docs/user-guide/providers/github/getting-started-github.mdx
+5 -5
View File
@@ -17,7 +17,7 @@ Prowler can scan either:
</Note>
<CardGroup cols={2}>
<Card title="Prowler Cloud/App" icon="cloud" href="#prowler-cloudapp">
<Card title="Prowler Cloud & Local Server" icon="cloud" href="#prowler-cloud-and-prowler-local-server">
Web-based interface with centralized management
</Card>
<Card title="Prowler CLI" icon="terminal" href="#prowler-cli">
@@ -27,7 +27,7 @@ Prowler can scan either:
---
## Prowler Cloud/App
## Prowler Cloud and Prowler Local Server
<iframe width="560" height="380" src="https://www.youtube-nocookie.com/embed/9ETI84Xpu2g" title="Prowler Cloud Onboarding Github" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="1"></iframe>
@@ -35,7 +35,7 @@ Prowler can scan either:
### Prerequisites
Before adding GitHub to Prowler Cloud/App, ensure you have:
Before adding GitHub to Prowler Cloud or Prowler Local Server, ensure you have:
1. **GitHub Account Access**
- Personal GitHub account, OR
@@ -47,9 +47,9 @@ Before adding GitHub to Prowler Cloud/App, ensure you have:
- OAuth App Token
- GitHub App Credentials (Not Recommended - limited data access)
### Step 1: Access Prowler Cloud/App
### Step 1: Access Prowler Cloud or Prowler Local Server
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to **Configuration** → **Providers**
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/googleworkspace/getting-started-googleworkspace.mdx
+1 -1
View File
@@ -43,7 +43,7 @@ The Customer ID starts with the letter "C" followed by alphanumeric characters (
### Step 2: Open Prowler Cloud
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Navigate to "Configuration" > "Providers".
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/huaweicloud/authentication.mdx
+135
View File
@@ -0,0 +1,135 @@
---
title: "Huawei Cloud Authentication in Prowler"
---
import { VersionBadge } from "/snippets/version-badge.mdx"
<VersionBadge version="5.37.0" />
Prowler for Huawei Cloud authenticates against the Huawei Cloud APIs using an IAM user's **Access Key ID** and **Secret Access Key** (AK/SK). Credentials are read exclusively from environment variables to avoid exposing secrets in shell history or process listings; there are no credential CLI flags.
## Required Credentials
Prowler requires read access to the Huawei Cloud account. The following values are supported:
| Credential | Environment Variable | Description |
|------------|----------------------|-------------|
| Access Key ID | `HUAWEICLOUD_ACCESS_KEY_ID` (or `HW_ACCESS_KEY`) | Permanent access key ID of the IAM user |
| Secret Access Key | `HUAWEICLOUD_SECRET_ACCESS_KEY` (or `HW_SECRET_KEY`) | Secret access key paired with the access key ID |
| Domain ID | `HUAWEICLOUD_DOMAIN_ID` (or `HW_DOMAIN_ID`) | Optional account (domain) ID |
| Security Token | `HUAWEICLOUD_SECURITY_TOKEN` | Optional security token for temporary credentials |
| Region | `HUAWEICLOUD_REGION` (or `HW_REGION`) | Default region(s) when `--region` is not passed (e.g. `eu-west-101`) |
| Cloud | `HUAWEICLOUD_CLOUD` (or `HW_CLOUD`) | Scan every region of a cloud (`international`, `europe`, or `china`) when no region is set |
<Note>
The endpoint domain (`.eu` or `.com`) and the per-region project ID are resolved automatically from the region, so neither endpoint nor project configuration is needed. Multi-region scans work out of the box. For the region precedence rules and the full list of supported regions, see [Regions and Clouds](/user-guide/providers/huaweicloud/getting-started-huaweicloud#regions-and-clouds).
</Note>
<Warning>
Huawei Cloud runs separate clouds: **International** and **China** (`.com` endpoints) and **Huawei Cloud Europe** (`.eu` endpoints). The region (or `--cloud` selector) determines the endpoint, so accounts outside China must select a region they can reach — for example `eu-west-101` for a Huawei Cloud Europe account. A single set of credentials belongs to one cloud, so it cannot authenticate against both `.com` and `.eu`; scan each account with its own credentials.
</Warning>
---
## API Credentials
### Step 1: Create an Access Key (AK/SK)
1. Log in to the [Huawei Cloud console](https://console-intl.huaweicloud.com).
2. Open **My Credentials** from the account menu, then select **Access Keys**.
3. Click **Create Access Key** and complete the identity verification.
4. Download the `credentials.csv` file — it contains the Access Key ID and Secret Access Key. The secret is not shown again.
<Warning>
Use an IAM user with read-only permissions (for example, the built-in `ReadOnly` policy) rather than the account root credentials.
</Warning>
### Step 2: Configure Authentication
Export the credentials as environment variables:
```bash
export HUAWEICLOUD_ACCESS_KEY_ID="your-access-key-id"
export HUAWEICLOUD_SECRET_ACCESS_KEY="your-secret-access-key"
```
Then run Prowler:
```bash
prowler huaweicloud
```
---
## Assuming an Agency (Cross-Account)
To scan a different account, assume an [agency](https://support.huaweicloud.com/intl/en-us/usermanual-iam/iam_06_0002.html) delegated to your account. Set the agency name and the target account, and Prowler exchanges the base credentials for temporary credentials scoped to the agency:
```bash
export HUAWEICLOUD_ACCESS_KEY_ID="your-access-key-id"
export HUAWEICLOUD_SECRET_ACCESS_KEY="your-secret-access-key"
export HUAWEICLOUD_AGENCY_NAME="your-agency-name"
export HUAWEICLOUD_ASSUME_DOMAIN_ID="target-account-domain-id" # or HUAWEICLOUD_ASSUME_DOMAIN_NAME
prowler huaweicloud
```
| Environment Variable | Description |
|----------------------|-------------|
| `HUAWEICLOUD_AGENCY_NAME` | Name of the agency to assume in the target account |
| `HUAWEICLOUD_ASSUME_DOMAIN_ID` | Domain ID of the target (delegating) account |
| `HUAWEICLOUD_ASSUME_DOMAIN_NAME` | Domain name of the target account (alternative to the domain ID) |
---
## Verifying Authentication
To confirm that Prowler can reach the account, run a scan against a single region the account can reach:
```bash
# China account
prowler huaweicloud --region cn-north-4
# International account
prowler huaweicloud --region ap-southeast-1
# Huawei Cloud Europe account
prowler huaweicloud --region eu-west-101
```
To scan the account's entire cloud instead, use the `--cloud` selector:
```bash
prowler huaweicloud --cloud europe
```
A successful run reports findings for the discovered resources. A failed run displays an error message indicating the credential or connectivity issue.
---
## CI/CD Integration
For automated pipelines, set the credentials as secret environment variables:
**GitHub Actions:**
```yaml
env:
HUAWEICLOUD_ACCESS_KEY_ID: ${{ secrets.HUAWEICLOUD_ACCESS_KEY_ID }}
HUAWEICLOUD_SECRET_ACCESS_KEY: ${{ secrets.HUAWEICLOUD_SECRET_ACCESS_KEY }}
steps:
- name: Run Prowler
run: prowler huaweicloud
```
**GitLab CI:**
```yaml
variables:
HUAWEICLOUD_ACCESS_KEY_ID: $HUAWEICLOUD_ACCESS_KEY_ID
HUAWEICLOUD_SECRET_ACCESS_KEY: $HUAWEICLOUD_SECRET_ACCESS_KEY
prowler_scan:
script:
- prowler huaweicloud
```
docs/user-guide/providers/huaweicloud/getting-started-huaweicloud.mdx
+177
View File
@@ -0,0 +1,177 @@
---
title: 'Getting Started With Huawei Cloud on Prowler'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
<VersionBadge version="5.37.0" />
Prowler for Huawei Cloud scans your Huawei Cloud account for security misconfigurations across compute, storage, networking, identity, encryption, database, and logging services.
<Note>
Huawei Cloud support in Prowler is community-maintained. For commercial support or to request additional service coverage, [contact us](https://prowler.com/contact).
</Note>
## Prerequisites
Set up authentication for Huawei Cloud with the [Huawei Cloud Authentication](/user-guide/providers/huaweicloud/authentication) guide before starting:
- Create an Access Key ID and Secret Access Key (AK/SK) for an IAM user with read-only permissions.
- Prowler reads the credentials exclusively from environment variables, so secrets are never passed on the command line.
## Prowler CLI
### Run Prowler for Huawei Cloud
Once authenticated, export the credentials as environment variables and run Prowler for Huawei Cloud. Environment variables keep secrets out of shell history and process listings:
```bash
export HUAWEICLOUD_ACCESS_KEY_ID="your-access-key-id"
export HUAWEICLOUD_SECRET_ACCESS_KEY="your-secret-access-key"
prowler huaweicloud
```
### Run Specific Checks
```bash
prowler huaweicloud --checks obs_bucket_public_access iam_user_mfa_enabled
```
### Run a Specific Service
```bash
prowler huaweicloud --services iam
```
## Regions and Clouds
Huawei Cloud operates as three separate clouds, and every account belongs to exactly one of them:
- **International** — served from the `.com` endpoints (for example `myhuaweicloud.com`).
- **China** — also served from the `.com` endpoints, on the China regions (`cn-*`).
- **Huawei Cloud Europe** — served from the `.eu` endpoints (for example `myhuaweicloud.eu`).
The cloud is a property of the region: each region ID maps to exactly one endpoint domain. Prowler selects the correct endpoint automatically from the region, so no endpoint configuration is required.
### Region Selection Precedence
Prowler resolves the regions to scan from the first source that is set, in this order:
1. **`--region` flag** (aliases `--filter-region`, `-f`) — one or more explicit region IDs.
2. **`HUAWEICLOUD_REGION`** (or `HW_REGION`) environment variable — one or more region IDs, separated by spaces or commas.
3. **`--cloud` selector** (or `HUAWEICLOUD_CLOUD` / `HW_CLOUD`) — expands to every region of the selected cloud.
4. **Default** — when none is set, Prowler falls back to its built-in region list.
A more specific source always wins: `--region` overrides `HUAWEICLOUD_REGION`, which overrides `--cloud`.
### Select Specific Regions
To scan a defined set of regions, pass the region IDs to `--region` or set `HUAWEICLOUD_REGION`. Accounts outside China must select a region they can reach — for example `eu-west-101` for Huawei Cloud Europe or `ap-southeast-1` for International.
```bash
# Flag (one or more regions)
prowler huaweicloud --region eu-west-101 ap-southeast-1
# Environment variable (space- or comma-separated)
export HUAWEICLOUD_REGION="ap-southeast-1, ap-southeast-2"
prowler huaweicloud
```
### Scan an Entire Cloud
To scan every region of an account's cloud without listing regions, use the `--cloud` selector or the `HUAWEICLOUD_CLOUD` environment variable. Prowler expands it to that cloud's regions and selects the matching endpoint automatically:
```bash
# Scan all Huawei Cloud Europe regions (.eu endpoints)
prowler huaweicloud --cloud europe
# Scan all International regions (.com endpoints)
prowler huaweicloud --cloud international
# Scan all China regions (.com endpoints)
prowler huaweicloud --cloud china
```
The `--cloud` flag accepts three values: `international`, `europe`, and `china`. The `HUAWEICLOUD_CLOUD` (or `HW_CLOUD`) environment variable additionally accepts the short aliases `intl`/`com` (International), `eu` (Europe), and `cn` (China).
<Note>
A single set of credentials belongs to one cloud, so `--cloud` selects which cloud to scan — it cannot authenticate against both `.com` and `.eu` at once. To scan accounts on different clouds, run Prowler once per account with that account's credentials.
</Note>
### How Prowler Handles Regions and Endpoints
Prowler manages several Huawei Cloud specifics automatically during a scan:
- **Endpoint selection:** The endpoint domain (`.eu` or `.com`) is derived from each region, so every service targets the right cloud. This corrects services whose bundled metadata still points Europe regions at `.com`.
- **Project resolution:** The per-region project ID is resolved automatically, so multi-region scans work without any project configuration.
- **Credential validation:** Credentials are validated against a region in the account's cloud that exposes IAM, so validation succeeds even when the requested regions do not all offer IAM.
- **Unsupported regions:** Any region a given service does not offer is skipped and logged, so scanning an entire cloud never fails on regions where a service is unavailable.
### Supported Regions
Prowler recognizes the following region IDs, grouped by cloud.
**International (`.com`)**
| Region ID | Location |
|-----------|----------|
| `ae-ad-1` | UAE (Abu Dhabi) |
| `af-north-1` | Egypt (Cairo) |
| `af-south-1` | South Africa |
| `ap-southeast-1` | Hong Kong |
| `ap-southeast-2` | Singapore |
| `ap-southeast-3` | Thailand |
| `ap-southeast-4` | Malaysia |
| `ap-southeast-5` | Indonesia (Jakarta) |
| `eu-west-0` | Ireland |
| `la-north-2` | Mexico |
| `la-south-2` | Chile (Santiago) |
| `me-east-1` | UAE (Dubai) |
| `my-kualalumpur-1` | Malaysia (Kuala Lumpur) |
| `na-mexico-1` | Mexico (Mexico City) |
| `ru-moscow-1` | Russia (Moscow-1) |
| `sa-brazil-1` | Brazil |
| `tr-west-1` | Türkiye (Istanbul) |
**Huawei Cloud Europe (`.eu`)**
| Region ID | Location |
|-----------|----------|
| `eu-west-101` | Ireland (Dublin) |
**China (`.com`)**
| Region ID | Location |
|-----------|----------|
| `cn-north-1` | China (Beijing-1) |
| `cn-north-2` | China (Beijing-2) |
| `cn-north-4` | China (Beijing-4) |
| `cn-north-9` | China (Ulanqab) |
| `cn-north-11` | China (Ulanqab-11) |
| `cn-north-12` | China (Ulanqab-12) |
| `cn-east-2` | China (Shanghai-2) |
| `cn-east-3` | China (Shanghai-1) |
| `cn-east-4` | China (Shanghai-4) |
| `cn-east-5` | China (Shanghai-5) |
| `cn-south-1` | China (Guangzhou) |
| `cn-south-2` | China (Guangzhou-2) |
| `cn-south-4` | China (Guangzhou-4) |
| `cn-southwest-2` | China (Guiyang) |
| `cn-southwest-3` | China (Guiyang-3) |
## Available Services
Prowler for Huawei Cloud currently supports the following services:
| Service | Description |
|---------|-------------|
| `cts` | Cloud Trace Service trackers that record account and API activity for audit logging |
| `ecs` | Elastic Cloud Server compute instances and their key pair, public IP, and security group configuration |
| `elb` | Elastic Load Balance load balancers and their public exposure |
| `evs` | Elastic Volume Service block volumes and their encryption settings |
| `iam` | Identity and Access Management users, MFA devices, password policy, and account operation protection |
| `kms` | Key Management Service keys, their state, and rotation configuration |
| `obs` | Object Storage Service buckets and their public-access configuration |
| `rds` | Relational Database Service instances and their public access, backup, and disk-encryption settings |
| `vpc` | Virtual Private Cloud security groups and their ingress rules |
| `waf` | Web Application Firewall instances and their status |
docs/user-guide/providers/iac/getting-started-iac.mdx
+4 -4
View File
@@ -25,7 +25,7 @@ Prowler IaC provider scans the following Infrastructure as Code configurations f
## How It Works
- Prowler App leverages [Trivy](https://trivy.dev/docs/latest/guide/coverage/iac/#scanner) to scan local directories (or specified paths) for supported IaC files, or scans remote repositories.
- Prowler Cloud leverages [Trivy](https://trivy.dev/docs/latest/guide/coverage/iac/#scanner) to scan local directories (or specified paths) for supported IaC files, or scans remote repositories.
- No cloud credentials or authentication are required for local scans.
- For remote repository scans, authentication can be provided via [git URL](https://git-scm.com/docs/git-clone#_git_urls), CLI flags or environment variables.
- Check the [IaC Authentication](/user-guide/providers/iac/authentication) page for more details.
@@ -38,11 +38,11 @@ Prowler IaC provider scans the following Infrastructure as Code configurations f
### Supported Scanners
Scanner selection is not configurable in Prowler App. Default scanners, misconfig and secret, run automatically during each scan.
Scanner selection is not configurable in Prowler Cloud. Default scanners, misconfig and secret, run automatically during each scan.
### Step 1: Access Prowler Cloud/App
### Step 1: Access Prowler Cloud or Prowler Local Server
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/image/getting-started-image.mdx
+1 -1
View File
@@ -34,7 +34,7 @@ Prowler Cloud does not support scanner selection. The vulnerability, secret, and
### Step 1: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Navigate to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/kubernetes/getting-started-k8s.mdx
+4 -4
View File
@@ -5,9 +5,9 @@ description: 'Onboard Kubernetes clusters to Prowler and scan for security misco
## Prowler Cloud
### Step 1: Access Prowler Cloud/App
### Step 1: Access Prowler Cloud or Prowler Local Server
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app)
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app)
2. Go to "Configuration" > "Providers"
![Providers Page](/images/prowler-app/cloud-providers-page.png)
@@ -22,10 +22,10 @@ description: 'Onboard Kubernetes clusters to Prowler and scan for security misco
### Step 2: Configure Kubernetes Authentication
For Kubernetes, Prowler App uses a `kubeconfig` file to authenticate. Paste the contents of your `kubeconfig` file into the `Kubeconfig content` field.
For Kubernetes, Prowler Cloud uses a `kubeconfig` file to authenticate. Paste the contents of your `kubeconfig` file into the `Kubeconfig content` field.
<Note>
Kubeconfigs that use `users[].user.exec` authentication are not supported in Prowler Cloud/App. For security reasons, Prowler Cloud does not run commands declared by uploaded kubeconfigs. Use kubeconfig credentials that do not rely on `exec` authentication, such as the ServiceAccount token flow documented below.
Kubeconfigs that use `users[].user.exec` authentication are not supported in Prowler Cloud or Prowler Local Server. For security reasons, Prowler Cloud does not run commands declared by uploaded kubeconfigs. Use kubeconfig credentials that do not rely on `exec` authentication, such as the ServiceAccount token flow documented below.
</Note>
By default, the `kubeconfig` file is located at `~/.kube/config`.
docs/user-guide/providers/linode/authentication.mdx
+1 -1
View File
@@ -30,7 +30,7 @@ Ensure the token has all required scopes. Missing permissions will cause some ch
### Step 1: Create a Personal Access Token
1. Log into the [Linode Cloud Manager](https://cloud.linode.com).
2. Click on your username in the top-right corner, then select **API Tokens** under the "My Profile" section.
2. Click your username in the top-right corner, then select **API Tokens** under the "My Profile" section.
3. Click **Create a Personal Access Token**.
4. Configure the token:
- **Label:** A descriptive name (e.g., "Prowler Security Scanner")
docs/user-guide/providers/microsoft365/authentication.mdx
+1 -1
View File
@@ -552,7 +552,7 @@ Installing PowerShell is different depending on your OS:
</Tab>
<Tab title="Docker">
[Docker](https://learn.microsoft.com/es-es/powershell/scripting/install/powershell-in-docker?view=powershell-7.5#use-powershell-in-a-container): The following command download the latest stable versions of PowerShell:
[Docker](https://learn.microsoft.com/es-es/powershell/scripting/install/powershell-in-docker?view=powershell-7.5#use-powershell-in-a-container): The following command downloads the latest stable versions of PowerShell:
```console
docker pull mcr.microsoft.com/dotnet/sdk:9.0
docs/user-guide/providers/microsoft365/getting-started-m365.mdx
+1 -1
View File
@@ -42,7 +42,7 @@ Set up authentication for Microsoft 365 with the [Microsoft 365 Authentication](
### Step 2: Open Prowler Cloud
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Navigate to "Configuration" > "Providers".
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/microsoft365/use-of-powershell.mdx
+1 -1
View File
@@ -14,4 +14,4 @@ To learn more about how to install PowerShell and which versions are supported,
## Required Modules
The necessary modules will not be installed automatically by Prowler. Nevertheless, if you want Prowler to install them for you, you can execute the provider with the flag `--init-modules`, which will run the script to install and import them.
If you want to learn more about this process or you are running some issues with this, click [here](/user-guide/providers/microsoft365/authentication#required-powershell-modules).
If you want to learn more about this process or you are running into some issues with this, click [here](/user-guide/providers/microsoft365/authentication#required-powershell-modules).
docs/user-guide/providers/mongodbatlas/getting-started-mongodbatlas.mdx
+4 -4
View File
@@ -16,12 +16,12 @@ Before you begin, make sure you have:
3. An **API Key pair** (public and private keys) with appropriate permissions:
- **Organization Read Only**: Provides read-only access to everything in the organization, including all projects in the organization. This permission is sufficient for most security checks.
- **Organization Owner**: Required to audit the [Auditing configuration](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-auditing) for projects. Database auditing tracks database operations and security events, including authentication attempts, data definition language (DDL) changes, user and role modifications, and privilege grants. This configuration is essential for security monitoring, forensics, and compliance. Without **Organization Owner** permission, the `projects_auditing_enabled` check cannot retrieve the audit configuration status.
4. Prowler App access (cloud or self-hosted) or the Prowler CLI (`pip install prowler`).
4. Access to Prowler Cloud or Prowler Local Server, or Prowler CLI (`pip install prowler`).
For detailed instructions on creating API keys, see the [MongoDB Atlas authentication guide](./authentication.mdx).
<Warning>
If **Require IP Access List for the Atlas Administration API** is enabled in your organization settings, you **must** add the IP address of the host running Prowler (or the public IP of Prowler Cloud) to the organization IP Access List or Atlas will reject every API call. You can manage this under **Settings → Organization Settings → Security**. See step 7 of the [authentication guide](./authentication.mdx) for detailed instructions, and refer to the [Prowler Cloud public IP list](../../tutorials/prowler-cloud-public-ips) when using Prowler Cloud.
If **Require IP Access List for the Atlas Administration API** is enabled in the organization settings, add the IP address of the host running Prowler (or the public IP of Prowler Cloud) to the organization IP Access List or Atlas will reject every API call. Manage this under **Settings → Organization Settings → Security**. See step 7 of the [authentication guide](./authentication.mdx) for detailed instructions, and refer to the [Prowler Cloud egress IPs](/security/networking) when using Prowler Cloud.
</Warning>
<CardGroup cols={2}>
@@ -54,7 +54,7 @@ If **Require IP Access List for the Atlas Administration API** is enabled in you
### Step 3: Test the connection and start scanning
1. Click **Test connection** to ensure Prowler App can reach the Atlas API.
1. Click **Test connection** to ensure Prowler Cloud can reach the Atlas API.
2. Save the credentials. The provider will appear in the list with its current connection status.
3. Launch a scan from the provider row or from the **Scans** page.
![Launch scan](./img/launch-scan.png)
@@ -109,6 +109,6 @@ prowler mongodbatlas --atlas-project-id <project-id>
- Combine flags (for example, `--checks` or `--services`) just like with other providers.
- Use `--output-modes` to export findings in JSON, CSV, ASFF, etc.
- Rotate API keys regularly and update the stored credentials in Prowler App to maintain connectivity.
- Rotate API keys regularly and update the stored credentials in Prowler Cloud to maintain connectivity.
For more examples (filters, outputs, scheduling), refer back to the [MongoDB Atlas documentation hub](./authentication.mdx) and the main Prowler CLI usage guide.
docs/user-guide/providers/mongodbatlas/img/add-credentials.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 120 KiB

After

Width:  |  Height:  |  Size: 214 KiB

docs/user-guide/providers/mongodbatlas/img/add-org-id.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 99 KiB

After

Width:  |  Height:  |  Size: 189 KiB

docs/user-guide/providers/mongodbatlas/img/add-provider-list.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 203 KiB

After

Width:  |  Height:  |  Size: 211 KiB

docs/user-guide/providers/oci/authentication.mdx
+2 -2
View File
@@ -56,7 +56,7 @@ After running `oci session authenticate`, you need to manually add your user OCI
**Get your user OCID from the OCI Console:**
Navigate to: **Identity & Security** → **Users** → Click on your username → Copy the OCID
Navigate to: **Identity & Security** → **Users** → Click your username → Copy the OCID
![Get User OCID from OCI Console](./images/oci-user-ocid.png)
@@ -435,7 +435,7 @@ prowler oci --oci-config-file /path/to/config
**Cause**: Insufficient IAM permissions
**Solution**: Add required policies (see [Required Permissions](./getting-started-oci.md#required-permissions))
**Solution**: Add required policies (see [Required Permissions](/user-guide/providers/oci/getting-started-oci#required-permissions))
### Configuration Validation
docs/user-guide/providers/oci/getting-started-oci.mdx
+6 -6
View File
@@ -7,7 +7,7 @@ Prowler supports security scanning of Oracle Cloud Infrastructure (OCI) environm
## Prowler Cloud
The following steps apply to Prowler Cloud and the self-hosted Prowler App.
The following steps apply to Prowler Cloud and Prowler Local Server.
### Step 1: Collect OCI Identifiers
1. Sign in to the [OCI Console](https://cloud.oracle.com/) and open **Tenancy Details** to copy the Tenancy OCID.
@@ -16,14 +16,14 @@ The following steps apply to Prowler Cloud and the self-hosted Prowler App.
4. Note the **Region** identifier to scan (for example, `us-ashburn-1`).
### Step 2: Access Prowler Cloud
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Navigate to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Go to **Configuration** → **Providers** and click **Add Provider**.
![Add OCI Provider](./images/oci-add-cloud-provider.png)
3. Select **Oracle Cloud** and enter the **Tenancy OCID** and an optional alias, then choose **Next**.
![Add OCI Cloud Tenancy](./images/oci-add-tenancy.png)
### Step 3: Add OCI API Key Credentials
Prowler App connects to OCI with API key credentials. Provide:
Prowler Cloud connects to OCI with API key credentials. Provide:
- **User OCID** for the API key owner
- **Fingerprint** of the API key
@@ -59,7 +59,7 @@ Before you begin, ensure you have:
### Authentication
Prowler supports multiple authentication methods for OCI. For detailed authentication setup, see the [OCI Authentication Guide](./authentication).
Prowler supports multiple authentication methods for OCI. For detailed authentication setup, see the [OCI Authentication Guide](/user-guide/providers/oci/authentication).
**Note:** OCI Session Authentication and Config File Authentication both use the same `~/.oci/config` file. The difference is how the config file is generated - automatically via browser (session auth) or manually with API keys.
@@ -79,7 +79,7 @@ The easiest and most secure method is using OCI session authentication, which au
**Get your user OCID from the OCI Console:**
Navigate to: **Identity & Security** → **Users** → Click on your username → Copy the OCID
Navigate to: **Identity & Security** → **Users** → Click your username → Copy the OCID
![Get User OCID from OCI Console](./images/oci-user-ocid.png)
@@ -108,7 +108,7 @@ The easiest and most secure method is using OCI session authentication, which au
#### Alternative: Manual API Key Setup
If you prefer to manually generate API keys instead of using browser-based session authentication, see the detailed instructions in the [Authentication Guide](./authentication#config-file-authentication-manual-api-key-setup).
If you prefer to manually generate API keys instead of using browser-based session authentication, see the detailed instructions in the [Authentication Guide](/user-guide/providers/oci/authentication#config-file-authentication-manual-api-key-setup).
**Note:** Both methods use the same `~/.oci/config` file - the difference is that manual setup uses static API keys while session authentication uses temporary session tokens.
docs/user-guide/providers/oci/images/oci-add-api-key-credentials.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 472 KiB

After

Width:  |  Height:  |  Size: 228 KiB

docs/user-guide/providers/oci/images/oci-add-cloud-provider.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 367 KiB

After

Width:  |  Height:  |  Size: 210 KiB

docs/user-guide/providers/oci/images/oci-add-tenancy.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 288 KiB

After

Width:  |  Height:  |  Size: 194 KiB

docs/user-guide/providers/okta/authentication.mdx
+1 -1
View File
@@ -21,7 +21,7 @@ Prowler authenticates to Okta as a **service application** using **OAuth 2.0 wit
| Method | Status | Use Case |
|---|---|---|
| **OAuth 2.0 (private-key JWT)** | Supported | Production scans, CI/CD, Prowler App. |
| **OAuth 2.0 (private-key JWT)** | Supported | Production scans, CI/CD, Prowler Cloud. |
The private-key JWT flow is the only supported authentication method in the initial release. The service application proves possession of a private key on every token request; Okta returns a short-lived access token, refreshed automatically by the SDK.
docs/user-guide/providers/okta/getting-started-okta.mdx
+1 -1
View File
@@ -31,7 +31,7 @@ Set up authentication for Okta with the [Okta Authentication](/user-guide/provid
### Step 1: Add the Provider
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Navigate to "Configuration" > "Providers".
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/providers/okta/images/okta-credentials-form.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 306 KiB

After

Width:  |  Height:  |  Size: 227 KiB

docs/user-guide/providers/okta/images/okta-org-domain-form.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 220 KiB

After

Width:  |  Height:  |  Size: 189 KiB

docs/user-guide/providers/okta/images/select-okta-provider.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 529 KiB

After

Width:  |  Height:  |  Size: 210 KiB

docs/user-guide/providers/openstack/images/add-credentials.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 135 KiB

After

Width:  |  Height:  |  Size: 222 KiB

docs/user-guide/providers/openstack/images/add-provider-id.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 99 KiB

After

Width:  |  Height:  |  Size: 199 KiB

docs/user-guide/providers/openstack/images/select-provider.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 241 KiB

After

Width:  |  Height:  |  Size: 218 KiB

docs/user-guide/providers/scaleway/getting-started-scaleway.mdx
+2 -2
View File
@@ -15,7 +15,7 @@ Prowler for Scaleway scans IAM resources in your Scaleway organization for secur
Prowler authenticates to Scaleway with a Scaleway API key. See [Scaleway Authentication in Prowler](./authentication) for the full setup, environment variables, CLI flags, and required permissions.
## Run a scan
## Run a Scan
```bash
export SCW_ACCESS_KEY="SCW..."
@@ -31,7 +31,7 @@ To run only the IAM root-key check:
prowler scaleway --check iam_api_keys_no_root_owned
```
## Checks shipped
## Checks Shipped
| Check ID | Severity | Description |
|---|---|---|
docs/user-guide/providers/vercel/getting-started-vercel.mdx
+1 -1
View File
@@ -29,7 +29,7 @@ Set up authentication for Vercel with the [Vercel Authentication](/user-guide/pr
### Step 1: Add the Provider
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler App](/user-guide/tutorials/prowler-app).
1. Go to [Prowler Cloud](https://cloud.prowler.com/) or launch [Prowler Local Server](/user-guide/tutorials/prowler-app).
2. Navigate to "Configuration" > "Providers".
![Providers Page](/images/prowler-app/cloud-providers-page.png)
docs/user-guide/tutorials/aws-organizations-bulk-provisioning.mdx
+11 -9
View File
@@ -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>
docs/user-guide/tutorials/bulk-provider-provisioning.mdx
+7 -7
View File
@@ -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 \
docs/user-guide/tutorials/prowler-app-api-keys.mdx
+10 -7
View File
@@ -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.
![API Keys list](/images/cli/api-keys/list.png)
@@ -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
docs/user-guide/tutorials/prowler-app-attack-paths-active-queries.mdx
+41
View File
@@ -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.
![Attack Paths query returning no data](/images/prowler-app/attack-paths/query-no-data.png)
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.
![Attack Paths query selector with confirmed-empty queries hidden](/images/prowler-app/attack-paths/query-selector-hidden-empty.png)
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.
docs/user-guide/tutorials/prowler-app-attack-paths.mdx
+18 -105
View File
@@ -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
docs/user-guide/tutorials/prowler-app-finding-groups.mdx
+4 -1
View File
@@ -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.
docs/user-guide/tutorials/prowler-app-findings-triage.mdx
+1 -1
View File
@@ -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
docs/user-guide/tutorials/prowler-app-jira-integration.mdx
+88 -23
View File
@@ -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**
![Integrations tab](/images/prowler-app/jira/integrations-tab.png)
@@ -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**.
![A complete Finding Group selected with the Send Finding Group to Jira action highlighted](/images/prowler-app/jira/select-group.png)
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**.
![Jira export dialog showing grouped and separate issue creation modes for a Finding Group](/images/prowler-app/jira/send-group-to-jira.png)
### 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**.
![Multiple Findings selected within an expanded Finding Group before sending them to Jira](/images/prowler-app/jira/select-multiple-findings.png)
### 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.
![Finding Group summary information in a grouped Jira issue](/images/prowler-app/jira/group-info.png)
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.
![Affected-resources table listing the Findings included in a grouped Jira issue](/images/prowler-app/jira/group-resources.png)
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.
![Complete Finding Group opened in Prowler Cloud from the Jira issue link](/images/prowler-app/jira/prowler-finding-group.png)
### 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.
docs/user-guide/tutorials/prowler-app-lighthouse-multi-llm.mdx
+19
View File
@@ -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>
docs/user-guide/tutorials/prowler-app-lighthouse.mdx
+1 -1
View File
@@ -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.
docs/user-guide/tutorials/prowler-app-multi-tenant.mdx
+5 -2
View File
@@ -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.
docs/user-guide/tutorials/prowler-app-mute-findings.mdx
+10 -7
View File
@@ -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
![Add provider](/images/mutelist-ui-1.png)
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
docs/user-guide/tutorials/prowler-app-rbac.mdx
+47 -35
View File
@@ -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
docs/user-guide/tutorials/prowler-app-s3-integration.mdx
+10 -7
View File
@@ -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"
![Navigate to integrations](/images/prowler-app/s3/s3-integration-ui-1.png)
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
![Access S3 integration](/images/prowler-app/s3/s3-integration-ui-2.png)
3. Click the "Add Integration" button
![Add integration button](/images/prowler-app/s3/s3-integration-ui-3.png)
docs/user-guide/tutorials/prowler-app-scan-configuration.mdx
+19 -1
View File
@@ -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>
docs/user-guide/tutorials/prowler-app-security-hub-integration.mdx
+8 -5
View File
@@ -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**
![Integrations tab](/images/prowler-app/security-hub/integrations-tab.png)
docs/user-guide/tutorials/prowler-app-simple-mutelist.mdx
+4 -1
View File
@@ -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?
docs/user-guide/tutorials/prowler-app-social-login.mdx
+4 -1
View File
@@ -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
docs/user-guide/tutorials/prowler-app-sso-entra.mdx
+7 -3
View File
@@ -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
![Edit](/images/prowler-app/saml/saml-sso-azure-5.png)
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.
![Enter data](/images/prowler-app/saml/saml-sso-azure-6.png)
@@ -45,4 +49,4 @@ You can find a walkthrough video [here](https://www.youtube.com/watch?v=zegqm55o
![Metadata XML](/images/prowler-app/saml/saml-sso-azure-9.png)
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).
docs/user-guide/tutorials/prowler-app-sso-google-workspace.mdx
+38 -28
View File
@@ -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".
![Google Identity Provider details - Download metadata](/images/prowler-app/saml/saml-sso-gw-3.png)
@@ -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`).
![Prowler App - Configure SAML SSO dialog (initial state)](/images/prowler-app/saml/saml-sso-gw-prowler-1.png)
![Prowler Cloud - Configure SAML SSO dialog (initial state)](/images/prowler-app/saml/saml-sso-gw-prowler-1.png)
### 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".
![Prowler App - Configure SAML SSO dialog (domain entered and ready to save)](/images/prowler-app/saml/saml-sso-gw-prowler-2.png)
![Prowler Cloud - Configure SAML SSO dialog (domain entered and ready to save)](/images/prowler-app/saml/saml-sso-gw-prowler-2.png)
### 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.
![Prowler App - SAML SSO Integration status showing "Enabled"](/images/prowler-app/saml/saml-sso-gw-prowler-3.png)
![Prowler Cloud - SAML SSO Integration status showing "Enabled"](/images/prowler-app/saml/saml-sso-gw-prowler-3.png)
---
@@ -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.
![Prowler App - Sign in with SAML SSO](/images/prowler-app/saml/saml-sso-gw-prowler-4.png)
![Prowler Cloud - Sign in with SAML SSO](/images/prowler-app/saml/saml-sso-gw-prowler-4.png)
### 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.
![Prowler App - User profile showing role "Backend" created from userType mapping](/images/prowler-app/saml/saml-sso-gw-prowler-5.png)
![Prowler Cloud - User profile showing role "Backend" created from userType mapping](/images/prowler-app/saml/saml-sso-gw-prowler-5.png)
### 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.
docs/user-guide/tutorials/prowler-app-sso.mdx
+71 -36
View File
@@ -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).
![Access Profile Settings](/images/prowler-app/saml/saml-step-1.png)
@@ -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.
![IdP configuration](/images/prowler-app/saml/idp_config.png)
@@ -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:
![Okta App Assignments](/images/prowler-app/saml/okta-app-assignments.png)
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.
![Okta User Profile — First Name and Last Name](/images/prowler-app/saml/okta-user-profile-name.png)
* **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.
![Okta User Profile — User Type and Organization](/images/prowler-app/saml/okta-user-profile-attributes.png)
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.
![Verify Integration Status](/images/prowler-app/saml/saml-step-4.png)
![Verify Integration Status](/images/prowler-app/saml/saml-sso-enabled.png)
<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.
![Prowler Cloud SAML configuration with multiple additional email domains](/images/prowler-app/saml/saml-multiple-domains.png)
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.
![Remove SAML configuration](/images/prowler-app/saml/saml-step-remove.png)
![Remove SAML configuration](/images/prowler-app/saml/saml-sso-remove.png)
### 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"
![](/images/prowler-app/saml/saml-signin-1.png)
![Prowler Cloud login page with the "Continue with SAML SSO" button](/images/prowler-app/saml/saml-signin-1.png)
3. Enter their email address from the configured domain
![](/images/prowler-app/saml/saml-signin-2.png)
![SAML SSO login form asking for the email address](/images/prowler-app/saml/saml-signin-2.png)
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 |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
docs/user-guide/tutorials/prowler-app.mdx
+10 -18
View File
@@ -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.
docs/user-guide/tutorials/prowler-cloud-aws-organizations.mdx
+293 -329
View File
@@ -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&param_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&param_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
docs/user-guide/tutorials/prowler-cloud-azure-management-groups.mdx
+11
View File
@@ -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.
docs/user-guide/tutorials/prowler-cloud-gcp-organizations.mdx
+442
View File
@@ -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>
docs/user-guide/tutorials/prowler-cloud-public-ips.mdx
-30
View File
@@ -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>
Loaded 100 of 2428 files, more files were not shown because too many files have changed in this diff. Show more