Skip to main content
Plerion connects to AWS to deliver three capabilities:
  • Cloud Security Posture Management (CSPM)
  • Cloud Infrastructure Entitlement Management (CIEM)
  • Cloud Workload Protection Platform (CWPP)
CSPM and CIEM are read-only. CWPP performs agentless, out-of-band workload scanning, and it is CWPP that determines which of the three deployment options below is right for you.
This page covers the access model, exact IAM permissions, deployment options, and data handling for cloud and security teams who need to review and sign off before onboarding.

​
What Plerion assesses

A typical CSPM scan covers the services below: The final scope depends on your AWS Organization, accounts, regions, and customizations during onboarding.

​
AWS access model

The Plerion AWS integration is built on a cross-account IAM role which leverages temporary, auto-rotating credentials (via AWS STS).
  • Tenant-unique trust anchor. The role trust is anchored by a tenant-unique External ID and Plerion’s AWS control-plane account ID.
  • Control Plane. Plerion’s own AWS environment; orchestrating scans, managing appliances and storing results. No standing Plerion compute runs in your account between scans.
  • Tag Governance. All Plerion-created resources are tagged with Owner: Plerion for visibility, cost attribution (when enabled) and cleanup.
No long-term credentials are stored in Plerion or transmitted at any point. Capabilities and access level: Workload scanning is agentless, so nothing is installed on your workloads. Scanning is out-of-band: meaning Plerion snapshots a volume and analyses the snapshot on a separate ephemeral appliance, so there is no performance impact. Versioned, self-updating templates Plerion Cloudformation templates are versioned (for example: v30). Rather than hard-coding a URL, the current template URL and version are retrieved dynamically from the Plerion API. Optional Auto-Stack Update keeps your stack up to date with controlled and visible updates.

​
Deployment options

Posture and identity assessment work the same way across all three deployment models. The only thing that changes is where the workload scanning appliances run, and therefore where snapshot data is processed.
  • Plerion-managed. (default) Scanning appliances are launched, run, and terminated inside Plerion-owned AWS accounts. You grant one cross-account role and deploy a single CloudFormation stack. There are no networking resources to set up.
  • Customer-managed service account. A dedicated account you own runs the appliance fleet and scans all your other accounts centrally. Choose this to keep all scanning inside your own AWS Organization.
  • In-account. Appliances run in the same account as your workloads. Simple deployment but only practical for a single account.
The one question that determines which model to use: can a temporary, encrypted snapshot copy leave your AWS account? If yes, take the default. If your data classification says no, the customer-managed service account model gives you identical coverage with everything kept inside your own Organization.

​
Onboarding Plerion-managed scanning

You deploy one CloudFormation stack and choose your scope. Plerion provisions and operates the scanning infrastructure across every supported region. There is no appliance fleet for you to run, size, or patch.
1

Deploy one cross-account role

Launch a single CloudFormation stack. It creates the IAM roles and policies listed in the next section, and nothing else.
2

Choose scope

Select the workload types to scan (EC2, AMI, Lambda, ECS, ECR) and the regions to enable.
3

Snapshot and hand-off

A temporary snapshot is created in your account, re-encrypted with a Plerion-owned KMS key, and shared to the Plerion scanning account.
4

Scan and delete

A temporary volume is scanned in the Plerion account. Both the snapshot and the volume are deleted when the scan finishes. The first scan starts automatically.
What the stack creates in your account:
  • PlerionAccessRole — the cross-account role for Plerion to read your AWS resource metadata
  • PlerionPermissionsBoundary — a permissions boundary policy that caps all Plerion roles to prevent privilege escalation
  • PlerionInstanceProfileRole — assumed by appliances to read your workloads; only scan results are sent to Plerion
  • PlerionCSPMAccessPolicy and PlerionCSPMDenyPolicy — read-only permissions plus explicit denies on what Plerion can read
  • PlerionAutoUpdateRole — Optional. Lets Plerion update only Plerion-managed Cloudformation stacks
  • PlerionAPILambdaExecutionRole and PlerionAPICallFunction — Lambda used to finalize the onboarding integration via Plerion API
What you don’t need to do:
  • No VPC, subnet, or security group configuration
  • No StackSets deployment for the appliance fleet
  • No EC2 quota increase in your account
  • No dedicated service or shared-services account to stand up
  • No compute running in your account between scans
Additionally, the region selection is yours. You choose which regions are enabled during setup.

​
Service account model

Everything above still applies, and you add:
  • A dedicated shared-services or security-tooling account you own as the Service Account
  • A second stack which contains infrastructure per region: VPC, auto-scaling group, and scan queue
  • A PlerionApplianceRole in each target account, deployed at scale via StackSets
  • Sufficient on-demand EC2 quota per region for the appliance fleet
  • HTTPS egress on 443 from the appliance subnet (default service account template config)

​
IAM permissions and KMS access

