Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Configure Alcide kAudit for AWS SecurityHub Integration

Using kAudit's UI or kAudit's ConfigMap & Secret Kubernetes objects, configure Configure Alcide kAudit to send its findings to SecurityHub using kAudit’s ConfigMap & Secret configuration option. See configuration guide here. Use the AWS credentials (User KeyPair or STS Role) prepared in the previous step.

k8s ConfigMaps & Secrets configuration

There are 3 types of integrations, according to the findings type: detections, selections (policy violation matches), and activity (raw audit entries)
The configuration of each integration type has 3 sections:

  • type (required): the integration type detections, selections or activity

  • target (required): aws-security-hub

  • data-filter (optional): a filter determining which processed results to send to the target(s).
    The filter's specifics depend on the integration type (i.e. the processed data to filter).

    • For detection findings this enables filtering on

      • category, detection type, incident and/or anomaly

      • etype, principal type associated with the detection, cluster, principal and/or resource

      • entity-no-match principal associated with the detection

    • For policy violation findings

      • rules-match filtering on the rule name

      • entity-no-match principal associated with the audit entry.

  • name (optional): a short name for the integration. Up to 15 alphanumeric, '_', '-' and ' ' characters.

See below an sample configuration for detections, selections (policy matches):




Values in a target configuration which are sensitive, like credentials or tokens, may be configured
by referencing an environment variable, a k8s secret or an entry in externally mounted secrets (e.g. from Vault), using the following syntax:

  • Sensitive value configuration with value 'foo' (note the mandatory prefix 'val-' in the field name), set up for example through Vault:
    val-my-key: foo

  • A configuration of field 'my-credentials' that needs to be initialised to the sensitive value in 'val-my-key' (note the mandatory prefix 'ref/' in the field name):
    ref/my-credentials: val-my-key

The relationship between these 2 fields is:
If 'val-my-key' field is present, field 'my-credentials' will get its value, otherwise it will not have a value.
Changes to the the value of 'val-my-key' will automatically update the referencing field (the one named 'my-credentials').

Here's an example for a partial configuration of integration, with externally-injected AWS credentials:

Code Block
- type: detections
    target-type: aws-security-hub
    aws-region: us-west-2
    aws-account-id: "111111111111"
    aws-access-key-id: my-key-id
    ref/aws-secret-access-key: val-x

And the sensitive value 'my-access-key' is injected into 'aws-secret-access-key' with a configuration like this:


View and Process Alcide kAudit Findings in AWS SecurityHub