Prisma Cloud: Onboarding an AWS Account

Prisma Cloud (Palo Alto Networks) covers cloud security posture management (CSPM), workload protection and code scanning. Posture management answers the question every security review begins with: what do we have in our cloud accounts, and which of it is misconfigured or exposed? The first step is read-only visibility into the account, which is low risk and delivers results within the hour.

Versions in use on this date. The SaaS edition of Prisma Cloud, which is updated continuously; menu names change between releases, so follow the current documentation if the screen differs from the steps below. AWS-side tooling is AWS CLI 2.11 and CloudFormation.

How the connection works

flowchart TB
  subgraph PC[Prisma Cloud tenant - SaaS]
    ENG[Ingestion engine<br/>polls AWS APIs every few hours]
    POL[Policies and compliance standards]
    ALERT[Alerts and inventory]
  end
  subgraph AWSACC[Your AWS account]
    ROLE[IAM role PrismaCloudReadOnlyRole<br/>trust Prisma Cloud principal<br/>condition sts ExternalId]
    SVC[EC2, S3, IAM, RDS, VPC, EKS configuration]
    CT[CloudTrail, VPC Flow Logs, S3 logs]
  end
  ENG -->|sts AssumeRole with ExternalId| ROLE
  ROLE -->|read only Describe, List, Get| SVC
  ROLE -->|optional log read| CT
  SVC --> POL
  CT --> POL
  POL --> ALERT
  ALERT --> TICKET[Jira, Slack, SIEM via integrations]
  ORG[AWS Organization management account] -.->|StackSet deploys role to every member account| ROLE

Prisma Cloud does not install an agent for posture management. It assumes an IAM role you create and calls read APIs, so what it can see (and change) is limited by that role’s permissions.

Onboard one account

1. In the console, Settings, Cloud Accounts, Add Cloud Account, choose AWS and Account.
2. Name the account (for example prod-111122223333) and choose the mode:
   • Monitor: read-only; findings and compliance reports. Start here.
   • Monitor and Protect: adds remediation actions through extra write permissions. Enable only after you trust the policies, and scope it to specific accounts.
3. Download the generated CloudFormation template. It creates a cross-account IAM role that Prisma Cloud assumes, protected by an external ID unique to your tenant. The external ID prevents the “confused deputy” problem, where another customer of the same SaaS tricks it into accessing your account.
4. Review the template before deploying. A read-only role should contain Describe*, List* and Get* actions, not *:*. Compare it with the permission list in the documentation and with the AWS-managed SecurityAudit and ViewOnlyAccess policies.
5. Deploy the stack:

aws cloudformation deploy --template-file prisma-role.yaml \
  --stack-name prisma-cloud-role --capabilities CAPABILITY_NAMED_IAM --region us-east-1
aws cloudformation describe-stacks --stack-name prisma-cloud-role \
  --query 'Stacks[0].Outputs'

IAM is global, so the stack region only decides where the CloudFormation stack lives; keep it in a region you already use for security tooling.

6. Copy the role ARN from the stack outputs back into the console, select the compliance standards (CIS AWS Foundations Benchmark, PCI DSS, NIST, SOC 2 and others) and finish. Prisma Cloud validates the role by assuming it.

Cover the whole organization

For many accounts, choose AWS Organization onboarding. You deploy a role in the management account that can enumerate member accounts, and a CloudFormation StackSet creates the read role in every member account (and automatically in new ones). Use a delegated administrator, not the management account, where AWS allows it, and exclude sandbox accounts deliberately rather than by accident.

Logs and extra visibility

Posture checks on configuration need only the role. For threat detection and network visibility, Prisma Cloud also reads logs: CloudTrail (management events), VPC Flow Logs, and optionally S3 and ALB access logs. Point them at S3 buckets the role can read, and mind the cost of storing and querying flow logs.

First scan: what to expect

After the first ingestion (typically within a few hours) the console shows:

View	What it gives you
Inventory / Asset inventory	Every resource, its configuration and relationships
Compliance	Percentage pass per standard, with the failing resources
Alerts	Policy violations grouped by severity and resource
Investigate	Query configuration and network paths (RQL)

The first scan will produce hundreds or thousands of alerts. Do not try to close them all.

Triage by exposure and impact

1. Internet-exposed and sensitive: public S3 buckets, security groups open to 0.0.0.0/0 on SSH (22), RDP (3389) or databases, public RDS snapshots, and instances with public IPs running old software.
2. Identity risk: root account without MFA, IAM users with unused keys older than 90 days, wildcard IAM policies, roles that can escalate privileges.
3. Logging gaps: CloudTrail not multi-region, no log validation, no VPC Flow Logs, Config not enabled.
4. Encryption and hygiene: unencrypted EBS or RDS, missing backups, no deletion protection.
5. Everything else goes to a backlog, scheduled by severity.

Create an alert rule that sends high-severity findings in production accounts to Slack and creates Jira tickets with an owner (use account tags to route). Suppress known exceptions with a documented reason and an expiry date, not forever.

Keep it healthy

• Review the role’s permissions after each Prisma Cloud update; unexpected Put* or Delete* in a read-only role is a red flag.
• Monitor the role itself: a CloudTrail alert on AssumeRole from unexpected sources, and on policy changes to the role.
• Record who administers Prisma Cloud, require SSO and MFA, and restrict access to the console by role (security, platform, read-only).
• Treat compliance percentages as direction, not goals. A green dashboard with an exposed database is worse than a red one that is being worked.
• Pair posture management with preventive controls (service control policies, S3 Block Public Access, AWS Config rules) so the same problems do not return.