What is an Elastic integration?

This integration is powered by Elastic Agent. Elastic Agent is a single, unified way to add monitoring for logs, metrics, and other types of data to a host. It can also protect hosts from security threats, query data from operating systems, forward data from remote services or hardware, and more. Refer to our documentation for a detailed comparison between Beats and Elastic Agent.

Prefer to use Beats for this use case? See Filebeat modules for logs or Metricbeat modules for metrics.

The Kubernetes Security Posture Management (KSPM) integration allows you to identify and remediate configuration risks in the various components that make up your Kubernetes cluster. It does this by evaluating the various components of your cluster against secure configuration guidelines, as defined by the Center for Internet Security (CIS), in order to identify configuration risks. When configuration risks are discovered, findings are generated that tell you exactly what is misconfigured and how you can remediate it. Please read through the KSPM documentation for an overview of KSPM.

We recommend reading through this entire readme before getting started with KSPM.

Getting started guide

For in-depth, step-by-step instructions to help you get started with KSPM, please read through our getting started guide.

Using KSPM

After you install this integration, the pages described in the table below will begin to get populated with security posture data. Please read the "Use Cases" section of the KSPM documentation for step-by-step instructions on how to use these pages to get insight into and improve the security posture of your Kubernetes clusters.

PageDescription
Posture Dashboard
The posture dashboard provides an overview of the security posture of all Kubernetes clusters monitored. You can access the posture dashboard via the dashboards section of the security solution. Please read the posture dashboard documentation to learn more.
Findings
Findings communicate the configuration risks discovered in your clusters. The findings page will always display the most up-to-date configuration risks discovered. You can access the findings page in the main navigation pane of the security solution. Please read the findings documentation to learn more.
Benchmark Rules
Benchmark rules are used to assess your Kubernetes clusters for secure configuration. You can access benchmark rules in the Manage section of the security solution under CLOUD SECURITY POSTURE. To learn more, please read the benchmark rules documentation

Compatibility

This integration is tested with Kubernetes 1.21.x and currently supports the security posture assessment of:

  1. Unmanaged/Vanilla Kubernetes clusters
  2. Amazon EKS clusters

This integration has not been tested on

  1. Amazon EKS on AWS Outposts

This integration does not currently support the security posture assessment of the managed kubernetes services below:

  1. Google GKE
  2. Azure AKS
  3. Red Hat Openshift
  4. Amazon EKS with AWS Fargate nodes

The integration supports elastic agent version 8.5 and above.

Integration Requirments

The KSPM integration requires access to node files, node processes, and the Kubernetes api-server therefore, it assumes the agent will be installed as a DaemonSet with the proper Roles and RoleBindings attached.

If deploying this integration on an Amazon EKS cluster, you will additionally need:

  • AWS Credentials to connect with your AWS account.
  • AWS Permissions to make sure the user you're using to connect has permission to share the relevant data.

AWS Credentials

AWS credentials are required for running the KSPM integration in your EKS clusters.

There are a few ways to provide AWS credentials:

  • Use access keys directly
  • Use temporary security credentials
  • Use a shared credentials file
  • Use an IAM role Amazon Resource Name (ARN)]

Use access keys directly

Access keys are long-term credentials for an IAM user or the AWS account root user. To use access keys as credentials, you need to provide:

  • Access Key ID: The first part of the access key.
  • Secret Access Key: The second part of the access key.

For more details refer to AWS Access Keys and Secret Access Keys.

Use temporary security credentials

Temporary security credentials can be configured in AWS to last for some period of time. They consist of an access key ID, a secret access key, and a security token, which is typically returned using GetSessionToken. IAM users with multi-factor authentication (MFA) enabled need to submit an MFA code while calling GetSessionToken. For more details refer to Temporary Security Credentials.

You can use AWS CLI to generate temporary credentials. For example, you would use sts get-session-token if you have MFA enabled:

aws sts get-session-token --serial-number arn:aws:iam::1234:mfa/your-email@example.com --duration-seconds 129600 --token-code 123456

Then, use the response to provide the following information to the KSPM integration:

  • Access Key ID: The first part of the access key.
  • Secret Access Key: The second part of the access key.
  • Session Token: A token is required when using temporary security credentials.

Because temporary security credentials are short-term, after they expire you will need to generate new ones and manually update the integration's configuration to continue posture evaluations. There will be downtime in coverage if the configuration is not updated with the new credentials before the old ones expire.

Use a shared credentials file

If you use different credentials for different tools or applications, you can use profiles to configure multiple access keys in the same configuration file. For more details, refer to Create Shared Credentials File.

Instead of providing the Access Key ID and Secret Access Key directly to the integration, you will provide the following values to reference the access keys in the shared credentials file:

  • Credential Profile Name: The profile name in the shared credentials file.
  • Shared Credential File: The directory of the shared credentials file.

Note: If you don't provide values for all keys, the integration will use these defaults:

  • If none of the Access Key ID, Secret Access Key, and ARN Role options are provided, then the integration will check for Credential Profile Name.
  • If there is no Credential Profile Name given, the integration will use the default profile.
  • If Shared Credential File is empty, the integration will use the default directory.
    • For Linux or Unix, the shared credentials file is located at ~/.aws/credentials.
  • The integration will use the EC2 attached role if no values are provided.

Use an IAM role Amazon Resource Name (ARN)

An IAM role ARN is an IAM identity you can create in your AWS account. You define the role's permissions. A role does not have standard long-term credentials such as passwords or access keys. Instead, when you assume a role, it provides you with temporary security credentials for your session. An IAM role's ARN can be used to specify which AWS IAM role to use to generate temporary credentials.. For more details refer to AssumeRole API documentation.

To use an IAM role's ARN, you need to provide either a credential profile or access keys along with the ARN Role option. ARN Role is used to specify which AWS IAM role to assume for generating temporary credentials.

Note: If ARN Role is given, the integration will check if access keys are given. If they are not given, the integration will check for a credential profile name. If neither is given, the integration will try to assume with the EC2 attached role.

AWS Permissions

Specific AWS permissions are required for an IAM user to make the necessary AWS API calls. To enable the KSPM integration to collect the configuration state of all necessary services, make sure to grant the following permissions:

  • ecr:GetRegistryPolicy,
  • eks:ListTagsForResource
  • elasticloadbalancing:DescribeTags
  • ecr-public:DescribeRegistries
  • ecr:DescribeRegistry
  • elasticloadbalancing:DescribeLoadBalancerPolicyTypes
  • ecr:ListImages
  • ecr-public:GetRepositoryPolicy
  • elasticloadbalancing:DescribeLoadBalancerAttributes
  • elasticloadbalancing:DescribeLoadBalancers
  • ecr-public:DescribeRepositories
  • eks:DescribeNodegroup
  • ecr:DescribeImages
  • elasticloadbalancing:DescribeLoadBalancerPolicies
  • ecr:DescribeRepositories
  • eks:DescribeCluster
  • eks:ListClusters
  • elasticloadbalancing:DescribeInstanceHealth
  • ecr:GetRepositoryPolicy

JSON object of an IAM Policy with the permissions above:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetRegistryPolicy",
                "eks:ListTagsForResource",
                "elasticloadbalancing:DescribeTags",
                "ecr-public:DescribeRegistries",
                "ecr:DescribeRegistry",
                "elasticloadbalancing:DescribeLoadBalancerPolicyTypes",
                "ecr:ListImages",
                "ecr-public:GetRepositoryPolicy",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeLoadBalancers",
                "ecr-public:DescribeRepositories",
                "eks:DescribeNodegroup",
                "ecr:DescribeImages",
                "elasticloadbalancing:DescribeLoadBalancerPolicies",
                "ecr:DescribeRepositories",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "elasticloadbalancing:DescribeInstanceHealth",
                "ecr:GetRepositoryPolicy"
            ],
            "Resource": "*"
        }
    ]
}

