AWS CloudWatch Plugin for Log Shipper

This document explains how to configure the AWS CloudWatch v1.0.0 plugin with the Log Shipper module of the Netskope Cloud Exchange platform. This plugin supports ingestion of:

• Alerts (DLP, Malware, Policy, Compromised Credential, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, Device, Content, Anomaly, Legal Hold)
• Events (Page, Application, Audit, Infrastructure, Network, Incident, Endpoint, Client Status)
• BWAN Events (Authentication, Audit, Client, Gateway, System)
• WebTx and Logs (Debug, Information, Error, Warning).

This plugin supports ingestion in CEF and JSON formats.

Prerequisites

To complete this configuration, you need:

• A Netskope tenant (or multiple, for example, production and development/test instances).
• A Netskope Cloud Exchange tenant with the Tenant plugin and Log Shipper plugin already configured.
• A Netskope Cloud Exchange tenant with the BWAN plugin already configured.
• The AWS Log Streaming plugin and Azure Log Streaming plugin already configured, for ingesting alerts, events and WebTx from the Netskope Log Streaming plugin.
• Amazon CloudWatch logs permissions to the IAM user.
  • DescribeLogGroups
  • DescribeLogStreams
  • CreateLogGroup
  • CreateLogStream
  • PutLogEvents
• Connectivity to AWS CloudWatch service.
• For Secret Manager configuration, refer to this documentation and to set up Azure Key Vault Secrets Manager refer to this documentation.

AWS CloudWatch Plugin Support

This plugin supports ingestion in CEF and JSON formats.

cloudwatch_client = boto3.client(
    "logs",
    aws_access_key_id=self.aws_public_key,
    aws_secret_access_key=self.aws_private_key,
    aws_session_token=self.aws_session_token,
    region_name=get_effective_region(self.configuration),
    verify=self._get_verify(),
    config=Config(
        proxies=self.proxy,
        user_agent=self.useragent,
        connect_timeout=CONNECT_TIMEOUT,
        read_timeout=READ_TIMEOUT,
        retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
    ),
)

cloudwatch_client.describe_log_groups(
    logGroupNamePrefix=log_group_name, limit=1
)

response = cloudwatch_client.describe_log_groups(
    logGroupNamePrefix=log_group_name,
    limit=DESCRIBE_PAGE_LIMIT,
    nextToken=next_token,
)

response = cloudwatch_client.describe_log_streams(
    logGroupName=log_group_name,
    logStreamNamePrefix=log_stream_name,
    limit=DESCRIBE_PAGE_LIMIT,
    nextToken=next_token,
)

cloudwatch_client.create_log_group(logGroupName=log_group_name)

cloudwatch_client.create_log_stream(
    logGroupName=log_group_name,
    logStreamName=log_stream_name,
)

log_events = [
    {"timestamp": timestamp_ms, "message": message}
    for message in batch
]

cloudwatch_client.put_log_events(
    logGroupName=log_group_name,
    logStreamName=log_stream_name,
    logEvents=log_events,
)

# endpoint = "https://rolesanywhere.{region}.amazonaws.com"
#            ("amazonaws.com.cn" for the China partition)
# canonical_uri = "/sessions"

request_parameters = json.dumps(
    {
        "durationSeconds": 900,
        "profileArn": profile_arn,
        "roleArn": role_arn,
        "sessionName": "Session",
        "trustAnchorArn": trust_anchor_arn,
    }
)

headers = {
    "Content-Type": "application/json",
    "X-Amz-Date": amz_date,
    "X-Amz-X509": amz_x509,
    "Authorization": authorization_header,
    "User-Agent": self.user_agent,
}

response = requests.post(
    endpoint + canonical_uri,
    data=request_parameters,
    headers=headers,
    proxies=self.proxy,
    timeout=ROLES_ANYWHERE_TIMEOUT,
    verify=self.verify,
)

private_key = serialization.load_pem_private_key(
    private_key_file.encode("utf-8"), None
)

# Encrypted key
private_key = serialization.load_pem_private_key(
    private_key_file.encode("utf-8"),
    password=str.encode(pass_phrase),
)

