Our next-gen architecture is built to help you make sense of your ever-growing data Watch a 4-min demo video!

Back to All Docs

Cloud Security Posture Management (CSPM)

Last Updated: Sep. 19, 2023

Overview of CSPM

Cloud Security Posture Management (CSPM) serves as a comprehensive cybersecurity strategy to fortify the security posture of your cloud resources and keep all your data safe and sound. This is accomplished by continually monitoring for misconfigurations, vulnerabilities and compliance lapses within your cloud infrastructure.

Coralogix CSPM is designed to help you mitigate your attack surface and fend off the risks associated with cloud-based data breaches by comprehensively assessing the security health of your entire cloud infrastructure against industry best practices and regulatory standards.

Some scenarios where CSPM can prevent security and compliance breaches include:

  • An improperly configured S3 bucket that allows public access can lead to exposure of sensitive data. This not only risks sensitive data falling into the wrong hands but also poses a significant compliance violation, especially under regulations like GDPR and HIPAA.
  • Unencrypted Amazon RDS snapshots can be disastrous as this exposes your data to potential theft.
  • Operating Google App Engine Applications without HTTPS encryption can result in data leakage. This compromises the integrity and confidentiality of the data, making it vulnerable to man-in-the-middle attacks and other forms of cyber intrusion.

By automating the evaluation of cloud environments, Coralogix CSPM ensures that your cloud configurations align with security best practices and compliance standards such as ISO, CIS AWS, SOC 2, PCI, and HIPAA. This provides organizations with real-time insights, allowing for proactive risk mitigation and the maintenance of a secure cloud deployment. As businesses increasingly transition to the cloud, the importance of incorporating CSPM into your cybersecurity strategy is becoming ever more crucial.

The Coralogix CSPM solution is based on an agent that runs in the customer’s cloud environment. The agent performs tests to assess the security posture – checking if the current cloud setting is aligned with the recommended best practice or not. The test results are then sent to Coralogix to be displayed in the Coralogix Security UI.

Below you can find a list of the services that we currently support:

CSPM Testing Availability:

  • AWS (named: “aws”): WAF, KMS, Lambda, S3, RDS, EC2, IAM, CloudTrail, CloudFront, VPC, DocumentDB, FSx, DynamoDB/Dax, SQS, Api Gateway, Security Hub, ECR, ELB (v1/v2), EBS, Backup, EMR, AutoScaling, EKS, CloudWatch, Redshift, OpenSearch, NetworkFirewall, Elasticache
  • GCP (named: “gcp”): CloudDNS, CloudSQL, API Keys, GCE, GKE, VPC, Resource manager, Cloud Storage, Cloud Logging, Cloud Load Balancer, PubSub, Dataproc, KMS, IAM

SSPM Testing Availability:

  • GitHub (named: “github”)

Setting up the Coralogix CSPM Agent

There are two options for how to set up the CSPM agent. You can run the agent on a virtual machine such as an AWS EC2 instance, or you can use an orchestration tool such as Kubernetes.

Installation Using Virtual Machine


The Coralogix CSPM agent uses several GiB of memory when executing tests which scales with the amount of resources being tested.

Minimum hardware requirements:

  • 4 GiB (for large cloud environments containing more than 1,000 EC2 VMs, use 8 GiB or more).
  • 2 or more CPU cores

STEP 1. Get a virtual machine, (such as an AWS EC2 instance) sized according to the guidelines in the prerequisites and obtain terminal access (for example via SSH).

STEP 2. Install Docker.

STEP 3. Create a file local.yaml in your current directory, using a terminal. Configure the file using the details in the Configuration section below.

STEP 4. Run the following command in a terminal from the folder in which the local.yaml file is located:

docker run -d coralogix/agent:latest -v ./local.yaml:/cxa/config

Installation Using Orchestration Tool (e.g. Kubernetes)

STEP 1. Install Docker Compose.

STEP 2. Create a file called docker-compose.yaml with the following content:

version: '2'
    image: coralogix/agent:latest
      - agent_config
    file: ./local.yaml

