> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetrident.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect Your Cloud Accounts to Trident Cloud Security

> Connect your AWS, Azure, GCP, or Kubernetes environment to Trident using a read-only IAM role — no agents installed, no network changes required.

Trident connects to your cloud environment through a **read-only IAM role** (or provider-equivalent) that you create in your own account. Trident assumes that role on each scan cycle — it never stores long-lived credentials, never installs agents, and never makes changes to your infrastructure. The entire connection model is pull-based and read-only: Trident observes, it does not mutate.

<Note>
  Trident never stores long-lived credentials. It assumes the read-only role
  on each scan cycle using short-lived tokens, so rotating or revoking the
  role immediately stops all access.
</Note>

## Connect an AWS account

AWS is the most common first connection. Trident provides a CloudFormation template to create the role in one click, or you can apply the IAM policy JSON manually.

<Steps>
  <Step title="Open the Add Account flow">
    In the [Trident dashboard](https://app.usetrident.dev), navigate to
    **Cloud → Add Account → AWS**.
  </Step>

  <Step title="Copy your External ID">
    Trident displays a CloudFormation template link and an IAM policy JSON
    document. Before you leave this page, copy your **External ID** — you
    will paste it into the IAM trust policy in the next step. The External ID
    is unique to your Trident project and prevents confused-deputy attacks.
  </Step>

  <Step title="Create the IAM role in your AWS account">
    In your AWS account, create a new IAM role with the trust policy Trident
    provides. The trust policy allows Trident's scanner principal to assume
    the role, scoped to your External ID. Attach the Trident-provided
    read-only permission policy — it covers compute, IAM, networking,
    storage, and secrets services. **No write permissions are included.**

    If you prefer one-click setup, launch the Trident-provided
    CloudFormation template instead — it creates the role and attaches the
    policy automatically.
  </Step>

  <Step title="Paste the role ARN and connect">
    Back in the Trident dashboard, paste the ARN of the role you just
    created (format: `arn:aws:iam::<account-id>:role/<role-name>`) and
    click **Connect**.
  </Step>

  <Step title="Wait for the first scan">
    Trident validates the role and runs its first scan. The initial scan
    typically completes in under five minutes. Once it finishes, your assets
    appear in **Cloud → Assets** and your security graph is live.
  </Step>
</Steps>

## Connect Azure, GCP, or Kubernetes

Each provider follows the same pattern — you create a read-only credential in your environment and hand Trident a reference to it.

<Tabs>
  <Tab title="Azure">
    Navigate to **Cloud → Add Account → Azure**. Trident walks you through
    creating an **Azure service principal** with a Reader role assignment
    scoped to your subscription or management group. You provide the
    tenant ID, client ID, and client secret. Trident encrypts the credential
    at rest using AES-256-GCM and uses it only during scan cycles.
  </Tab>

  <Tab title="GCP">
    Navigate to **Cloud → Add Account → GCP**. Trident asks you to create a
    **GCP service account** with the built-in `roles/viewer` and
    `roles/iam.securityReviewer` roles, then download its JSON key. Upload
    the key in the Trident dashboard — it is encrypted and used only for
    scanning.
  </Tab>

  <Tab title="Kubernetes">
    Navigate to **Cloud → Add Account → Kubernetes**. Trident generates a
    `ClusterRole` and `ClusterRoleBinding` manifest that grants read access
    to pods, deployments, services, secrets metadata, and RBAC resources.
    Apply the manifest to your cluster with `kubectl`, then provide the
    cluster API endpoint and a service account token. Trident works with
    EKS, GKE, AKS, and self-managed clusters.
  </Tab>
</Tabs>

## What permissions Trident requests

Trident requests the minimum read-only permissions required to build the security graph. The scope covers:

| Surface        | Examples                                                                 |
| -------------- | ------------------------------------------------------------------------ |
| **Compute**    | List/describe EC2 instances, Lambda functions, EKS clusters, pods        |
| **IAM**        | List roles, policies, users, groups, and effective permission simulation |
| **Networking** | VPCs, subnets, security groups, load balancers, DNS                      |
| **Storage**    | S3 bucket metadata, ACLs, and policies (not object contents)             |
| **Secrets**    | Secrets Manager / KMS key metadata (not secret values)                   |
| **Databases**  | RDS, DynamoDB, Cloud SQL instance metadata                               |

Trident never requests write permissions, never reads secret *values*, and never accesses object contents in storage buckets.

## Ingest output from existing scanners

If you already run Prowler, Trivy, Kubescape, Falco, CloudQuery, Steampipe, TruffleHog, or similar tools, you can push their JSON output directly into Trident's security graph. This enriches your attack path analysis with data from tools you already trust.

Send a `POST` request to the scanner ingest endpoint using your project's API key for Basic auth:

```bash theme={null}
POST /api/public/trident/scanner-ingest
Authorization: Basic <base64(publicKey:secretKey)>
Content-Type: application/json
```

```json theme={null}
{
  "scanner": "trivy",
  "accountExternalId": "my-cluster-prod",
  "provider": "KUBERNETES",
  "raw": { ...trivy JSON output... }
}
```

The complete set of supported `scanner` values is:

| Value            | Tool                                      |
| ---------------- | ----------------------------------------- |
| `falco`          | Falco / falcosidekick runtime alerts      |
| `trivy`          | Trivy container and repository scans      |
| `kubescape`      | Kubescape Kubernetes posture              |
| `cloudquery`     | CloudQuery asset and edge inventory       |
| `steampipe`      | Steampipe cloud inventory                 |
| `threatmapper`   | ThreatMapper cloud and container topology |
| `pmapper`        | PMapper effective-permission graph        |
| `neuvector`      | NeuVector deep runtime security           |
| `stackrox`       | StackRox / RHACS Kubernetes posture       |
| `ciem`           | Generic CIEM output                       |
| `gcp_ciem`       | GCP-native CIEM output                    |
| `azure_ciem`     | Azure-native CIEM output                  |
| `terraform`      | Terraform plan static analysis            |
| `checkov`        | Checkov IaC scanning                      |
| `tetragon`       | Tetragon eBPF runtime events              |
| `trufflehog`     | TruffleHog secret detection               |
| `osv`            | OSV vulnerability feed                    |
| `cloudsplaining` | Cloudsplaining IAM analysis               |
| `dspm_content`   | DSPM content-tier data classification     |
| `mcpSafety`      | MCP tool-call safety scanner              |

The endpoint returns a `scanId` and a `202 Accepted` status — findings appear in your inbox once Trident processes the job.

## Removing an account

To disconnect a cloud account, go to **Cloud → Settings → Disconnect Account** and confirm. Trident stops scanning that account immediately. You should also delete the IAM role (or service principal/service account) from your cloud environment to fully revoke access.