cert = x509.load_pem_x509_certificate(
    public_certificate_file.encode()
)

amz_x509 = str(
    base64.b64encode(
        cert.public_bytes(encoding=serialization.Encoding.DER)
    ),
    "utf-8",
)

serial_number_dec = cert.serial_number

signature = private_key.sign(
    data=string_to_sign.encode("utf-8"),
    padding=padding.PKCS1v15(),
    algorithm=hashes.SHA256(),
)
signature_hex = signature.hex()

Performance Matrix

This performance reading is conducted on a Large Stack CE with these VM specifications.

User Agent

APN/1.1 (ahq9d89xj9gspapczzdb59goq)

Workflow

1. Create a AWS CloudWatch Log Group, Log Stream and Policy.
2. Generate Private Key, Certificate Body, Password Phrase, Profile ARN, Role ARN, Trust Anchor ARN if using AWS IAM Role Anywhere.
3. Configure the AWS CloudWatch Plugin.
4. Configure a Log Shipper Business Rule for AWS CloudWatch.
5. Configure Log Shipper Log Delivery for AWS CloudWatch.
6. Validate the AWS CloudWatch plugin.

Watch a Video

Click play to watch a video.

Create a CloudWatch Log Group

1. Log in to the AWS Console.
2. From All Services, select CloudWatch, or search for CloudWatch in the search bar.
3. Check the region selector at the top right. The Log Group is created in that region, and you will select the same region in the plugin’s AWS CloudWatch Region Name parameter.
4. In the left panel, click Logs > Log groups.
5. Click Create log group.
6. Enter the Log group name, like netskope-ce-log-group.
7. Select a Retention setting, *Never expire*, or a period your organization needs.
8. Select Standard for Log class.
9. KMS key ARN and Tags are optional.
10. Click Create.

Create a CloudWatch Log Stream

1. In CloudWatch go to Logs > Log groups.
2. Search for the Log Group you created above and click its name to open it.
3. Open the Log streams tab.
4. Click Create log stream.
5. Enter the Log stream name, like netskope-ce-log-stream.
6. Click Create.

Create CloudWatch Logs Policy

1. Search for IAM in the search box, and from the left panel, click Policies.

2. Click Create Policy.

   

3. Click on the JSON tab, and enter the below-mentioned policy. Click on Next:  Tags, Click on Next: Review

   

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "NetskopeCECloudWatchLogs",
               "Effect": "Allow",
               "Action": [
                   "logs:DescribeLogGroups",
                   "logs:DescribeLogStreams",
                   "logs:CreateLogGroup",
                   "logs:CreateLogStream",
                   "logs:PutLogEvents"
               ],
               "Resource": "*"
           }
       ]
   }

4. Attach this policy to the user:

   • Go to IAM > Users and select the user for which you want to attach a policy. Click Add permissions and then click Add permissions options.

     

   • Select the Attach policies directly option under the Permissions options. Search for and select the policy created in the previous step.

     

   • Click Next and then click Add permissions. The Policy will be attached to the user.

     

Plugin Authentication Methods

IAM Role Anywhere Configuration

Prerequisites

The AWS Certificate Manager service is required to be enabled to authenticate the plugin using the AWS IAM Roles Anywhere Authentication Method.

Make sure you create the Private Certificate Authority, Trust Anchor, and Profile in the same region in which your AWS S3 Source Bucket resides.

Create a Policy

This Policy contains the required permissions for creating a Private CA Certificate(including Permissions for creating Trust Anchor and Profile) and using the IAM Roles Anywhere.

1. Go to Policy Generator and select IAM Policy as the policy type and generate a policy.

   • Select Type of Policy: IAM Policy
   • Effect: Allow
   • AWS Service: AWS Private Certificate Authority
   • Actions:
     1. CreateCertificateAuthority
     2. DescribeCertificateAuthority
     3. GetCertificate
     4. GetCertificateAuthorityCertificate
     5. GetCertificateAuthorityCsr
     6. ImportCertificateAuthorityCertificate
     7. IssueCertificate
     8. ListCertificateAuthorities
   • ARN: *
2. Click Add Statement.