STEP 3. Create a configuration file local.yaml in the directory where you created the docker-compose.yaml file. Configure the file using the details in the Configuration section below.

STEP 4. Run the following commands in a terminal from the directory in which you created the local.yaml and docker-compose.yaml files:

docker compose pull; docker compose up -d

STEP 5. To stay up to date with the latest agent version, you can use a script to automatically re-run these commands periodically. It will automatically update the running agent when a newer version is released.


It’s recommended to verify the new version in a staging environment before updating it in production. You can run the above script daily as a cron job or use your favorite CI/CD platform to only update minor versions. Here are some example links:


The agent comes with an annotated default version of the configuration. Edit the file and uncomment keys as needed.

Within the configuration, there are three important sections:

  • The Root section (General) allows you to modify some of the agent behavior.
  • The aws/gcp/github sections provide the authentication credentials for each service.
  • The Coralogix section configures the Coralogix connection.

In the default configuration file, follow these steps:

STEP 1. Configure the account authentication required to perform the tests by uncommenting the relevant sections in the default configuration file (provided below), and filling it with your authentication details.

STEP 1a. For AWS, use the values described in the Amazon Web Services (AWS) section below.

STEP 1b. For GCP, use the values described in the Google Cloud Platform (GCP) section below.

STEP 1c. For GitHub, use the values described in the GitHub section below.

STEP 2. Configure how the agent sends the results back to Coralogix as described in the Coralogix section below.

💡 NOTE You can also define environment variables which will take priority on top of the configured values. For more information, see Environment Variables below.

Default Configuration File

# General settings

# How many seconds between tester polls
interval_secs: 59

# Providers to poll. Removing one will deactivate automatic scanning
providers: ["aws", "github", "gcp"]

# Provide credentials here or via the equivalent environment variables

## GitHub
#  # GitHub (classic) private access token. The required permissions are: 
#  # read:audit_log, read:enterprise, read:gpg_key, read:org, read:project, read:public_key, read:repo_hook, read:ssh_signing_key, read:user, repo, user:email
#  token: "ghp_88eiK0RNNRgYwLK1UT33PZybr0nDZoP"
#  # Which (GitHub) organizations to include in the testing. Note that the account has to have "owner" permissions for some testers. 
#  orgs: ["my-org"]

## AWS
#  # Default region
#  region: "eu-west-1"
#  # Credentials for AWS
#  secret_access_key_id: "my-secret-access-key"
#  access_key_id: "my-access-key"
#  # Retries in case the AWS API fails
#  retries: 100
#  # Optional role to use for querying the data
#  # iam_role: "my-role"
#  # Regions to include for testers
#  include_regions: [ "sa-east-1", "us-east-2", "us-west-1", "us-west-2" ]

## GCP
#  project_configs:
#    - project_number: 123456789123
#      client_email: "***"
#      private_key_id: "***"
#      private_key: "***"
#      token_uri: "<https://oauth2.googleapis.com/token>"
#      scopes: ["<https://www.googleapis.com/auth/cloud-platform>"]
#   organization_configs:
#     - organization_id: 1234567890
#       client_email: "***"
#       private_key_id: "***"
#       private_key: "***"
#       token_uri: "<https://oauth2.googleapis.com/token>"
#       scopes: ["<https://www.googleapis.com/auth/cloud-platform>"]
#   postgres_log_min_error_statement: "error"
#   postgres_max_connections: "100"
#   sql_server_user_connections: "100"

# Coralogix connection configuration

  # gRPC endpoint of the Coralogix cluster. Check the docs <https://coralogix.com/docs/cloud-security-posture-cspm/>
  grpc_endpoint: https://ng-api-grpc.<coralogix-domain>
  # logs endpoint of the Coralogix cluster. Check the docs <https://coralogix.com/docs/coralogix-domain/>
  logs_endpoint: https://ingress.<coralogix-domain>
  # Your Coralogix private key
  private_key: 877E1EB0-EBE2-4EEF-9170-9B418F98F654
  # Meta data application name for Coralogix
  application_name: MyApplication
  # Meta data subsystem name for Coralogix
  subsystem_name: MySubsystem
  # If true doesn't actually send the data
  dry_run: true
  # Optional account name for synchronizing polls 
  # account: "my-account"

