Operation DescribeAccount doesn't work

[vjancich]

Issue search

• I have searched the existing issues and this bug has not been reported yet

Which component is affected?

Prowler API

Cloud Provider (if applicable)

AWS

Steps to Reproduce

Hello,

we are running Prowler as a AWS ECS Fargate service. Everything works fine but I noticed following error in logs during scan:
2026-03-02 11:01:04.247ERROR[2026-03-02 10:01:04,054: WARNING/ForkPoolWorker-69] AccessDeniedException[15]: An error occurred (AccessDeniedException) when calling the DescribeAccount operation: You don't have permissions to access this resource.

We migrated Prowler into account which is delegated administrator account so this command should work.

Expected behavior

Command DescribeAccount works.

Actual Result with Screenshots or Logs

If I manually assume prowler role and execute the command, it works.

~ $ aws sts get-caller-identity                                                                                                                                                                                                                           
{
    "UserId": "AROA6LTKSWWMCC5BS74IG:prowler-session",
    "Account": "986992260504",
    "Arn": "arn:aws:sts::986992260504:assumed-role/cor-prowler-scan/prowler-session"
}

$ aws organizations describe-account --account-id 986992260504
{
    "Account": {
        "Id": "986992260504",
        "Arn": "arn:aws:organizations::183992486874:account/<org_id>/986992260504",
        "Email": "<email_address>,
        "Name": "<account_name>",
        "Status": "ACTIVE",
        "State": "ACTIVE",
        "JoinedMethod": "INVITED",
        "JoinedTimestamp": "2021-04-14T17:45:33.932000+00:00"
    }
}

However, prowler logs this:

2026-03-02 11:01:04.247ERROR[2026-03-02 10:01:04,054: WARNING/ForkPoolWorker-69] AccessDeniedException[15]: An error occurred (AccessDeniedException) when calling the DescribeAccount operation: You don't have permissions to access this resource.

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,653: INFO/ForkPoolWorker-69] Getting AWS Organizations metadata for account 986992260504

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,653: INFO/ForkPoolWorker-69] Setting new identity for the AWS IAM Role assumed

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,653: INFO/ForkPoolWorker-69] Audit session is the new session created assuming an IAM Role

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,644: INFO/ForkPoolWorker-69] IAM Role assumed: arn:aws:iam::986992260504:role/cor-prowler-scan

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,568: INFO/ForkPoolWorker-69] Assuming role: arn:aws:iam::986992260504:role/cor-prowler-scan

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,568: INFO/ForkPoolWorker-69] Original AWS Caller Identity ARN: arn='arn:aws:sts::986992260504:assumed-role/cor-prowler-api-dev-task-role/8c06fd372e2440609fa8fe281fa9af2b' partition='aws' service='sts' region=None account_id='986992260504' resource='cor-prowler-api-dev-task-role/8c06fd372e2440609fa8fe281fa9af2b' resource_type='assumed-role'

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,568: INFO/ForkPoolWorker-69] Original AWS Caller Identity UserId: AROA6LTKSWWMA55GNMDBU:8c06fd372e2440609fa8fe281fa9af2b

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,567: INFO/ForkPoolWorker-69] Credentials validated

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,403: INFO/ForkPoolWorker-69] Validating credentials ...

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,392: INFO/ForkPoolWorker-69] Generating original session ...

2026-03-02 11:01:04.247INFO[2026-03-02 10:01:03,391: INFO/ForkPoolWorker-69] Initializing AWS provider ...

Prowler succesfully assumed the same role as I did during my testing. I'm capable of executing DescribeAccount command, Prowler isn't.

How did you install Prowler?

Cloning the repository from github.com (git clone)

Environment Resource

AWS ECS Fargate service

OS used

not applicable (AWS managed)

Prowler version

v5.18.3

Python version

provided by prowler

Pip version

provided by prowler

Context

No response

[github-actions]

✅ Issue Triage completed successfully!

[github-actions]

AI Assessment [Experimental]: Bug

Component: API (Django backend)
Provider: AWS
Severity: medium
Complexity: low
Agent Ready: Ready

Summary

The Prowler API component does not support the organizations_role_arn parameter when initializing AWS providers, preventing Organizations metadata retrieval in delegated administrator scenarios. The underlying SDK supports this parameter (accessible via CLI with --organizations-role), but the API's provider secret schema and initialization logic lack this field.

Extracted Issue Fields

• Reporter version: v5.18.3
• Install method: Cloning the repository from github.com (git clone)
• Environment: AWS ECS Fargate service

Duplicates & Related Issues

None found

---

Root Cause Analysis

Symptom

When running Prowler API as an ECS Fargate service with a scan role in a delegated administrator account, the organizations:DescribeAccount API call fails with AccessDeniedException, even though the same role works when manually assumed via AWS CLI.

Location

• File: api/src/backend/api/utils.py
• Function: get_prowler_provider_kwargs()
• Lines: 173-255
• Related files:
  • api/src/backend/api/v1/serializer_utils/providers.py (secret schema definition, lines 5-78)
  • prowler/providers/aws/aws_provider.py (SDK provider that supports the parameter, line 114)

Cause

The Prowler SDK's AwsProvider class accepts an organizations_role_arn parameter (line 114 in aws_provider.py) to assume a separate role for fetching Organizations metadata. This is necessary in delegated administrator scenarios where the scan role may not have organizations:DescribeAccount permissions.