• Select Type of Policy: IAM Policy
• Effect: Allow
• AWS Service: AWS Identity and Access Management (IAM)
• Actions:
  1. AttachRolePolicy
  2. CreateAccessKey
  3. CreateRole
  4. DeleteRole
  5. PassRole
• ARN: *
3. Click Add Statement.



• Select Type of Policy: IAM Policy
• Effect: Allow
• AWS Service: AWS Certificate Manager
• Actions:
  1. DescribeCertificate
  2. ExportCertificate
  3. GetCertificate
  4. ListCertificates
  5. ListTagsForCertificate
  6. RequestCertificate
• ARN: *
4. Click Add Statement.



• Select Type of Policy: IAM Policy
• Effect: Allow
• AWS Service: AWS Identity and Access Management Roles Anywhere
• Actions:
  1. CreateProfile
  2. CreateTrustAnchor
  3. GetProfile
  4. GetTrustAnchor
  5. ListProfiles
  6. ListTrustAnchors
• ARN: *
5. Click Add Statement.



6. Click Generate Policy.



7. Copy the Policy as it will be used in the next step for creating the policy required for creating the Private CA certificates.

8. Go to the AWS Console and select IAM from All Services. Click Policies in the left panel and then click Create Policy.

   

9. Copy the policy to the JSON tab. Click on Next: Tags and then click on Next: Review.

   

10. Enter the Name (like netskope-ce-rolesAnywhere-policy), and click Save Changes.

    

Create Private Certificate Authority

1. Log in to the AWS Console.

2. Search for Certificate Manager.

   

3. Click AWS Private CA.

4. Click Create a private CA.

   

5. For Mode Options, select General-purpose. 

6. For CA type options, select Root.

   

7. Enter an Organization (O).

   

8. For Key algorithm options, select RSA 2048.

   

   

9. Add tags if any (optional).

10. Enable the checkbox in the CA Permissions Options section.

11. Enable the checkbox in the Pricing section.

12. Click Create to create the CA certificate.

    

    

13. From Actions select Install.

    

14. Click Confirm and Install.

    

    

Create Trust Anchor

1. Search for IAM Service and go to Roles under Access management. Scroll down to Roles Anywhere and select Manage.

   

2. Click Create a Trust anchor.

   

3. Enter a Trust anchor name, like netskope-ce-trust-anchor.

   

4. Select AWS Certificate Manager Private CA (created in the previous steps) as the Certificate authority (CA) source.

5. Add tags if required.

6. Click Create a trust anchor.

   

   

7. Click on the created Trust Anchor and copy the Trust Anchor ARN

   

Create IAM Role

1. Go to IAM services in the AWS Console.

2. Click Role in the Access management submenu.

3. Click Create Role.

   

4. In the Trusted entity type, select Custom Trust Policy.

   

5. Replace the Custom trust Policy with the below given Trust Policy. This policy contains the permissions for using the Roles Anywhere service:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": [
                       "rolesanywhere.amazonaws.com"
                   ]
               },
               "Action": [
                   "sts:AssumeRole",
                   "sts:TagSession",
                   "sts:SetSourceIdentity"
               ]
           }
       ]
   }

   

6. Click Next.

7. In the Permissions policies, select the policy created previously.

   

8. Click Next.

9. Enter a Role name and Description for the role, like netskope-ce-roleAnywhere.

10. Click Create role.

    

11. Make a note of the Role ARN as this will be required in the Plugin configuration parameter Role ARN for the AWS IAM Roles Anywhere authentication method.

    

Create a Profile

1. Select Roles present under Access management.

2. Scroll down to Roles Anywhere and click Manage.

   

3. Expand the Setup steps.

4. Click Step 2: Configure roles.

5. Click Configure a profile.

   

6. Enter a Profile name, like netskope-ce-profile.

7. Select the role created previously (netskope-ce-roleAnywhere)

   

8. Remove the Inline Policy.

9. Click Create profile.

   

   

   

10. Click on the created Profile and copy the Profile ARN.

    

Request Private Certificate

1. Go to AWS Certificate Manager > Request certificate.

2. Select Request a private certificate.

   

3. Click Next.

