docs: add AWS Workload Identity Federation integration guide

cloud/integrations.mdx

@@ -18,7 +18,7 @@
   <Card title="Webhook" icon="webhook" href="#webhook">
 
   </Card>
   <Card title="Jira" icon="jira" href="#jira">
 
   </Card>
   <Card title="GitHub" icon="github" href="#github">
@@ -48,7 +48,7 @@
   <Card title="Cloudflare" icon="cloudflare" href="#cloudflare">
 
   </Card>
   <Card title="Fastly" icon="bolt" href="#fastly">
 
   </Card>
   <Card title="DigitalOcean" icon="digital-ocean" href="#digitalocean">
@@ -188,7 +188,7 @@
   },
 
   "finished": null,
   "failed_stopped": null
 }
 ```
 
@@ -276,8 +276,8 @@
     - `medium` — Medium severity count
     - `low` — Low severity count
     - `info` — Info severity count
   - `rescan_new_vulnerabilities` — New vulns since last scan, rescans only (integer)
   - `rescan_vulns_list` — List of new vulnerabilities, **max 15 items**, rescans only (array)
     - `Name` — Vulnerability name/title
     - `Severity` — Severity level (critical, high, medium, low, info)
     - `Count` — Number of instances found
@@ -385,7 +385,7 @@
     <Accordion title="Enumeration Finished" icon="circle-check">
 
 <Info>
 **Trigger:** When asset disocvery completes successfully
 
 **Type:** `finished`
 </Info>
@@ -442,7 +442,7 @@
   - `total_assets` — Total number of assets in inventory (integer)
   - `new_assets` — Number of newly discovered assets (integer)
   - `new_assets_list` — Details of newly discovered assets (array)
     - `host` — Hostname or domain name
     - `port` — Port number
     - `ip` — List of IP addresses associated with the host (array of strings)
   </Accordion>
@@ -506,7 +506,7 @@
 
 **Type:** `new_vuln`
 
 **Note:** This event is only triggered for rescans when comparing against previous results
 </Info>
 
 ```json New Vulnerability Alert Payload
@@ -575,7 +575,7 @@
 </Tip>
 
 <Note>
 If you configured severity filters (e.g., only Critical and High), only new vulnerabilities matching those severities will trigger this event and be included in the `rescan_vulns_list`.
 </Note>
     </Accordion>
 
