Phase 2: Provision the AWS resources
Phase 2: Provision the AWS resources
This phase provisions the AWS resources used by Cortex to protect your cloud environment.
Set up your variables
Set these shell variables before running any commands. Use these examples, but replace the placeholder values with the identifiers provided by Cortex for your environment.
# Identifiers provided by Cortex
OUTPOST_ROLE_ARN="arn:aws:iam::237422644089:role/gcp_saas_role"
AUDIENCE="cortex-audit-logs"
COLLECTOR_SA_ID="116501907218496843752"
# Your AWS environment
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_REGION=$(aws configure get region)
CLOUDTRAIL_BUCKET="your-cloudtrail-bucket-name"
CLOUDTRAIL_SNS_ARN="arn:aws:sns:${AWS_REGION}:${AWS_ACCOUNT_ID}:your-cloudtrail-topic"
CLOUDTRAIL_KMS_ARN="" # The KMS key used by CloudTrail
# Resource names (choose your own naming convention)
SQS_QUEUE_NAME="cortex-cloudtrail-logs-queue"
LOGS_ROLE_NAME="cortex-logs-ingestion-role"
DISCOVERY_POLICY_NAME="Cortex-Discovery-Policy"
CORTEX_ROLE_NAME="CortexPlatformRole"Step 2.1: Create the Cortex Discovery Custom Policy
Create a custom permission set (IAM managed policy) that gives Cortex read access to AWS services not covered by the standard AWS read-only policies. This includes services like API Gateway, AppSync, Backup, Batch, CodeBuild, GuardDuty, SageMaker, and others.
Use the following to create the policy to be added to the platform role. Name the policy according to the following naming convention: Cortex-DISCOVERY-Policy-m-a-<lcaas> where <lcaas> is the Cortex tenant ID.
Step 2.2: Create the Cortex Platform Role
The Cortex Platform Role is the main IAM role (a set of permissions) that Cortex uses to access your AWS account. The role is configured so that only Cortex is allowed to use it, based on the specific OutpostRoleArn and ExternalID values. This setup relies on "cross-account role assumption," allowing Cortex to run in a different account while safely acting on your behalf in your account.
Step 2.3: Create the SQS Queue for CloudTrail Logs
Create the SQS queue, the "mailbox" in the delivery chain. This queue sits between the CloudTrail SNS topic (the bulletin board) and Cortex (the reader). When CloudTrail saves a new log file to S3, it notifies SNS. SNS forwards that notification to this queue and Cortex picks it up and fetches the log file.
Step 2.4: Set the SQS Queue Policy
By default, the SQS queue (mailbox) does not accept messages from other AWS services. This step adds a permission rule that explicitly allows the CloudTrail SNS topic to put messages into the queue. Without this rule, the SNS → SQS part of the delivery chain would be blocked.
Step 2.5: Subscribe the SQS Queue to the CloudTrail SNS Topic
Connect the SQS queue (mailbox) to the CloudTrail SNS topic (bulletin board). After this step, the full delivery chain is active: CloudTrail → S3 Bucket → SNS → SQS. Cortex will start receiving notifications about new log files as soon as the ingestion role (Step 2.6) is created.
Step 2.6: Create the CloudTrail Logs Ingestion Role
Create the IAM role that Cortex uses to actually read the log files. This role gives Cortex permission to:
Read log files from the S3 bucket (the storage folder where CloudTrail saves logs).
Pick up and delete messages from the SQS queue (the mailbox).
This role uses a special trust method called Web Identity Federation (WIF). It allows Cortex's Google Cloud service account to use this AWS role directly, without needing a separate AWS user or password.
Step 2.7: Create the Scanner Role (Optional — Outpost Scanning)
If you enabled data security scanning (DSPM), registry scanning, or serverless scanning in the AWS onboarding wizard in Cortex (Phase 1), you must create an additional IAM role that the Cortex scanner assumes. This role has its own trust policy with a separate external ID.
Step 2.8: Additional Permissions (Required).
Additional IAM permissions need to be granted to both the scanner and platform roles in accordance with the security capabilities and features that you enabled in the AWS onboarding wizard in Cortex (Phase 1).
Scanner role related permissions
Serverless scanning
If you enabled serverless scanning, these policies need to be added to the scanner role:
Registry scanning
If you enabled registry scanning, these policies need to be added to the scanner role:
Data Security Posture Management (DSPM)
If you enabled DSPM, this policy must be added to the scanner role. An additional policy must be added to the platform role.
Note that there are two variables in the policy, which must be replaced with the values from the identifiers file that you downloaded from Cortex (Step 1.2): <MTKmsAccountDSPM>, and <CortexPlatformScannerRoleARN>. The <AWS_AccountId> value is the ID of the AWS account you are onboarding (or using as a "host" when onboarding an organizational unit).
Platform Role Related Permissions
Agentless disk scanning
If you enabled agentless disk scanning, add this policy to the platform role. Name the policy according to the following naming convention: Cortex-ADS-Policy-m-a-<lcaas> where <lcaas> is the Cortex tenant ID.
Note that there are two variables in the policy, which must be replaced with the values from the identifiers file that you downloaded from Cortex (Step 1.2): <OutpostAccountId>, <KmsAccountADS>.
Automation
If you enabled automation, this policy must be added to the platform role. Name the policy according to the following naming convention: Cortex-Automation-Policy-m-a-<lcaas> where <lcaas> is the Cortex tenant ID.
Important: When applying this policy, AWS may display a standard alert regarding the use of wildcards (*) with the iam:PassRole and iam:CreateServiceLinkedRole actions. While AWS proactively flags wildcards to encourage specificity, these permissions are safely granted when the Automation security capability is enabled to keep your environment secure.
The Automation capability pre-configures a list of integrations and associated commands to automate security issue responses. Because these commands can be utilized individually or woven into custom playbooks for dynamic issue remediation, Cortex must have the flexibility to provision service-linked roles and pass runtime roles to newly generated security resources on the fly. Since these automated remediation workloads are created dynamically in response to active threats, their exact Resource ARNs cannot be predicted or hardcoded in advance. The entire operational boundary is tightly restricted by the role's trust policy. Only Cortex, verified by your unique ExternalID and OutpostRoleArn, is permitted to trigger these automated guardrails and playbooks on your behalf.
Data Security Posture Management
If you enabled DSPM, add this policy to the platform role. An additional policy must be added to the scanner role, as above. Name the policy according to the following naming convention: Cortex-DSPM-Policy-m-a-<lcaas> where <lcaas> is the Cortex tenant ID.
Note that there are 4 variables in the policy: MTKmsAccountDSPM, CortexPlatformRoleName, CortexPlatformScannerRoleName, AccountId.
Note that there are two variables in the policy, which must be replaced with the values from the identifiers file that you downloaded from Cortex (Step 1.2): <MTKmsAccountDSPM> and <CortexPlatformRoleName>. The <AWS_AccountId> value is the ID of the AWS account you are onboarding (or using as a "host" when onboarding an organizational unit).
Last updated
Was this helpful?