Prisma Cloud Enterprise Implementation Guide for CNAPP and Runtime Security

Overview

Prisma Cloud is a cloud-native application protection platform (CNAPP) designed to secure public cloud infrastructure, workloads, identities, containers, Kubernetes, serverless functions, and infrastructure as code from a single control plane. Enterprises adopt it to consolidate CSPM, CWPP, CIEM, DSPM, and shift-left scanning so security teams can reduce tool sprawl and map findings to business risk.

Key enterprise use cases include:

• Continuous posture management across AWS, Azure, GCP, and Kubernetes
• Runtime defense for hosts, containers, and serverless workloads
• Identity risk reduction through excessive permission analysis
• Compliance reporting for frameworks such as CIS, PCI DSS, ISO 27001, and NIST
• DevSecOps integration into Terraform, GitHub Actions, Jenkins, and container registries

Architecture

Prisma Cloud has two major planes:

• SaaS management plane: policy engine, alerting, dashboards, compliance reporting, and API access
• Runtime protection plane: defenders deployed on hosts, containers, or Kubernetes clusters for workload telemetry and enforcement

Core components:

• Prisma Cloud Console: central UI and API for posture and runtime management
• Defender: lightweight agent for hosts, containers, and serverless runtime protection
• Cloud account integrations: read-only or least-privilege roles for AWS, Azure, and GCP
• CI/CD and registry connectors: image scanning and IaC analysis before deployment

Typical data flow:

1. Cloud accounts are onboarded using IAM roles, service principals, or service accounts.
2. Prisma Cloud ingests configuration metadata, activity logs, and identity context.
3. Defenders send runtime telemetry, vulnerability data, and behavioral events to the Console.
4. Policies evaluate posture drift, exposed workloads, malware, anomalous process execution, and compliance violations.
5. Alerts are pushed to SIEM, SOAR, Jira, Slack, or ServiceNow.

Deployment models:

• SaaS-first for most enterprises
• Self-hosted Compute Console for regulated runtime environments
• Hybrid where posture is SaaS-managed and runtime is tightly controlled per region

Implementation Guide

1. Onboard AWS account

Create a least-privilege cross-account role and enable CloudTrail, Config, and Security Hub integration.

aws iam create-role --role-name PrismaCloudReadOnlyRole --assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy --role-name PrismaCloudReadOnlyRole --policy-arn arn:aws:iam::aws:policy/SecurityAudit
aws cloudtrail describe-trails
aws configservice describe-configuration-recorders

2. Deploy Defender to Kubernetes

Add the Prisma Cloud Helm repository and install Defender with a dedicated namespace.

helm repo add prisma https://prismacloud.github.io/helm-charts
helm repo update
kubectl create namespace twistlock
helm install prisma-defender prisma/waas-defender -n twistlock -f defender-values.yaml
kubectl get pods -n twistlock

3. Integrate CI/CD image scanning

Use TwistCLI in the pipeline to scan images before push or deploy.

docker pull registry.example.com/app:1.4.2
./twistcli images scan --address https://console.prismacloud.example.com --user cicd-scanner --password "$PC_PASSWORD" --details registry.example.com/app:1.4.2

4. Enable IaC scanning for Terraform

Run Prisma Cloud scan in pre-merge validation.

prisma-cloud scan iac --path ./terraform --policy-built-in high,critical --format json

5. Configure alert forwarding

Create notification integrations for Splunk or Cortex XSOAR and map policies by severity, account group, and business unit.

Code Examples

Example 1: AWS trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::188619942792:root"},
      "Action": "sts:AssumeRole",
      "Condition": {"StringEquals": {"sts:ExternalId": "prisma-prod-external-id"}}
    }
  ]
}

Example 2: Defender Helm values

console:
  address: https://console.prismacloud.example.com:8084
cluster:
  name: prod-aks-eastus
defender:
  type: container
  privileged: true
  dnsPolicy: ClusterFirstWithHostNet

Example 3: Terraform policy target

resource "aws_s3_bucket" "logs" {
  bucket = "enterprise-central-logs-prod"
}

resource "aws_s3_bucket_public_access_block" "logs" {
  bucket                  = aws_s3_bucket.logs.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Security Hardening

• Use least-privilege IAM roles instead of broad administrator access for onboarding.
• Restrict Console access with SAML SSO, MFA, and role-based access control.
• Encrypt data in transit with TLS 1.2+ and validate outbound proxy trust chains for Defenders.
• Segment Defenders by environment: prod, non-prod, and regulated clusters.
• Enable audit logs and export them to immutable storage or SIEM.
• Rotate API keys and service credentials through a vault such as HashiCorp Vault or AWS Secrets Manager.
• Use runtime policies in alert mode first, then move high-confidence controls to prevent/block.

Comparison

Troubleshooting

Error 1: Defender cannot reach Console

Log sample:

time="2025-02-11T09:14:22Z" level=error msg="Failed to register with console" error="Post \"https://console.prismacloud.example.com:8084/api/v1/defenders\": x509: certificate signed by unknown authority"

Fix: Import the enterprise CA into Defender trust stores and verify the Console certificate chain.

Error 2: AWS onboarding permission failure

Log sample:

AccessDenied: User: arn:aws:sts::123456789012:assumed-role/PrismaCloudReadOnlyRole/session is not authorized to perform: config:DescribeConfigurationRecorders on resource: *

Fix: Add missing AWS Config read permissions and confirm the role assumption external ID matches Prisma Cloud settings.

Error 3: Image scan fails in CI

Log sample:

FATA[0003] authentication failed for registry.example.com/app:1.4.2: unauthorized: authentication required

Fix: Authenticate the CI runner to the container registry before invoking twistcli images scan.

Best Practices

Do

• Align account groups to business units and environments for delegated administration.
• Tune policies using severity, internet exposure, exploitability, and data sensitivity.
• Scan Terraform and container images before merge and before deployment.
• Send high-severity alerts to SIEM/SOAR with cloud account, owner tag, and remediation context.

Don't

• Do not grant AdministratorAccess to onboarding roles when read-only plus scoped remediation is sufficient.
• Do not enable blocking policies globally without baseline observation in production.
• Do not treat posture findings equally; prioritize public exposure, privilege escalation, and secrets leakage first.
• Do not leave Defender upgrades unmanaged; standardize version rollout through Helm or infrastructure pipelines.