Amazon Web Services (AWS)

For AWS the agent requires the access key id and secret access keys of a user. If provided, the agent will assume a role before doing any API calls.

This is an example block for configuring AWS. Note that the include_regions and the region  define the scope of the resources that will be tested:

  # Default region
  region: "eu-west-1"
# Credentials for AWS
  secret_access_key_id: "my-secret-access-key"
  access_key_id: "my-access-key"
# Retries in case the AWS API fails
  retries: 100
  # Optional role to use for querying the data
  iam_role: "my-role"
  # Regions to include for testers
  include_regions: [ "sa-east-1", "us-east-2", "us-west-1", "us-west-2" ]

These are the required role permissions for AWS tests:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "DSPM",
            "Effect": "Allow",
            "Action": [
            "Resource": "*"

To use the agent with multiple accounts, you can set up a role with cross account access: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

Google Cloud Platform (GCP)

In this section you configure the authentication for each Google project or organization. You can configure several projects/organizations in an array. For example:

    - project_number: 123456789123
      client_email: "***"private_key_id: "***"private_key: "***"token_uri: "<https://oauth2.googleapis.com/token>"scopes: ["<https://www.googleapis.com/auth/cloud-platform>"]
    - project_number: 012345678912
      client_email: "***"private_key_id: "***"private_key: "***"token_uri: "<https://oauth2.googleapis.com/token>"scopes: ["<https://www.googleapis.com/auth/cloud-platform>"]
     - organization_id: 1234567890
       client_email: "***"private_key_id: "***"private_key: "***"token_uri: "<https://oauth2.googleapis.com/token>"scopes: ["<https://www.googleapis.com/auth/cloud-platform>"]
   postgres_log_min_error_statement: "error"postgres_max_connections: 100
   sql_server_user_connections: 100

Google cloud authentication is granted via a service account. The permissions required for each project are:

































In this section you configure the authentication for GitHub. Authentication to GitHub is granted via a personal access token (classic) of a user account. More information can be found at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#fine-grained-personal-access-tokens

The required permissions for the token are: read:audit_log, read:enterprise, read:gpg_key, read:org, read:project, read:public_key, read:repo_hook, read:ssh_signing_key, read:user, repo, user:email.

Additionally, the user to which the token belongs must have owner permissions within the organization where the agent is run.


In this section, you configure how the test results are sent to be displayed in Coralogix. The following information is required:

Private/API keyCoralogix Send-Your-Data API key.
application_name / subsystem_nameMetadata fields that you can filter by on Coralogix.
logs_endpointThe Coralogix cluster to send the results to, using the ingress vhost with the Coralogix domain.
For example, https://ingress.eu2.coralogix.com/
grpc_endpointThis URL tells the agent where to poll (in interval_secs) and whether to execute the tests. See table below for available endpoints.

GRPC Endpoints

This endpoint delivers the execution notifications.

United Stateshttps://ng-api-grpc.coralogix.us/

Environment Variables

Environment variables allow for easy integration with more complex orchestrators such as Kubernetes with a secrets store such as AWS KMS.

The structure of an environment variable configuration corresponds to the YAML structure above. Each key can be set using the CXA__  prefix (that is, CXA with two underscores _) followed by the section and again followed by the actual key. For example, the following key leads to the same token as from the YAML file above) – each separated by a period (.).


Lists use comma-separated strings and a JSON-esque notation:


For more information, check out https://docs.rs/figment/0.10.8/figment/providers/struct.Env.html

Here is the example from above, in an .env file:



Note that keys are not case sensitive.


Coralogix triggers a scan (also called a “run”) by default every 24 hours. You can change this setting in the Security tab in the Coralogix UI, after logging into your Coralogix instance. The Scan Settings button will be on the right.


Need help?

Our world-class customer success team is available 24/7 to walk you through your setup and answer any questions that may come up.

Feel free to reach out to us via our in-app chat or by sending us an email at [email protected].

On this page