Skip to main content

​
What Cymph uses it for

The AWS integration discovers cloud resources (EC2, Lambda, RDS, S3, IAM, etc.) and imports them as Cymph assets. See Asset actions. All operations are read-only — Cymph only calls Describe* / List* / Get* actions. It supports two credential modes: Access Key and IAM Role. Cross-account IAM Role is the recommended mode, because no long-lived credentials are stored by either party.

​
Access Key mode

You will need to supply an IAM user’s access key ID and secret access key. Optionally a session token can be provided for temporary (STS) credentials. The IAM user needs read access to the services Cymph discovers. The exact actions are listed under What Cymph reads; a policy limited to those is sufficient, and ReadOnlyAccess or SecurityAudit both cover them.

​
Cross-account IAM Role mode

Instead of long-lived keys, the customer creates a read-only IAM role that trusts Cymph’s AWS account. Cymph assumes the role via STS AssumeRole, so no long-lived credentials are stored by either party and access is easy to rotate or revoke. * Optional as far as AWS is concerned, but strongly recommended — see the confused-deputy problem.

​
Setup

  1. Create the role in the customer’s AWS account with a trust policy that allows Cymph’s account to assume it, gated by an external ID:
  2. Attach a read-only policy. The AWS managed policy ReadOnlyAccess (or SecurityAudit) covers the discovery calls; a tighter custom policy limited to the Describe* / List* / Get* actions used by the executor is preferable.
  3. Provide Cymph the role ARN and the external ID. Enter them in the integration form (Authentication method → IAM role) and click Test Connection to verify the role can be assumed.

​
Deployment-side IAM

In Assume Role mode Cymph calls STS using the API host’s own identity (the ECS task role / EC2 instance role, or ambient credentials from the environment). That identity must be allowed to call sts:AssumeRole on the customer roles, e.g.:
There is no Cymph-side config for this — it is part of the deployment’s IAM setup, not the integration record. This applies to self-hosted deployments; on a managed cloud tenant it is already in place.

​
What Cymph reads

Every call below is a read. Cymph makes no Create*, Put*, Update*, Delete*, or Modify* call against your account.
Secrets Manager and KMS are read as inventory only — DescribeSecret and DescribeKey return metadata. Cymph never calls GetSecretValue and never reads key material.
A least-privilege policy limited to exactly these actions is enough for discovery, and is preferable to ReadOnlyAccess if your security review needs one.

​
Which regions are scanned

IAM identities and the S3 bucket listing are account-wide and are always read in full. Everything else is regional:
  • If you name specific regions, only those are swept.
  • If you leave the region selection empty, Cymph enumerates every region enabled on the account and sweeps them in parallel.
A region that fails — not opted in, throttled, or denied — contributes nothing and is reported as failed. It is never treated as a region that has been emptied, so nothing is deleted on that basis.

​
How often discovery runs

A one-off import reads your account once, when you ask it to. To keep the resulting assets current, create a sync and give it a schedule — see Create a sync. Frequencies range from every 5 minutes to monthly.

​
Limits

​
Testing the connection

Test Connection calls sts:GetCallerIdentity with the credentials you supplied and reports what came back:
Invalid AWS credentials or access denied covers several distinct causes, because AWS deliberately does not distinguish between them:
  • a mistyped or rotated access key ID or secret
  • an expired session token
  • an assume-role attempt the trust policy rejected — the wrong account, or an external ID that does not match
  • the Cymph host’s own identity lacking sts:AssumeRole on the target role
Test Connection verifies the credentials, not the permissions. It stops at GetCallerIdentity. An integration can test successfully and still discover nothing, which almost always means the attached policy is missing the Describe* / List* / Get* actions listed above.
A region that is not enabled on the account never fails the connection test — it is skipped during discovery and reported as a failed region. If a resource you expected is missing, check the region is opted in before suspecting the credentials.