Leader election

To collect cluster level data (compared to node level information) the integration makes use of the leader election mechanism. This mechanism assures that the cluster-level data is collected by only one of the agents running as a part of the DaemonSet and not all.

Cluster level data example: List of the running pods. Node level data example: kubelet configuration.

Changelog

VersionDetails
1.0.8
Enhancement View pull request
Update screenshots and icon
1.0.7
Enhancement View pull request
Add KSPM to integration name
1.0.6
Enhancement View pull request
Removing the rule data yaml
1.0.5
Bug fix View pull request
Documentation bugfix
1.0.4
Enhancement View pull request
Updated mapping to include orchastrator.cluster.name.
1.0.3
Enhancement View pull request
Updated the readme to remove the broken internal link
1.0.2
Enhancement View pull request
Add AWS EKS documentation for KSPM
1.0.1
Enhancement View pull request
Add security category to package metadata.
1.0.0
Enhancement View pull request
Cloud Security Posture integration is now GA.
0.0.33
Enhancement View pull request
Remove unconfigurable default fields from hbs files
0.0.32
Enhancement View pull request
Add event property to finding, this event match the event spec of the ECS .
cycle_id mapping is removed as it is no longer reported by the Cloudbeat.
0.0.31
Enhancement View pull request
Store beat configuration file to be propagated to cloudbeat
0.0.30
Enhancement View pull request
Add AWS additional auth to KSPM integration
0.0.29
Enhancement View pull request
Update min age for delete to 180 days
0.0.28
Enhancement View pull request
Add ILM policy for the findings data stream
0.0.27
Enhancement View pull request
Update input types and var name to support runtime config
0.0.26
Enhancement View pull request
Version bump

Enhancement View pull request
Updates to KSPM Integration README
0.0.25
Bug fix View pull request
Remove unimplemented EKS rules from template
0.0.24
Enhancement View pull request
Updated release tag to beta
0.0.23
Bug fix View pull request
Fix rule id typo
0.0.22
Enhancement View pull request
Adjust findings data-stream mappings to fit ECS conventions

Enhancement View pull request
Turned off dynamic mappings of findings data-stream

Enhancement View pull request
Added default pipeline to findings data-stream
0.0.21
Enhancement View pull request
Update package display name
0.0.20
Enhancement View pull request
Remove Kibana configuration section from README
0.0.19
Enhancement View pull request
Adding EKS rule templates

Enhancement View pull request
Added date time field to index patterns

Enhancement View pull request
Update rule benchmark field to include an id
0.0.18
Enhancement View pull request
enhance integration to support eks
0.0.17
Enhancement View pull request
Refactored csp-rule-template metadata field to fit 8.4.0 schema
0.0.16
Enhancement View pull request
update resource id keyword mapping
0.0.15
Enhancement View pull request
update resource id mapping
0.0.14
Enhancement View pull request
Add mapping for rule id and resource id and revert Kibana version constrain
0.0.13
Enhancement View pull request
Update Kibana version constrain
0.0.12
Enhancement View pull request
Add new rule templates
0.0.11
Enhancement View pull request
Update elastic-agent deployment instructions
0.0.10
Enhancement View pull request
Update CSP rules configuration template
0.0.9
Enhancement View pull request
Update csp rule template
0.0.8
Enhancement View pull request
Send dataYaml (Rules Activation YAML) to cloudbeat
0.0.7
Enhancement View pull request
Add rule template assets
0.0.6
Enhancement View pull request
Update findings template asset
0.0.5
Enhancement View pull request
Add CSP rule template asset
0.0.4
Enhancement View pull request
Add latest findings data view
0.0.3
Enhancement View pull request
Change README
0.0.2
Enhancement View pull request
Change README
0.0.1
Enhancement View pull request
Initial draft of the package