> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plerion.com/llms.txt
> Use this file to discover all available pages before exploring further.
# AWS security review
> The Plerion access model, IAM permissions, deployment options, and data handling for teams to review before onboarding
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:
| Service area | Security focus |
| - | - |
| Object storage | S3 bucket configuration, public exposure, encryption, access policies, lifecycle and data protection controls |
| Compute | EC2 instance configuration, attached IAM roles, network exposure, security groups, patch posture, workload vulnerabilities |
| Databases | Access control, network exposure, encryption at rest and in transit, backup and configuration security |
| Logging and monitoring | CloudTrail management and data event logging, trail configuration, retention, centralized monitoring |
| Identity and access | Federated authentication, IAM users and roles, SSO, identity lifecycle, effective permissions, access grants |
| AWS governance | Organizations structure, multi-account controls, account governance, centralized security management |
| Networking | VPCs, subnets, route tables, security groups, network ACLs, internet-facing versus private connectivity |
| Containers and serverless | ECS, ECR, and Lambda where present, including workload configuration and container image security |
| Kubernetes / EKS | Cluster configuration, IAM and RBAC, workload security, network policies, node and pod security, image security |
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:**
| Capability | Access |
| - | - |
| CSPM | Read-only, posture and compliance assessment. Equivalent to the AWS `ReadOnlyAccess` Managed Policy |
| CIEM | Read-only, for entitlement analysis. Who can access what, across identities and resources |
| CWPP | Scoped write, agentless workload scanning for vulnerabilities, SBOM, secrets and sensitive data. Least-privilege, tag-scoped snapshot operations only. |
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.
| | Plerion-managed | Service account | In-account |
| - | - | - | - |
| Best for | Most accounts - default & recommended | Keeping scanning in your own Org | A single AWS account |
| Cross-account scanning | Yes | Yes | No |
| Where appliances run | Plerion-owned account | Your dedicated service account | Your workload account |
| Plerion network in your account | None | Yes (in service account) | Yes (VPC/Subnet/SG) |
| EC2 quota needed in your account | None | Yes, in the service account | Yes |
| Operational overhead | Lowest | Medium, centralized | Medium, per account |
| Snapshot data leaves your account? | Yes, encrypted EBS copy to Plerion | No, stays in your Organization | No |
| Preferred for highly regulated data | Consider option 2 or 3 instead | Yes | Yes |
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.
Launch a single CloudFormation stack. It creates the IAM roles and policies listed in the next section, and nothing else.
Select the workload types to scan (EC2, AMI, Lambda, ECS, ECR) and the regions to enable.
A temporary snapshot is created in your account, re-encrypted with a Plerion-owned KMS key, and shared to the Plerion scanning account.
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.
Snapshot the instance volume and create a block device from it.
Attach the block device to our ephemeral appliance EC2 instance.
Read the filesystem for vulnerabilities, SBOM components, secrets, and sensitive data.
Detach and delete the block device and snapshot automatically.
Send only security metadata, then move to the next asset.
| | |
| - | - |
| Default cadence | Every workload scanned every 24 hours. On-demand scans available. |
| Typical completion | About one hour across all appliances, depending on workload size. |
| Appliance ratio | 1 per 5 EC2 instances, ECS task definitions, and auto-scaling groups. 1 per 100 Lambda functions. |
| Filesystems read | ext2, ext3, ext4, XFS, NTFS |
**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](https://docs.aws.amazon.com/controltower/latest/userguide/opt-in-region-considerations.html) 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](https://docs.plerion.com/guides/integrations/kubernetes/overview) 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](https://docs.plerion.com/guides/integrations/aws/additional-aws-configurations/minimum-permissions-needed-to-launch-stack)
* 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](https://trust.plerion.com/) or contact your Plerion team.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.