4. Select the Certificate authority created previously.

   

5. Enter a domain name in the Fully qualified domain name field, like netskope-ce.com.

6. Select RSA 2048 for the Key algorithm.

   

7. Add tags if required.

8. Acknowledge the Certificate renewal permissions.

9. Click Request.

   

10. Go to List certificates from the navigation pane of AWS Certificate Manager.

11. Select the certificate created previously.

    

12. Click Export.

    

13. Enter the passphrase. Make a note of the passphrase as it will be required for the Configuration of the AWS S3 Plugin using the AWS IAM Roles Anywhere Authentication method.

14. Click Generate PEM Encoding.

    

15. Download all the Certificates as they won’t be visible again. For new certificates, you will need to Export it again.

    

    For More Info visit AWS IAM Role Anywhere

Deployed on AWS Configuration

Create a role

1. Go to IAM services in the AWS Console.

2. Click Create role.

   

3. Select the AWS Service.

4. Under Use case, select EC2.

5. Click Next.

   

6. Select the permission policy created in Create Policy.

7. Click Next.

   

8. Enter a Role Name, like netskope-ce-instance-role, and a Description.

9. Click Create Role.

   

   

Assign role to EC2 Instance

1. Open your EC2 instance console.

2. Click on Instances under Instances

   

   

3. Go to Action > Security > Modify IAM Role.

   

4. Select the Role that you created above in Create a role (netskope-ce-instance-role).

5. Click Add IAM role/Modify IAM Role. Note that both EC2 instance and Bucket should be on the same region.

   

Assign role to Fargate Instance

1. Open your CFN script.

2. Get the ExistingECSTaskRole parameter value if present.

   

3. Go to IAM > Roles.

4. Search for the ExistingECSTaskRole parameter value, or else search for NetskopeCloudExchangeTaskRole-<CFN name> and select the role.

   

5. Attach the Policy created previously to this role:

   • Click Add permission and attach policies.

     

   • Search and select the policy created previously (netskope-ce-s3-policy).

   • Click Add permissions.

     

Assign role to K8s Instance

1. Open your Role created for ServiceAccount while creating K8s instance.
2. Attach Policy created in Create Policy

Configure the AWS CloudWatch Plugin

1. Go to Settings > Plugin Store. Search for and select the AWS CloudWatch v1.0.0 (CLS) plugin.

   

2. Enter a plugin configuration name and make sure you have the AWS CloudWatch Default Mapping file selected if you want to use CEF format.

   

   To ingest data in JSON format, select format as ‘JSON’ under Basic Information.

3. Click Next and enter the Configuration Parameters:

   • Authentication Method: Select the method to be used for AWS client authentication.
     Deployed on AWS uses the IAM role attached to the AWS environment where Cloud Exchange runs.
     AWS IAM Roles Anywhere uses an X.509 certificate and private key to get temporary AWS credentials, and is meant for Cloud Exchange running outside AWS.
   • Private Key: PEM-encoded private key that matches the Certificate Body. It signs the IAM Roles Anywhere CreateSession request. Required for AWS IAM Roles Anywhere authentication.
   • Certificate Body: PEM-encoded X.509 end-entity certificate issued by the CA configured in the Trust Anchor. Required for AWS IAM Roles Anywhere authentication.
   • Password Phrase: Passphrase of the Private Key, if the key is encrypted. Required for AWS IAM Roles Anywhere authentication.
   • Profile ARN: ARN of the IAM Roles Anywhere profile. Format: arn:aws:rolesanywhere:{region}:{account-id}:profile/{profile-id}. Required for AWS IAM Roles Anywhere authentication.
   • Role ARN: ARN of the IAM role to be assumed. Format: arn:aws:iam::{account-id}:role/{role-name}. The role needs logs:PutLogEvents on the target log stream, and logs:CreateLogGroup and logs:CreateLogStream if the plugin should create them. Required for AWS IAM Roles Anywhere authentication.
   • Trust Anchor ARN: ARN of the IAM Roles Anywhere trust anchor. Format: arn:aws:rolesanywhere:{region}:{account-id}:trust-anchor/{anchor-id}. Required for AWS IAM Roles Anywhere authentication.
   • AWS CloudWatch Region Name: AWS region that holds the target CloudWatch log group. When AWS IAM Roles Anywhere is used, this region must match the region in the Profile ARN and the Trust Anchor ARN. Select Custom Region to enter a region that is not in the list.
   • AWS CloudWatch Custom Region: Only used when AWS CloudWatch Region Name is set to Custom Region; leave it empty otherwise. Any valid AWS region code of the log group, for a region that is not in the list, for example us-west-1. AWS IAM Roles Anywhere supports the aws, aws-cn and aws-us-gov partitions only, not the ISO or eusc- regions.
   • Log Group Name: Name of the CloudWatch log group the data is written to. The plugin creates the log group if it does not exist. It can be 1 to 512 characters long and can contain letters, digits and the characters . – _ / #.
   • Log Stream Name: Name of the log stream inside the log group. The plugin creates the log stream if it does not exist. It can be 1 to 512 characters long and must not contain : or *.
     

   

   

   