Posture (CSPM) and identity (CIEM). Access equivalent to the AWS ReadOnlyAccess managed policy. No write access and no data-plane access. Workload scanning. Scoped, tag-restricted EC2 snapshot operations only: ec2:DescribeInstances, ec2:DescribeInstanceStatus, ec2:DescribeSnapshots, ec2:CreateSnapshots, ec2:CreateTags, ec2:ModifySnapshotAttribute, ec2:DeleteSnapshot, ec2:DeleteTags KMS access: two modes:
  • All keys mode. Appliances can use any customer-managed key except those you tag PlerionAccess: Denied. Recommended when you have a large number of keys.
  • Selected keys mode. Access only to keys you tag PlerionAccess: Granted. Nothing is accessible until you explicitly tag it.
Deploy identity and guardrails:
  • If not using administrator to deploy the cloudformation stacks, you can use the stack-launch identity which holds only the minimal CloudFormation, IAM, and Lambda actions needed, and is removable after deployment.
  • PlerionPermissionsBoundary caps every Plerion-created role to prevent privilege escalation.
  • An explicit deny policy bounds what posture assessment can read.

​
How agentless scanning works

Scanning is out-of-band. An ephemeral appliance spins up, reads a snapshot, and terminates. Any of your live workloads are never touched and never sees a performance impact.
1

Snapshot

Snapshot the instance volume and create a block device from it.
2

Attach

Attach the block device to our ephemeral appliance EC2 instance.
3

Scan

Read the filesystem for vulnerabilities, SBOM components, secrets, and sensitive data.
4

Clean up

Detach and delete the block device and snapshot automatically.
5

Transmit

Send only security metadata, then move to the next asset.
What is covered:
  • EC2 instances and Lambda function bundles
  • ECS and ECR container images: the last two pulled plus the most recently pushed
  • EKS clusters, via the in-cluster collector described below
  • All default AWS commercial regions. Opt-in regions are available on request.
What comes back:
  • Known CVEs, with context from sources such as the NVD, CISA, and ExploitDB
  • OS and kernel vulnerabilities for Linux and Windows
  • Software bill of materials (SBOM) in CycloneDX format
  • Secrets and sensitive data detection, reported by type and location

​
Kubernetes integration

For AWS EKS clusters, agentless workload scanning only covers the worker nodes themselves:
  • Node AMIs are snapshotted and scanned the same way as any other EC2 instance, surfacing OS and kernel vulnerabilities, SBOM, and secrets on the node filesystem.
  • This does not give visibility into how the cluster itself is configured. Set up the Kubernetes Integration with our lightweight collector-manager via helm for cluster visibility
  • The Kubernetes-native configuration posture covers RBAC misconfig, network policy gaps, namespaces, pod specs and more.
  • The collector has no access to Kubernetes secrets, no cluster-scoped write verbs and no application logs are read.

​
Data handling

Plerion’s workload scanner collects security-related metadata only. It does not collect raw data, personally identifiable information (PII), protected health information (PHI), or sensitive business data. Data is encrypted in transit and at rest, all operations are audited and only scan results are sent to Plerion. What leaves your environment:
  • Snapshots (Option 1): Snapshots are re-encrypted with a Plerion-owned KMS key. Source snapshot and temporary volumes in the Plerion account are both deleted after the scan and nothing is retained.
  • Vulnerability findings
  • SBOM components
  • Secret and sensitive-data findings — type and location only
What stays in your environment:
  • Snapshots (Option 2 & 3): Created, scanned and deleted inside your account. Deleted immediately once metadata is extracted.
  • Raw workload data and disk contents
  • PII, PHI, and business data
  • Live-workload access — scanning is snapshot-based and out-of-band
Snapshot residency: With Plerion-managed scanning (the default), a temporary snapshot is created in your account, re-encrypted with a Plerion-owned KMS key, and scanned on a temporary volume inside a Plerion account. The snapshot and the volume are both deleted when the scan finishes. Only security metadata is retained. With the service account or in-account model, snapshots are created, scanned, and deleted entirely within your own account or Organization — nothing leaves except metadata.

​
Prerequisites

Access and IAM:
  • Permission to launch Plerion CloudFormation stacks or use minimum AWS permissions
  • If you have encrypted volumes, a decision on KMS access mode: all keys or selected keys
Decisions before the first scan:
  • Which regions to enable
  • Which accounts are in scope. The Organization management account is onboarded separately.
Sign-offs:
  • Acceptance of the Plerion data-handling and residency model
  • NDA, DPA, or BAA as applicable
A cloud infrastructure or security owner is needed to make the onboarding decisions and console access to launch the stack.
This document describes deployment for security reviewers; it is not legal, contractual or compliance advice. For attestations (SOC 2, ISO 27001, and similar) and workload-specific data-handling commitments, See trust.plerion.com or contact your Plerion team.