@@ -586,7 +586,7 @@
 
 **Type:** `new_asset`
 
 **Configuration:** Can be enabled for disocvery, scan, or both based on your alerting configuration
 </Info>
 
 ```json New Asset Alert Payload
@@ -651,7 +651,7 @@
   - `total_assets` — Total number of assets in your inventory (integer)
   - `new_assets` — **Number of NEWLY discovered assets** (integer)
   - `new_assets_list` — **List of NEWLY discovered assets only** (array)
     - `host` — Hostname or domain name
     - `port` — Port number
     - `ip` — List of IP addresses associated with the host (array of strings)
   </Accordion>
@@ -667,7 +667,7 @@
 
 ## Ticketing Integrations
 
 The integrations under Ticketing support ticketing functionality as part of scanning and include support for Jira, GitHub, GitLab, and Linear. Navigate to [Scans → Configurations → Ticketing](https://cloud.projectdiscovery.io/scans/configs?type=reporting) to configure your ticketing tools.
 
 <img
   height="300"
@@ -676,9 +676,9 @@
 
 ### Jira
 
 ProjectDiscovery provides integration support for Jira to create new tickets when vulnerabilities are found.
 
 Provide a name for the configuration, the Jira instance URL , the Account ID, the Email, and the associated API token.
 
 Details on creating an API token are available [in the Jira documentation here.](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/)
 
@@ -689,7 +689,7 @@
 Provide a name for the configuration, the Organization or username, Project name, Issue Assignee, Token, and Issue Label. The Issue Label determines when a ticket is created. (For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
 
 - The severity as label option adds a template result severity to any GitHub issues created.
 - Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
 
 Details on setting up access in GitHub [are available here.](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)
 
@@ -701,7 +701,7 @@
 (For example, if critical severity is selected, any issues with a critical severity will create a ticket.)
 
 - The severity as label option adds a template result severity to any GitLab issues created.
 - Deduplicate posts any new results as comments on existing issues instead of creating new issues for the same result.
 
 Refer to GitLab's documentation for details on [configuring a Project Access token.](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token)
 
@@ -756,7 +756,7 @@
   Click here to open the AWS integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
 ProjectDiscovery's AWS integration allows the platform to automatically discover and monitor cloud assets across your AWS accounts. By connecting AWS to ProjectDiscovery, security teams and DevOps engineers gain continuous visibility into EC2 instances, S3 buckets, DNS records, and other resources without manual inventory. This integration leverages ProjectDiscovery's open-source **Cloudlist** engine to enumerate assets via AWS APIs. In short, it helps ensure no cloud asset goes unnoticed, enabling proactive security monitoring and easier management of your attack surface.
 
 <img
   src="/images/aws-integration.png"
@@ -768,7 +768,7 @@
 
 | Service                                               | Description                                   |
 | :---------------------------------------------------- | :-------------------------------------------- |
 | [EC2](https://aws.amazon.com/ec2/)                    | VM instances and their public IPs             |
 | [Route53](https://aws.amazon.com/route53/)            | DNS hosted zones and records                  |
 | [S3](https://aws.amazon.com/s3/)                      | Buckets (especially those public or with DNS) |
 | [Cloudfront](https://aws.amazon.com/cloudfront/)      | CDN distributions and their domains           |
@@ -776,19 +776,20 @@
 | [EKS](https://aws.amazon.com/eks/)                    | Kubernetes cluster endpoints                  |
 | [ELB](https://aws.amazon.com/elasticloadbalancing/)   | Load balancers (Classic ELB and ALB/NLB)      |
 | [ELBv2](https://aws.amazon.com/elasticloadbalancing/) | Load balancers (Classic ELB and ALB/NLB)      |
 | [Lambda](https://aws.amazon.com/lambda/)              | Serverless function endpoints                 |
 | [Lightsail](https://aws.amazon.com/lightsail/)        | Lightsail instances (simplified VPS)          |
 | [Apigateway](https://aws.amazon.com/api-gateway/)     | API endpoints deployed via Amazon API Gateway |
 
 By covering these services, ProjectDiscovery can map out a broad range of AWS assets in your account. (Support for additional services may be added over time.)
 
 **AWS Integration Methods**
 
-ProjectDiscovery supports three methods to connect to AWS, each suited for different use cases and security preferences:
+ProjectDiscovery supports four methods to connect to AWS, each suited for different use cases and security preferences:
 
 1. **Single AWS Account (Access Key & Secret)** – Direct credential-based authentication using an IAM User's Access Key ID and Secret Access Key to connect one AWS account. Choose this for quick setups or single-account monitoring.
 2. **Multiple AWS Accounts (Assume Role)** – Use one set of credentials to assume roles in multiple accounts. This method is ideal for organizations with multiple AWS accounts (e.g. dev, prod, etc.). You provide one account's credentials and the common role name that exists in all target accounts.
-3. **Cross-Account Role (Role ARN)** – Use a dedicated IAM role with an External ID for third-party access. This option lets you create a cross-account IAM role in your AWS account and grant ProjectDiscovery access via that role's Amazon Resource Name (ARN). This is the most secure integration method, as it follows AWS best practices for third-party account access.
+3. **Cross-Account Role (Role ARN)** – Use a dedicated IAM role with an External ID for third-party access. This option lets you create a cross-account IAM role in your AWS account and grant ProjectDiscovery access via that role's Amazon Resource Name (ARN).
+4. **Workload Identity Federation (Recommended)** – Connect without storing any AWS credentials. ProjectDiscovery's OIDC identity provider exchanges short-lived tokens with AWS for each scan. This is the most secure method — no long-lived keys to manage, rotate, or risk leaking.
 
 **Prerequisites**
 
@@ -847,32 +848,125 @@
    - Give the integration a unique name
    - Select the AWS services you want to monitor
 
-**Required Permissions**
+#### 4. Workload Identity Federation (Recommended)
 
-ProjectDiscovery needs read-only access to your AWS assets. The following AWS-managed policies are recommended:
+<Note>
+**Recommended.** Workload Identity Federation (WIF) eliminates long-lived AWS credentials entirely. ProjectDiscovery's OIDC identity provider exchanges short-lived tokens with AWS STS for each scan — no access keys are stored or need rotation.
+</Note>
 
-- EC2 - AmazonEC2ReadOnlyAccess
-- Route53 - AmazonRoute53ReadOnlyAccess
-- S3 - AmazonS3ReadOnlyAccess
-- Lambda - AWSLambda_ReadOnlyAccess
-- ELB - ElasticLoadBalancingReadOnly
-- Cloudfront - CloudFrontReadOnlyAccess
+**Benefits over credential-based methods:**
+- No long-lived access keys to manage or rotate
+- Tokens are short-lived and scoped per-scan
+- Audit trail in AWS CloudTrail shows federated identity access
+- Trust is scoped to your specific ProjectDiscovery workspace ID
+- Follows AWS security best practices for third-party integrations
 
-Alternatively, you can use this custom policy for minimal permissions:
+**Prerequisites:**
+- An AWS account with IAM admin access
+- AWS CLI configured (`aws configure`)
+- Your ProjectDiscovery **Team ID** (found in the platform sidebar)
 
-```json
+<Tip>
+**Finding your Team ID** — In the ProjectDiscovery platform, click on your team name in the left sidebar to reveal your Team ID. Use the copy button to copy it.
+
+<img
+  src="/images/pdcp-teamid.png"
+  alt="Finding your Team ID in ProjectDiscovery"
+  title="Finding your Team ID in ProjectDiscovery"
+  style={{ width:"45%" }}
+/>
+</Tip>
+
+**Step 1: Create the OIDC Identity Provider**
+
+Register ProjectDiscovery as a trusted OIDC provider in your AWS account.
+
+```bash
+aws iam create-open-id-connect-provider \
+  --url "https://oidc.projectdiscovery.io" \
+  --client-id-list "sts.amazonaws.com"
+```
+
+Save the OIDC Provider ARN from the output (e.g., `arn:aws:iam::123456789012:oidc-provider/oidc.projectdiscovery.io`).
+
+**Step 2: Create the WIF Role**
+
+Create an IAM role that ProjectDiscovery can assume via OIDC token exchange. The trust policy restricts access to your specific workspace.
+
+```bash
+ACCOUNT_ID="YOUR_AWS_ACCOUNT_ID"
+TEAM_ID="YOUR_PROJECTDISCOVERY_TEAM_ID"
+OIDC_PROVIDER="oidc.projectdiscovery.io"
+
+cat > trust-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Principal": {
+        "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}"
+      },
+      "Action": "sts:AssumeRoleWithWebIdentity",
+      "Condition": {
+        "StringEquals": {
+          "${OIDC_PROVIDER}:aud": "sts.amazonaws.com",
+          "${OIDC_PROVIDER}:sub": "${TEAM_ID}"
+        }
+      }
+    }
+  ]
+}
+EOF
+
+aws iam create-role \
+  --role-name PDWorkloadIdentityRole \
+  --assume-role-policy-document file://trust-policy.json
+```
+
+**Step 3: Create a Scanner Role**
+
+The WIF role is the trust boundary — it should **not** have direct resource permissions. Create a separate scanner role with read-only permissions in each account you want to scan, starting with the account where the WIF role lives.
+
+```bash
+ACCOUNT_ID="YOUR_AWS_ACCOUNT_ID"
+
+cat > scanner-trust-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Principal": {
+        "AWS": "arn:aws:iam::${ACCOUNT_ID}:role/PDWorkloadIdentityRole"
+      },
+      "Action": "sts:AssumeRole"
+    }
+  ]
+}
+EOF
+
+aws iam create-role \
+  --role-name PDScannerRole \
+  --assume-role-policy-document file://scanner-trust-policy.json
+```
+
+Attach scanner permissions to the scanner role:
+
+```bash
+cat > scanner-policy.json <<EOF
 {
   "Version": "2012-10-17",
   "Statement": [
     {
-      "Sid": "RequiredReadPermissions",
       "Effect": "Allow",
       "Action": [
         "ec2:DescribeInstances",
         "ec2:DescribeRegions",
         "route53:ListHostedZones",
         "route53:ListResourceRecordSets",
         "s3:ListAllMyBuckets",
+        "s3:GetBucketLocation",
         "lambda:ListFunctions",
         "elasticloadbalancing:DescribeLoadBalancers",
         "elasticloadbalancing:DescribeTargetGroups",
@@ -893,31 +987,177 @@
     }
   ]
 }
+EOF
+
+aws iam put-role-policy \
+  --role-name PDScannerRole \
+  --policy-name ScannerPermissions \
+  --policy-document file://scanner-policy.json
+```
+
+<Note>
+For **multiple accounts**, repeat [Step 3](#step-3-create-a-scanner-role) in each account you want to scan — the role name must be the same (`PDScannerRole`) across all accounts. Use [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html), Terraform, or similar infrastructure-as-code tools to deploy the scanner role across all accounts at once.
+</Note>
+
+**Step 4: Grant the WIF Role AssumeRole Permission**
+
+Allow the WIF role to assume scanner roles. Use a wildcard to cover all accounts, or list specific account ARNs.
+
+```bash
+cat > assume-scanner-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": "sts:AssumeRole",
+      "Resource": "arn:aws:iam::*:role/PDScannerRole"
+    }
+  ]
+}
+EOF
+
+aws iam put-role-policy \
+  --role-name PDWorkloadIdentityRole \
+  --policy-name AssumeScannerRole \
+  --policy-document file://assume-scanner-policy.json
+```
+
+**Step 5: Configure in ProjectDiscovery**
+
+| Field | Value |
+|---|---|
+| **OIDC Provider ARN** | ARN from Step 1 |
+| **WIF Role Name** | `PDWorkloadIdentityRole` |
+| **Scanner Role Name** | `PDScannerRole` |
+| **Account IDs** | AWS account IDs to scan, one per line |
+
+Click **Verify** to test the connection.
+
+<Note>
+For a single account, enter just that account's ID. For multiple accounts, list all account IDs — the scanner role must exist in each one.
+</Note>
+
+---
+
+**Optional: Organization Discovery**
+
+Instead of listing account IDs manually, you can have ProjectDiscovery automatically discover all accounts in your AWS Organization.
+
+**Step 6: Create an Organization Discovery Role**
+
+<Note>
+This role must be created in the **management (root) account** of your AWS Organization — only the management account has permission to call `organizations:ListAccounts`. If the WIF role already lives in the management account, use the same account ID for both variables.
+</Note>
+
+```bash
+MANAGEMENT_ACCOUNT_ID="YOUR_MANAGEMENT_ACCOUNT_ID"  # AWS Organization management account (use the same value as ACCOUNT_ID if WIF is in the management account)
+ACCOUNT_ID="YOUR_AWS_ACCOUNT_ID"                     # Account where WIF role lives
+
+cat > org-discovery-trust-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Principal": {
+        "AWS": "arn:aws:iam::${ACCOUNT_ID}:role/PDWorkloadIdentityRole"
+      },
+      "Action": "sts:AssumeRole"
+    }
+  ]
+}
+EOF
+
+aws iam create-role \
+  --role-name PDOrgDiscoveryRole \
+  --assume-role-policy-document file://org-discovery-trust-policy.json
+```
+
+Attach organization read permissions:
+
+```bash
+cat > org-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "organizations:ListAccounts",
+        "organizations:DescribeOrganization"
+      ],
+      "Resource": "*"
+    }
+  ]
+}
+EOF
+
+aws iam put-role-policy \
+  --role-name PDOrgDiscoveryRole \
+  --policy-name OrgDiscoveryPermissions \
+  --policy-document file://org-policy.json
+```
+
+**Step 7: Allow the WIF role to assume the org discovery role**
+
+```bash
+MANAGEMENT_ACCOUNT_ID="YOUR_MANAGEMENT_ACCOUNT_ID"
+
+cat > assume-org-discovery-policy.json <<EOF
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": "sts:AssumeRole",
+      "Resource": "arn:aws:iam::${MANAGEMENT_ACCOUNT_ID}:role/PDOrgDiscoveryRole"
+    }
+  ]
+}
+EOF
+
+aws iam put-role-policy \
+  --role-name PDWorkloadIdentityRole \
+  --policy-name AssumeOrgDiscoveryRole \
+  --policy-document file://assume-org-discovery-policy.json
 ```
 
-**Verifying the Integration**
+**Configure in ProjectDiscovery:**
+
+| Field | Value |
+|---|---|
+| **OIDC Provider ARN** | ARN from Step 1 |
+| **WIF Role Name** | `PDWorkloadIdentityRole` |
+| **Scanner Role Name** | `PDScannerRole` |
+| **Org Discovery Role ARN** | `arn:aws:iam::MANAGEMENT_ACCOUNT_ID:role/PDOrgDiscoveryRole` |
+| **Exclude Account IDs** | _(optional)_ Account IDs to skip, one per line |
+
+Leave **Account IDs** empty — accounts are discovered automatically. Click **Verify** to test the connection.
 
-After configuring the integration, it's important to verify that ProjectDiscovery is successfully connected and enumerating your AWS assets:
+<Warning>
+**Scanner role is still required.** Organization Discovery only automates finding account IDs — the scanner role (`PDScannerRole` from [Step 3](#step-3-create-a-scanner-role)) must still exist in every account you want to scan. Use [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html), [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws/aws-iam-policy), or [AWS Organizations delegated admin](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_policies.html) to deploy the scanner role across all accounts automatically.
 
-- **Check Asset Discovery:** In the ProjectDiscovery platform, navigate to the cloud assets or inventory section. After a successful integration, you should start seeing resources from your AWS account(s) listed (for example, EC2 instance IDs, S3 bucket names, etc., corresponding to the integrated accounts). It may take a short while for the initial discovery to complete. If you see those assets, the integration is working.
-- **Test with a Known Resource:** As a quick test, pick a known resource (like a specific EC2 instance or S3 bucket in your AWS account) and search for it in ProjectDiscovery's asset inventory. If it appears, the connection is functioning and pulling data.
-- **Troubleshooting Errors:** If the integration fails or some assets are missing, consider these common issues:
-  - _Incorrect Credentials:_ Double-check that the Access Key and Secret (if used) were entered correctly and correspond to an active IAM user. If you recently created the user, ensure you copied the keys exactly (no extra spaces or missing characters).
-  - _Insufficient Permissions:_ If certain services aren't showing up, the IAM policy might be missing permissions. For example, if S3 buckets aren't listed, confirm that the policy includes `s3:ListAllMyBuckets`. Refer back to the Required Permissions and make sure all relevant actions are allowed. You can also use AWS IAM Policy Simulator or CloudTrail logs to see if any **AccessDenied** errors occur when ProjectDiscovery calls AWS APIs.
-  - _Assume Role Failures:_ In multi-account or cross-account setups, a common issue is a misconfigured trust relationship. If ProjectDiscovery cannot assume a role, you might see an error in the UI or logs like "AccessDenied: Not authorized to perform sts:AssumeRole". In that case, check the following:
-    - The trust policy of the IAM role (in target account) trusts the correct principal (either your primary account's IAM user/role ARN for multi-account, or ProjectDiscovery's external account ID for cross-account) and the External ID if applicable.
-    - The role name or ARN in the ProjectDiscovery config exactly matches the one in AWS (spelling/case must match).
-    - The primary credentials (for multi-account) have permission to call `AssumeRole`.
-  - _External ID Mismatch:_ For cross-account roles, if the external ID in ProjectDiscovery and the one in the IAM role's trust policy do not match, AWS will deny the assume request. Ensure you didn't accidentally copy the wrong value or include extra spaces. It must be exact.
-- **AWS CloudTrail Logs:** As an additional verification, you can check AWS CloudTrail in your account. When ProjectDiscovery connects, you should see events like `DescribeInstances`, `ListBuckets`, etc., being called by the IAM user or assumed role. For cross-account roles, you will see an `AssumeRole` event from ProjectDiscovery's AWS account ID, and subsequent calls under the assumed role's identity. This audit trail can confirm that the integration is working as intended and using only allowed actions.
+Accounts where the scanner role is missing will be silently skipped — no error is shown. To avoid blind spots, ensure the scanner role is deployed to all accounts before enabling org discovery.
+</Warning>
+
+---
 
-If all checks out, ProjectDiscovery is now actively monitoring your AWS environment. New resources launched in AWS should be detected on the next scan cycle, and any changes to your cloud footprint will be reflected in the platform. Make sure to regularly review the integration and update the IAM permissions if you start using new AWS services.
+#### AWS Troubleshooting
+
+| Error | Fix |
+|---|---|
+| `Not authorized to perform sts:AssumeRoleWithWebIdentity` | Check OIDC provider URL, WIF role trust policy `sub` condition (Team ID), and `aud` condition (`sts.amazonaws.com`) |
+| `Access Denied` on AssumeRole | Check target role trust policy trusts `PDWorkloadIdentityRole`, and WIF role has `sts:AssumeRole` permission |
+| `Access Denied` on resource enumeration | Check scanner permissions are on `PDScannerRole`, not the WIF role |
+
+---
 
 #### API Setup
 
 You can set up the AWS integration entirely through the API. The process involves creating a cloudlist configuration, verifying it, and then using it to create an enumeration.
 
 The cloudlist configuration is a YAML array that must be **base64-encoded** before sending it to the API. Each connection method uses a different YAML structure, but the API calls are the same.
 
 **Configuration Format**
 
@@ -925,9 +1165,9 @@
   <Accordion title="Single AWS Account (Access Key & Secret)">
     ```yaml
     - provider: aws
       aws_access_key: "AKIAIOSFODNN7EXAMPLE"
       aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
       aws_session_token: "optional-session-token"
       services:
         - ec2
         - route53
@@ -938,10 +1178,10 @@
   <Accordion title="Multiple AWS Accounts (Assume Role)">
     ```yaml
     - provider: aws
       aws_access_key: "AKIAIOSFODNN7EXAMPLE"
       aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
       assume_role_name: "ProjectDiscoveryReadOnlyRole"
       account_ids:
         - "123456789012"
         - "987654321098"
       services:
@@ -954,9 +1194,9 @@
   <Accordion title="Cross-Account Role (Role ARN)">
     ```yaml
     - provider: aws
       assume_role_arn: "arn:aws:iam::123456789012:role/ProjectDiscoveryRole"
       external_id: "your-external-id"
       assume_role_session_name: "projectdiscovery_role"
       services:
         - ec2
         - route53
@@ -1000,7 +1240,7 @@
 
 **Step 2: Create the Integration**
 
 Once verified, send the base64-encoded configuration to create a cloudlist config:
 
 ```bash
 curl -X POST https://api.projectdiscovery.io/v1/scans/config \
@@ -1040,11 +1280,10 @@
 
 **References:**
 
-1. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_read-only-console.html
+1. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
 2. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
-3. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html
-4. https://docs.aws.amazon.com/sdkref/latest/guide/feature-assume-role-credentials.html
-5. https://docs.logrhythm.com/OCbeats/docs/aws-cross-account-access-using-sts-assume-role
+3. https://docs.aws.amazon.com/sdkref/latest/guide/feature-assume-role-credentials.html
+4. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html
 
 ### Google Cloud Platform (GCP)
 
@@ -1060,9 +1299,9 @@
 |:---|:---|
 | [Cloud DNS](https://cloud.google.com/dns) | DNS zones and records |
 | [Kubernetes Engine](https://cloud.google.com/kubernetes-engine) | GKE cluster endpoints |
 | [Compute Engine](https://cloud.google.com/products/compute) | VM instances and public IPs |
 | [Cloud Storage](https://cloud.google.com/storage) | Buckets |
 | [Cloud Functions](https://cloud.google.com/functions) | Serverless function endpoints |
 | [Cloud Run](https://cloud.google.com/run) | Container service URLs |
 
 #### Enumeration Scope
@@ -1402,7 +1641,7 @@
 <Note>
 `YOUR_PROJECT_NUMBER` is the numeric project number, not the project ID. Find it with:
 ```bash
 gcloud projects describe YOUR_PROJECT_ID --format='value(projectNumber)'
 ```
 </Note>
 
@@ -1616,7 +1855,7 @@
 
    - If you only need specific services, you can further reduce actions. For example:
      - Virtual machines: `Microsoft.Compute/virtualMachines/read`, plus RG/subscription reads
      - Public IPs: `Microsoft.Network/publicIPAddresses/read`
      - Traffic Manager: `Microsoft.Network/trafficManagerProfiles/read`
      - Storage Accounts: `Microsoft.Storage/storageAccounts/read`
      - AKS Clusters: `Microsoft.ContainerService/managedClusters/read`
@@ -1639,9 +1878,9 @@
 
 
 
 ### Alibaba Cloud
 
 <Card title="Configure Alibaba Cloud Integration" icon="cloud" color="#FF6A00" href="https://cloud.projectdiscovery.io/assets/configure?provider=alibaba">
   Click here to open the Alibaba Cloud integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
@@ -1652,13 +1891,13 @@
   style={{ width:"62%" }}
 />
 
 Supported Alibaba Cloud Services:
 
 - ECS Instances
 
 **Alibaba Integration Method**
 
 This guide details the secure, best-practice method for connecting to Alibaba Cloud using a dedicated RAM user with read-only permissions.
 
 1. **Create a RAM User for API Access:**
    - Navigate to the **RAM (Resource Access Management) console**. [Ref](https://ram.console.aliyun.com/manage/ak)
@@ -1676,11 +1915,11 @@
    - Select the **System Policy** type.
    - Search for and select the `AliyunReadOnlyAccess` policy and click **OK**. This is the official, managed policy for read-only access to all cloud resources.
 4. **Find Your Region ID and Connect:**
    - Identify the **Region ID** for the resources you plan to monitor. You can find the official list in the Alibaba Cloud documentation here: [Regions and zones](https://www.alibabacloud.com/help/en/doc-detail/40654.htm) (This link lists the specific IDs required for API configuration).
    - Use the credentials you have collected to fill in the fields in ProjectDiscovery:
      - **Alibaba Region ID**: The target region, for example, `us-east-1`.
      - **Alibaba Access Key**: The AccessKey ID from Step 2.
      - **Alibaba Access Key Secret**: The AccessKey Secret from Step 2.
    - Enter a unique **Integration Name** and click **Verify**.
 
 References:
@@ -1721,8 +1960,8 @@
   - Clusters with public IP addresses
 </Note>
 
 1. **Prepare Base64-Encoded Kubeconfig**
    - Your kubeconfig file is typically located at:
 
      ```
      ~/.kube/config
@@ -1732,11 +1971,11 @@
      ```
      cat ~/.kube/config | base64
      ```
    - Paste the output into the **Kubeconfig** field in the UI.
 
      > ⚠️ Ensure the entire content is copied without extra whitespace.
 2. **Specify Context (Optional)**
    - If your kubeconfig has multiple contexts, find them with:
 
      ```
      kubectl config get-contexts
@@ -1755,7 +1994,7 @@
 
 If your Kubernetes integration fails, the most common cause is cluster accessibility:
 
 - **Internal Clusters**: Clusters only accessible within private networks (VPN, internal VPCs) cannot be reached by ProjectDiscovery
 - **Firewall Restrictions**: Ensure your cluster's API server and services are accessible from the internet
 - **Network Policies**: Check that network policies allow external access to required endpoints
 - **Load Balancer Configuration**: Verify that external load balancers are properly configured and accessible
@@ -1786,7 +2025,7 @@
 - DNS and CDN assets
 
 <Note>
   Connecting a Cloudflare integration also enables **origin IP exposure** detection under [Misconfigurations](/api-reference/enumerations/list-enumeration-misconfigurations). When a hostname from your asset inventory resolves to the same IP as the origin behind one of your proxied Cloudflare records, it is flagged as an origin exposure finding.
 </Note>
 
 **Cloudflare Integration Methods:**
@@ -1825,7 +2064,7 @@
 
 ### Fastly
 
 <Card title="Configure Fastly Integration" icon="bolt" color="#FF282D" href="https://cloud.projectdiscovery.io/assets/configure?provider=fastly">
   Click here to open the Fastly integration configuration page in the ProjectDiscovery Cloud platform
 </Card>
 
@@ -1836,16 +2075,16 @@
   style={{ width:"65%" }}
 />
 
 **Fastly Integration Method**
 
 - Go to Fastly [account settings](https://manage.fastly.com/account/personal).
 - Under **API**, click **Create API token** if you don’t already have one.
 - Copy the API Key.
 - Now enter API Key in ProjectDiscovery Cloud Platform.
 - Give a unique Integration name and click **Verify**.
 
   <Tip>
     Tip: In Fastly's documentation and interfaces, "API Key" and "API Token" refer to the same thing. You can use the terms interchangeably throughout this guide.
   </Tip>
 
 References: