The onboarding process creates AWS resources in the onboarding account (the management account for Organization or Organizational Unit scope). The exact set of resources depends on the onboarding scope and the security capabilities selected during the process. The resources fall into three categories: base resources (created for every cloud instance), scanning resources (created based on selected capabilities), and log collection resources (created when audit log collection is enabled).
Base resources
The following tables detail the AWS resources created as part of every cloud instance, according to scope.
The following resources are created as part of every cloud instance, regardless of which security capabilities are enabled.
Resource type | Resource name | Purpose |
|---|---|---|
AWS::IAM::Role | CortexPlatformRole | Primary IAM role assumed by Cortex Cloud using sts:AssumeRole. Attached: ReadOnlyAccess, AmazonMemoryDBReadOnlyAccess, SecurityAudit, AmazonSQSReadOnlyAccess, AWSOrganizationsReadOnlyAccess. Trust policy: principal = OutpostRoleArn with mandatory sts:ExternalId condition. Optional add-on capabilities (Discovery, ADS, DSPM, Kubernetes, Automation) attach additional policies to this role. |
AWS::IAM::Role | CortexTemplateCustomLambdaExecutionRole | Execution role for the custom Lambda function. Attached managed policy: AWSLambdaBasicExecutionRole. |
Custom::PublishRoleDetail | (CloudFormation-generated name) | CloudFormation custom resource that triggers the Lambda function to report stack outputs back to Cortex (ephemeral). |
AWS::Lambda::Function | (CloudFormation-generated name) | To complete the handshake, this Lambda function sends the CloudFormation Identifiers (role ARN, account ID, external ID) back to the Cortex Cloud platform via HTTPS PUT. For Org and OU scopes, it also sends two identifiers: the AWS Organization ID, and the targeting scope ID - the Organization root ID for Org scope, or the Organizational Unit (OU) ID for OU scope. |
The following resources are in addition to the resources created for account scope when onboarding at the organization or organizational unit (OU) scope.
Resource type | Resource name | Purpose |
|---|---|---|
AWS::CloudFormation::StackSet | CortexPlatformCloudRoleStackSetMember | Service-managed StackSet that deploys CortexPlatformRole (and CortexPlatformScannerRole if any scanner capability is enabled) plus selected scanning policies to every member account in the target OU. Automatic deployment onboards new accounts and removes stacks from offboarded ones. |
Organization and OU onboarding scopes follow the same workflow and create the same resources. In both cases, you launch the CloudFormation template from your AWS Organization management account. This is required by AWS for any deployment that targets multiple member accounts.The only difference between the two scopes is which accounts receive the Cortex Cloud resources:
Organization scope: Deploys Cortex Cloud resources to every account in your AWS Organization, including any accounts you add later.
OU scope: Deploys Cortex Cloud resources only to the accounts inside a specific OU that you choose, plus any sub-OUs nested underneath it
In both cases, the AWS Organization management account also receives Cortex Cloud resources because it hosts the audit-log collection infrastructure that Cortex Cloud needs to access. Two smaller differences also apply:
AWS organization metadata access: Organization scope grants Cortex Cloud read-only access to your AWS Organizations metadata (organization ID, account list) so it can identify which organization you have onboarded. OU scope does not grant this access.
CloudTrail audit logs: If you enable audit log collection, both scopes provision the collection infrastructure in the management account. With organization scope, CloudTrail is configured as an organization trail, meaning a single trail in the management account captures events from every member account automatically.
Scanning and automation resources
For organization and OU scopes, the CortexPlatformRole, the CortexPlatformScannerRole, and all selected capability policies are propagated to every member account using the member account StackSet. The onboarding helper function, handshake resource, and audit log resources are created only in the management account.
Resource type | Resource name | Purpose | Relevant security capabilities |
|---|---|---|---|
AWS::IAM::Role | CortexPlatformScannerRole | IAM role for scanner operations. Attached managed policy: ReadOnlyAccess. Trust policy allows scanner identity ARNs populated dynamically from outpost resources data. | Any of the following: DSPM, serverless scanning, registry scanning |
AWS::IAM::ManagedPolicy | Cortex-DISCOVERY-Policy | Managed policy attached to CortexPlatformRole. Grants read access to additional AWS services not covered by ReadOnlyAccess. | Always included |
AWS::IAM::ManagedPolicy | Cortex-ADS-Policy | Managed policy Cortex-ADS-Policy attached to CortexPlatformRole. Grants EC2 snapshot operations plus KMS support. Write actions are gated by the managed_by: paloaltonetworks tag condition. | Agentless disk scanning |
AWS::IAM::ManagedPolicy | Cortex-DSPM-Policy | Managed policy Cortex-DSPM-Policy attached to CortexPlatformRole. Grants permissions for data classification and sensitive-data discovery. Includes a scoped iam:PassRole to rds.amazonaws.com for snapshot-export workflows. Adds export.rds.amazonaws.com as a trusted service on the role's trust policy, and creates an inline policy Cortex-DSPM-Scanner-Policy on CortexPlatformScannerRole. | DSPM |
Inline policy | Cortex-DSPM-Scanner-Policy | Inline policy on CortexPlatformScannerRole. Grants the permissions that actually read customer data for sensitive data classification. | DSPM |
AWS::IAM::ManagedPolicy | Cortex-Automation-Policy | Managed policy Cortex-Automation-Policy attached to CortexPlatformRole. Grants permissions across a broad range of AWS services for automated remediation, active response, and enrichment. Statements are scoped by action; resources are *. | Automation |
AWS::IAM::ManagedPolicy | Cortex-K8s-Security-Policy | Managed policy Cortex-K8s-Security-Policy attached to CortexPlatformRole. Grants scoped EKS access-entry management, all conditioned on the managed_by: paloaltonetworks tag. Bound Kubernetes permission is the AWS-managed AmazonEKSAdminViewPolicy (read-only Kubernetes API access) | Kubernetes security |
Inline policy | ECRAccessPolicy | Inline policy on CortexPlatformScannerRole. Grants three ECR actions (BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for container image pull. | Registry scanning |
Inline policy | LAMBDAAccessPolicy | Inline policy on CortexPlatformScannerRole. Grants three Lambda read actions (GetFunction, GetFunctionConfiguration, GetLayerVersion) for serverless code retrieval | Serverless scanning |
Log collection resources
The following resources are deployed in the onboarding account (the management account for organization or OU scope). Log collection resources are never propagated to member accounts via the StackSet. In automated log collection mode, Cortex Cloud provisions the resources listed below. In custom (BYOB) log collection mode, only four resources are created: the SQS queue, SNS subscription to your existing topic, queue policy, and the CloudTrailReadRole.
Resource type | Resource name | Purpose |
|---|---|---|
AWS::KMS::Key | CloudTrailKMSKey | Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey*, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: CloudTrailReadRole) decrypt the logs. |
AWS::S3::Bucket | CloudTrailLogsBucket | S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy |
AWS::S3::BucketPolicy | CloudTrailLogsBucketPolicy | Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account. |
AWS::SQS::Queue | CloudTrailLogsQueue | SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files. |
AWS::SNS::Topic | CloudTrailSNSTopic | SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue. |
AWS::SNS::TopicPolicy | CloudTrailSNSTopicPolicy | Enables the CloudTrail service to publish notifications to the SNS topic. |
AWS::SNS::Subscription | CloudTrailSNSTopicSubscription | Subscribes the SQS queue to the SNS topic for message delivery. |
AWS::SQS::QueuePolicy | SNSPolicy | Enables the SNS topic to send messages to the SQS queue. |
AWS::IAM::Role | CloudTrailReadRole | Enables Cortex Cloud to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex Cloud's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt. |
AWS::IAM::Role | EmptyBucketLambdaExecutionRole | Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket. |
AWS::Lambda::Function | EmptyBucketLambda | Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal. |
Custom::EmptyBucketDetails | EmptyBucketCustomResource | CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral). CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral). |
AWS::CloudTrail::Trail | CloudTrail | Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation). Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true). |
When custom (BYOB) log collection is configured, you provide the existing S3 bucket and CloudTrail trail in your account. Cortex Cloud provisions the following four resources: CloudTrailReadRole, CloudTrail logs queue, SNS-to-SQS subscription and the Queue policy for the CloudTrail logs queue.
Naming convention for Cortex Cloud-managed AWS resources
All resources created during the onboarding deployment follow a deterministic naming pattern: Cortex<resource>-<scan-mode>-<scope>-<tenant-id>. The two IAM roles created in every deployment are:
CortexPlatformRole-<scan-mode>-<scope>-<tenant-id>: The primary access role Cortex Cloud uses to read and protect your AWS environment.
CortexPlatformScannerRole-<scan-mode>-<scope>-<tenant-id>: The role used by Cortex Cloud scanners (DSPM, registry, serverless) for data-plane reads.
Where:
<scan-mode> is m for cloud scan or o for outpost scan.
<scope> is a for account scope or o for organization/OU-scope deployments. The scope is fixed at template generation time.
<tenant-id> is the unique numeric identifier of your Cortex Cloud tenant.
Most Cortex Cloud-managed resources are tagged managed_by=paloaltonetworks for inventory and lifecycle tracking. Resources that do not support AWS tagging (such as S3 bucket policies, SNS subscriptions, and SQS queue policies) are not tagged but are managed under the parent resource's lifecycle. The same naming pattern applies to audit-log resources (cortex-ct-logs-…), KMS keys, and SQS queues created by the stack.
Note
Because role names are deterministic, you cannot deploy two cloud instances of the same scope and the same scan mode into the same AWS account.