4. Click Save. Your plugin configuration will be available on the Log Shipper > Plugins page.

   

Configure a Log Shipper Business Rule for the AWS CloudWatch

1. Go to the Business Rule page.

2. By default, there is a business rule that filters all alerts and events. If you want to filter out any specific type of alert or event, click Create New Rule and configure a new business rule by adding the rule name and filter(s).

   

3. Click Save.

   

Configure Log Shipper Log Delivery for AWS CloudWatch

1. in Log Shipper, go to Log Delivery and click Add Log Delivery Configuration.
2. Select the Source plugin (CLS Netskope or any other source plugin), Destination plugin (CLS AWS CloudWatch), and business rule and click on save.
3. For WebTx select Source plugin(CLS AWS Netskope LogStreaming), and Destination plugin(CLS AWS CloudWatch).
4. For Logs sharing, select the Source plugin (CLS Cloud Exchange Logs), and Destination plugin (CLS AWS CloudWatch).
5. For BWAN events sharing, select the Source plugin (CLS Netskope BWAN), and Destination plugin (CLS AWS CloudWatch).
6. After the Log Delivery is added, the data will start to be pulled from the Netskope tenant or source platform, then transformed, and ingested into the AWS CloudWatch platform.

Validate the AWS CloudWatch Plugin

Validate the Pull

To validate the pulling of Events, Alerts, logs, BWAN events and WebTx from the Netskope tenant.

In Cloud Exchange, go to Settings > Logging. Search for the pulled logs.

Validate the Push

To validate the plugin workflow in Cloud Exchange:

Go to Logging and Search for ingested Events, Alerts, WebTx & Logs with the filter “message contains ingested”. The ingested logs will be filtered.

To validate the push in AWS CloudWatch:

Log in to the AWS Platform.

Search for CloudWatch and click on it.

Go to Logs > Log Analytics and enter a query like this:

SOURCE "arn:aws:logs:us-east-1:***********:log-group:<log_group_name>" START=-5m END=0s 
| fields @timestamp, @message
| sort @timestamp desc
| limit 10000
| filter @logStream like "<log_stream_name>"

Here are examples of ingested Alerts:

Here are examples of ingested Events:

This is how BWAN Events look like from the plugin to AWS CloudWatch:

This is how AWS CloudWatch for CE Logs look like from plugin to AWS CloudWatch:

This is how WebTx data looks like from plugin to AWS CloudWatch:

This is how Data looks like when shared in JSON from plugin to AWS CloudWatch (unparsed format):

Here is an example of ingested data in JSON format with custom mapping having only selected fields:

Troubleshooting the AWS CloudWatch Plugin

No AWS Credentials Found in the Environment

Error message:

No AWS Credentials were found in the environment. Deploy the plugin into an AWS environment or use AWS IAM Roles Anywhere authentication

Possible causes:

• The Deployed on AWS authentication method is selected, but no instance profile or IAM role is attached to the CE host.
• AWS IAM Roles Anywhere is misconfigured and the ambient credential chain is being used unintentionally.

What to do:

1. Verify that the CE host has an IAM instance profile with the required CloudWatch permissions attached (logs:PutLogEvents, logs:CreateLogGroup, logs:CreateLogStream, logs:DescribeLogGroups, logs:DescribeLogStreams), or switch the Authentication Method to AWS IAM Roles Anywhere.
2. If using IAM Roles Anywhere, confirm that the Private Key, Certificate Body, Profile ARN, Role ARN, and Trust Anchor ARN are correctly configured.

Access Denied for AWS IAM Roles Anywhere

Error message:

Access Denied. Verify the Profile ARN, Role ARN and Trust Anchor ARN provided in configuration parameters and the policies attached to the role

Possible causes:

• The ARNs provided in the configuration are mismatched or incorrect.
• The IAM role’s trust policy does not permit the Roles Anywhere service principal.
• The IAM role lacks the required CloudWatch Logs permissions.

What to do:

1. Verify that the Profile ARN, Role ARN, and Trust Anchor ARN are correct and reference existing resources in your AWS account.
2. Confirm that the IAM role’s trust policy grants the required permissions to the AWS IAM Roles Anywhere service.
3. Ensure the IAM role has the necessary CloudWatch Logs permissions: logs:PutLogEvents, logs:CreateLogGroup, logs:CreateLogStream, logs:DescribeLogGroups, and logs:DescribeLogStreams.

Resource Not Found for AWS IAM Roles Anywhere

Error message:

Resource not found. Verify the Profile ARN, Role ARN and Trust Anchor ARN provided in configuration parameters

Possible causes:

• One or more of the configured ARNs reference a non-existent profile, role, or trust anchor.
• The ARN format is incorrect.
• The ARNs belong to a different region than the one selected in AWS CloudWatch Region Name.

What to do:

1. Log in to the AWS console and verify that the profile, role, and trust anchor referenced by the configured ARNs exist and are active.
2. Ensure the ARN format is correct: arn:aws:rolesanywhere:{region}:{account-id}:profile/{profile-id}.
3. Confirm that the region in the Profile ARN and the Trust Anchor ARN matches the AWS CloudWatch Region Name configured in the plugin.

Invalid Private Key or Certificate Body

Error messages:

• Invalid Private Key provided. Private Key should be in a valid PEM format
• Invalid Certificate Body provided. Certificate Body must be in valid PEM format

Possible causes:

• The Private Key field does not contain a valid PEM-encoded private key.
• The Certificate Body field does not contain a valid PEM-encoded X.509 certificate.
• The Password Phrase is incorrect for an encrypted private key.

What to do:

1. Verify that the Private Key begins with —–BEGIN RSA PRIVATE KEY—– or —–BEGIN PRIVATE KEY—– and is complete.
2. Verify that the Certificate Body begins with —–BEGIN CERTIFICATE—– and is complete.
3. Confirm that the Password Phrase matches the passphrase used when the private key was generated, or leave it empty if the key is not encrypted.

CloudWatch Log Group Not Accessible

Error messages:

• AWS CloudWatch Log Group ‘{log_group}’ does not exist or is not accessible
• ResourceNotFoundException: The specified log group does not exist

Possible causes:

• The log group name configured in the plugin does not exist in the specified AWS region.
• The IAM credentials lack the required logs:DescribeLogGroups or logs:CreateLogGroup permissions.
• The log group exists in a different region than what is configured.

What to do:

1. Log in to the CloudWatch Logs console and verify that the log group exists in the configured region.
2. Ensure the IAM role or instance profile has logs:DescribeLogGroups and logs:CreateLogGroup permissions.
3. If the log group is in a different region, update the AWS Region field in the plugin configuration to match the actual region of the log group.

CloudWatch Log Group Region Mismatch

Error message:

AWS CloudWatch Log Group ‘{log_group}’ exists but is in region ‘{actual}’, not the configured region ‘{configured}’

Possible causes:

• The AWS Region configured in the plugin does not match the actual region where the log group resides.
• CloudWatch log groups are region-specific resources.

What to do:

1. Log in to the CloudWatch Logs console and confirm the actual region of the log group.
2. Update the AWS Region field in the plugin configuration to match the actual log group region.

Access Denied When Writing to CloudWatch Logs

