Skip to main content

AWS Access — Customer Summary

Audience: customer security buyer (CISO, GC, compliance), and the cloud engineer who will deploy the role.

This page is the single artifact to share with a customer reviewing what SecurityV0 needs from their AWS environment. The IAM permission set described here is enforced by the canonical CloudFormation template at sv0-connectors/integrations/aws/cfn/securityv0-readonly-role.yaml. That template is the source of truth; this page is its plain-English summary.

In one sentence​

SecurityV0 needs a read-only IAM role in your AWS account(s), trusted by the SecurityV0 hub account, with an ExternalId that you choose. Same access pattern as Wiz, Orca, Datadog Cloud Security, and Prisma Cloud.

There is no agent installed in your environment. Every API call is read-only, made from the SecurityV0 hub via temporary STS credentials, and logged in your CloudTrail.

What we read​

Metadata only. No object contents, no secret values, no application data.

CategoryBusiness framingAWS services we permission
Identity inventoryIAM users, roles, groups, policies, federation providers (OIDC/SAML), access-key last-used signals, instance profiles, MFA devicesiam:* (read-only verbs only — Get*, List*, Generate*CredentialReport, Generate*ServiceLastAccessedDetails)
AI agent inventoryBedrock agents, action groups, agent versions, knowledge bases, flows, guardrailsbedrock:Get* / List* (configuration only — never invocation data)
Automation inventoryLambda functions, ECS clusters/services/task definitions, Step Functions state machines, EventBridge rules + targets + event buses + connections + API destinations, SNS topics. Note on Lambda: GetFunctionConfiguration returns the function's environment-variable map and GetFunction returns a presigned download URL for the function code. Customer-set values in either of those surfaces are visible to the connector. Treat Lambda environment variables as you would any non-secret config: do not store production secrets in them — use Secrets Manager or SSM SecureString instead.lambda:Get* / List*, ecs:Describe* / List*, states:Describe* / List*, events:Describe* / List* (incl. events:ListApiDestinations), sns:GetTopicAttributes / ListTopics / ListTagsForResource
Container image metadataECR repository policies, lifecycle policies, image manifestsecr:DescribeRepositories, ecr:GetRepositoryPolicy, ecr:GetLifecyclePolicy, ecr:DescribeImages, ecr:ListTagsForResource
Data store metadataS3 bucket settings (location, policy, encryption, public-access-block, logging, versioning, tagging, notification) — NOT bucket contentss3:Get*Bucket*, s3:ListAllMyBuckets, dynamodb:DescribeTable, dynamodb:ListTables, dynamodb:ListTagsOfResource
Secret and config metadataSecret names and resource policies, Parameter Store names — NOT valuessecretsmanager:DescribeSecret, secretsmanager:ListSecrets, secretsmanager:GetResourcePolicy, ssm:DescribeParameters
Audit signalCloudTrail trail configuration and event metadata via the CloudTrail API (LookupEvents)cloudtrail:DescribeTrails, cloudtrail:LookupEvents, cloudtrail:GetTrailStatus, cloudtrail:GetEventSelectors
Org structure (multi-account org-mode only)Account list, OU structure with full upward traversal, SCPsorganizations:List* (incl. ListAccounts, ListParents, ListOrganizationalUnitsForParent, ListRoots, ListPolicies), organizations:Describe*

The full enumerated permission list is in the canonical CFN. Every action is enumerated explicitly — there are no * wildcards beyond resource scoping.

A note on scope vs. current extraction. The canonical CFN grants the full permission set the SecurityV0 AWS connector targets. A subset of the granted categories — IAM Identity Center (AWS SSO), EKS Pod Identity, KMS key metadata, AWS Config rules, Access Analyzer findings — is part of the integration roadmap and not yet extracted by the current connector build. The connector never uses permissions beyond what the CFN grants, and the role description above is the authoritative scope of what your AWS account is exposing to SecurityV0. We will not silently begin extracting the roadmap categories without notifying connected customers.

Optional — CloudTrail S3 archive bucket (opt-in)​