However, the Prowler API component has two gaps:

1. Schema Gap: The provider secret schema in api/src/backend/api/v1/serializer_utils/providers.py (lines 30-78) defines AWS secret fields (role_arn, external_id, session_duration, etc.) but does NOT include organizations_role_arn.

2. Initialization Gap: The get_prowler_provider_kwargs() function in api/src/backend/api/utils.py (lines 173-255) constructs kwargs for provider initialization. For AWS providers, it passes the secret fields directly (line 185: prowler_provider_kwargs = provider.secret.secret), without checking for or extracting an organizations_role_arn field.

When the API initializes an AWS provider, it only passes the scan role credentials. The Organizations metadata fetch (in aws_provider.py line 330) then uses the audit session credentials (the assumed scan role), which may not have Organizations permissions in a delegated admin setup.

In the CLI, users can pass --organizations-role to specify a separate role with Organizations permissions. The API has no equivalent mechanism.

Coding Agent Plan

Required Skills

Load these skills from AGENTS.md before starting:

• prowler-api — API models, serializers, views, and RLS patterns
• django-drf — DRF serializer patterns and validation
• prowler-test-api — API testing patterns with pytest-django
• pytest — Generic pytest patterns
• tdd — Test-Driven Development workflow

Test Specification

Write tests FIRST (TDD). The skills contain all testing conventions and patterns.

Test Scenario	Expected Result	Must FAIL today?
Create AWS provider with organizations_role_arn in secret	Provider initialization passes organizations_role_arn to AwsProvider constructor	Yes
Initialize AWS provider with organizations_role_arn in secret	get_prowler_provider_kwargs includes organizations_role_arn in returned kwargs	Yes
AWS provider secret schema includes organizations_role_arn field	OpenAPI schema documents organizations_role_arn as optional string field	Yes
Test connection for AWS provider with organizations_role_arn	Connection test passes when Organizations role is valid	No (existing test coverage may pass)

Test location: api/src/backend/api/tests/ (follow existing test structure for provider initialization)
Mock pattern: Use existing provider test fixtures and extend with organizations_role_arn scenarios

Fix Specification

1. Update secret schema (api/src/backend/api/v1/serializer_utils/providers.py):

   • Add organizations_role_arn as an optional field in the "AWS Assume Role" schema (around line 30-78)
   • Include description: "The ARN of the AWS Organizations role to assume for fetching account metadata. Required when the scan role lacks organizations:DescribeAccount permissions (e.g., delegated administrator scenarios)."
   • Pattern: Should validate as AWS IAM role ARN format
   • No changes needed to "AWS Static Credentials" schema (organizations role is only relevant for role assumption scenarios)

2. Update kwargs extraction (api/src/backend/api/utils.py):

   • In get_prowler_provider_kwargs(), after line 185 where prowler_provider_kwargs = provider.secret.secret
   • Add conditional logic: if provider is AWS and secret contains organizations_role_arn, ensure it's included in the kwargs
   • The current implementation passes provider.secret.secret directly, which should already include all fields, but verify this doesn't get stripped by subsequent provider-specific logic

3. Verify passthrough (no code change expected):

   • Confirm that initialize_prowler_provider() (line 286) passes all kwargs from get_prowler_provider_kwargs() to the provider constructor
   • The current implementation does prowler_provider(**prowler_provider_kwargs), which should work correctly

Acceptance Criteria

• Provider secret schema documents organizations_role_arn as optional field for AWS Role Assumption
• OpenAPI schema includes the new field with proper validation and description
• get_prowler_provider_kwargs() includes organizations_role_arn in returned kwargs when present in secret
• Existing provider initialization tests pass
• New test passes: AWS provider with organizations_role_arn in secret correctly initializes with that parameter
• All existing tests pass (pytest -x)

Files to Modify

File	Change Description
api/src/backend/api/v1/serializer_utils/providers.py	Add organizations_role_arn field to AWS Assume Role secret schema with description, validation pattern, and marked as optional
api/src/backend/api/tests/test_*.py (existing provider tests)	Add test scenario for AWS provider initialization with organizations_role_arn in secret

Edge Cases

• Empty string: If organizations_role_arn is empty string, should not be passed to provider constructor (filter out falsy values)
• Invalid ARN format: Schema validation should catch invalid ARN formats before initialization
• Static credentials scenario: organizations_role_arn only makes sense with role assumption, not static credentials (document in schema description)
• Backwards compatibility: Existing providers without organizations_role_arn should continue to work (field is optional)

---

Note for the Reporter: After this fix is implemented, you'll be able to add an organizations_role_arn field to your AWS provider's secret in the Prowler API. This should be the ARN of a role in your Organizations management account (or a delegated admin account) with organizations:DescribeAccount and organizations:ListTagsForResource permissions. This mirrors the CLI's --organizations-role flag.

Workaround Until Fixed: Add the organizations:DescribeAccount and organizations:ListTagsForResource permissions to your scan role (cor-prowler-scan). This allows the role to fetch its own Organizations metadata without needing a separate Organizations role. However, this is not ideal in delegated admin scenarios where you want separation of concerns between scanning and Organizations management permissions.

AI generated by Issue Triage

[jfagoagas]

Hi @vjancich thanks for heads up! We're going to review this internally and we'll get back to you.

Thanks for using Prowler 🚀