Error message:

AccessDeniedException: User is not authorized to perform: logs:PutLogEvents on resource: {log_group}

Possible causes:

• The IAM role or instance profile is missing one or more required CloudWatch Logs permissions.
• A resource-based policy or Service Control Policy (SCP) is blocking the action.
• The log group uses AWS KMS encryption and the IAM role lacks the corresponding KMS key permissions.

What to do:

Verify that the IAM role has the following permissions on the target log group:

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents",
    "logs:DescribeLogStreams",
    "logs:DescribeLogGroups"
  ],
  "Resource": "*"
}

1. Check for any SCPs or permission boundaries in your AWS Organization that may be restricting CloudWatch Logs access.
2. If the log group is encrypted with a customer-managed AWS KMS key, ensure the IAM role also has kms:GenerateDataKey and kms:Decrypt permissions on that key.

CloudWatch Logs Throttling

Error message:

ThrottlingException: Rate exceeded for logs:PutLogEvents

Possible causes:

• The plugin is sending log events at a rate that exceeds the CloudWatch Logs service quota for PutLogEvents.
• Multiple CE instances are writing to the same log stream simultaneously.

What to do:

1. Review the CloudWatch Logs service quotas for your account and request an increase if needed.
2. Ensure that multiple CE instances are not writing to the same log stream at the same time; use unique log stream names per instance.

Could Not Reach AWS CloudWatch

If the user encounters the message “Could not reach AWS CloudWatch while {action}. Check the network connection, the proxy settings and the AWS CloudWatch Region Name” or “Error occurred while connecting to AWS CloudWatch”, it could be due to one of the following reasons:

• The CE host cannot reach the CloudWatch Logs endpoint for the configured region.
• The proxy configured in Cloud Exchange is incorrect or is blocking the request.
• The configured region does not exist, so the endpoint hostname does not resolve.

What to do:

1. Verify that the CE host can reach logs.{region}.amazonaws.com on port 443.
2. Review the proxy configuration in Cloud Exchange and confirm that the CloudWatch Logs endpoint is allowed through the firewall.
3. Confirm that the AWS CloudWatch Region Name (or AWS CloudWatch Custom Region) is the region where the log group resides.

Push Stopped After a Failed Batch

If the user encounters the message: Batch {n} of {total} failed, so the push stopped. {n} log(s) already reached AWS CloudWatch and were removed from the retry. {n} log(s) will be sent again by Cloud Exchange, it could be due to one of these reasons:

• A credential, permission, or network error occurred partway through a push.
• AWS throttled the PutLogEvents calls for the target log stream.

What to do:

1. Check the AWS credentials, the IAM permissions on the log group, and the network connection, using the specific error logged immediately before this message.
2. No action is needed for the logs themselves. Cloud Exchange automatically resends only the unsent remainder, so no log is lost or duplicated.
3. If the message recurs with a throttling error, request a PutLogEvents quota increase for the account, or spread the ingestion across additional log streams.
   

Known Behavior

• You may encounter escape characters in the ingested data due to several factors, such as accented characters (in English), characters of languages other than English, non-breaking spaces, newline characters, and other special formatting symbols.

  Example:

  <14>Apr 07 09:32:56 alltypes CEF:0|Netskope|Mock Netskope Tenant|NULL|application|NULL|Unknown|act=Download appcategory=Cloud Storage applicationType=nspolicy browser=unknown \\u4ed5\\u4e8b cci=89 ccl=high device=Other dst=ef82::1a12:1234:1b12 os=unknown requestClientApplication=Box sourceServiceName=Box src=ef82::1a12:1234:1b12 suser=support@netskope.com timestamp=1743736484

  Here, we had 2 Japanese characters that were ingested, which looked like “\\u4ed5\\u4e8b” in the above log.

• Ingested content may have missing fields/data if you set “Pull DLP Incident Forensics” field as “Yes” or the content of any of the fields is very large
  • We have observed that some of the fields are very large and they have length beyond the maximum length supported by the Netskope Cloud Exchange. Due to this, you may encounter the warning and you may observe that the ingested event is incomplete as rest of the values will be skipped.