If you want SecurityV0 to derive execution evidence from CloudTrail history beyond the ~90-day LookupEvents API window, you can opt in by setting the canonical CFN's CloudTrailBucketArn parameter to the ARN of your CloudTrail S3 archive bucket at deploy time. When you do, the role gains a second managed policy with two narrowly-scoped grants:

  • s3:ListBucket on Resource: <your CloudTrail bucket ARN> (no other buckets)
  • s3:GetObject on Resource: <your CloudTrail bucket ARN>/* (only objects in that bucket)

If you leave CloudTrailBucketArn empty (the default), the second policy is never created and your role's IAM scope is exactly what's described in the table above — no s3:GetObject grant exists.

The connector reads CloudTrail log files from this bucket only when its server-side CLOUDTRAIL_ENABLED and CLOUDTRAIL_BUCKET_NAME configuration is set. Both sides have to opt in for any S3 object read to occur.

What we will never do​

These are explicit non-permissions. The role does not grant them, so they cannot occur even by mistake.

  • Never read object contents in S3 — except, opt-in only, from a CloudTrail archive bucket you explicitly designate. By default no s3:GetObject is granted by the canonical CFN; we see bucket settings only. If (and only if) you set the optional CloudTrailBucketArn parameter at template deploy time, a second narrowly-scoped policy grants s3:GetObject on <that-bucket-ARN>/* and on no other bucket. See the "Optional — CloudTrail S3 archive bucket" section above for the full opt-in semantics.
  • Never read secret values from Secrets Manager. No secretsmanager:GetSecretValue. We see secret names, descriptions, and resource policies only.
  • Never read Parameter Store values. No ssm:GetParameter / GetParameters / GetParameterHistory — these would return SecureString values, so they are deliberately excluded. Only DescribeParameters (names and types) is granted.
  • Never read DynamoDB items. Only DescribeTable and ListTables. No Query, Scan, or GetItem.
  • Never invoke automation. No lambda:Invoke*, no states:StartExecution, no events:PutEvents.
  • Never write, create, modify, or delete anything. The policy contains zero Put*, Create*, Update*, Delete*, Attach*, Detach*, Tag*, or Untag* verbs.
  • Never assume any role other than the one you create for us. The hub uses a single sts:AssumeRole to enter your account.
  • Never use long-lived credentials inside your account. Every API call is made under a short-lived STS session token.

For an additional defense-in-depth signal, you can attach an IAM permissions boundary to the role that explicit-denies every write verb. Permissions boundaries are supported by IAM, and most enterprise security teams author their own to fit the standard pattern they already apply to other read-only third parties. SecurityV0 does not ship a boundary template today. The canonical CFN exposes the role ARN via its RoleArn output; from there you can inspect the attached managed policy (aws iam list-attached-role-policies --role-name SecurityV0ReadOnly) and write a boundary that matches your existing model.

How you grant access​

  1. You deploy the canonical CloudFormation template into your account. Single stack, ~1 minute to deploy. For multi-account orgs, deploy via CloudFormation StackSets across an OU.
  2. You choose the ExternalId — a 16–64 character secret you generate. SecurityV0 will only assume the role with that exact ExternalId. (Defends against confused-deputy attacks per AWS guidance.)
  3. You share the resulting role ARN and ExternalId with SecurityV0 via your preferred secure channel.

That is the entire onboarding. Setup time is 15–30 minutes including review. No agent installation, no IP allowlisting required, no inbound network access into your environment.

For multi-account organizations, SecurityV0 supports an org-mode flow that uses an Organizations role to enumerate accounts and a StackSet to deploy the per-account read-only role. See AWS org-mode bootstrap.

How you revoke access​

One step: delete the role. SecurityV0's next assume-role call fails with AccessDenied, and the connector marks the account as revoked.

Optional intermediate steps if you want to pause without revoking:

  • Detach the SecurityV0 managed policy from the role — connector calls return AccessDenied per action.
  • Rotate the ExternalId — the role no longer trusts the previous value, so SecurityV0 can no longer assume it.

There is no SecurityV0-side state that needs to be cleaned up. The role exists in your account; deleting it terminates access fully.

How you audit us​

Every API call SecurityV0 makes against your account appears in your CloudTrail. Specifically:

  • userIdentity.type = AssumedRole
  • userIdentity.principalId = <role-id>:SecurityV0-Connector-<unix-epoch> for the hub-bootstrap session, or <role-id>:SecurityV0-<your-account-id>-<unix-epoch> for per-account scan sessions
  • userIdentity.arn = arn:aws:sts::<your-account>:assumed-role/SecurityV0ReadOnly/SecurityV0-Connector-<unix-epoch> (or the per-account variant above)
  • userIdentity.sessionContext.attributes.creationDate = scan start time
  • The initial AssumeRole event records the ExternalId condition match
  • sourceIPAddress shows the SecurityV0 connector's source IP

You can write a CloudTrail Lake query, an Athena query, or a Config rule to alert on any SecurityV0 API call that is not on the read-only verb list — that alert should never fire. We treat any such alert as a P1 on our side.

Compliance framing​

The access pattern aligns with:

  • AWS Well-Architected Framework — Security Pillar, SEC02 (Identity Management): least-privilege, time-bounded credentials, federation over long-lived keys.
  • SOC 2 (CC6.1): logical and physical access controls — read-only, principal-bounded, revocable.
  • ISO/IEC 27001:2022 (A.5.18, A.8.3): access rights are restricted to what is necessary for the documented purpose.
  • PCI DSS 4.0 (Req. 7): restrict access by business need-to-know — the role grants no access to cardholder data stores' contents.
  • GDPR Art. 32: appropriate technical measures — encryption-in-transit (TLS to AWS APIs), no personal data exfiltration (no object reads), full audit trail in the controller's environment.

What's next​

If your team needs more depth on any of the above:

  • CloudFormation template review: the canonical readonly-role CFN is the source of truth. Diff this file in PRs to see exact permission changes over time.
  • Multi-account / org-mode setup: see AWS org-mode bootstrap.
  • Architecture deep dive: the SecurityV0 team can walk your engineering team through the connector internals and the canonical-data-model on a 30-minute technical session.

Questions or a customer-specific addendum required? Contact: contact@securityv0.com