AWS Marketplace

Mastering runtime security on Amazon EKS with Upwind’s powerful Amazon EKS add-on

AWS Marketplace add-ons for Amazon Elastic Kubernetes Service (Amazon EKS) give EKS customers the ability to deploy third-party software on their clusters as an add-on, streamlining procurement and deployment. This makes it easier for Amazon Web Services (AWS) customers to find, deploy, and manage software using Amazon EKS add-ons.

Upwind is a runtime-powered cloud security platform that redefines cloud security, speed, visibility, and actionability. It quickly identifies critical risks, finds root causes faster, and stops attacks in real-time. Upwind helps accelerate productivity and empowers development, security, and DevOps teams to innovate securely and efficiently.

As an independent software vendor (ISV) ) approved by AWS, you can deploy Upwind on EKS clusters using the same methods as native AWS services. This can be done manually through the Amazon EKS console, APIs, Command Line Interface (CLI) , or through infrastructure as code (IaC) with services such as AWS CloudFormation and Terraform.

This integration lets you automatically deploy Upwind to existing and new EKS clusters without a lengthy procurement process, bypassing the often months-long process of discovery, deployment, and management.

Prerequisites

You need the following to complete the steps in this post:

Solution overview

In this post we will show you how to deploy Upwind’s cloud security platform as an EKS add-on to protect your Kubernetes environment with advanced security capabilities including complete visibility, threat detection, and automated response.

The Upwind Cloud Security Platform offers several capabilities that you can use for advanced Amazon EKS protection.

These include:

  • Complete EKS inventory – Discover the complete EKS inventory, including compute, storage, running images, and running packages including package dependencies.
  • Monitoring of EKS resource communication – View real-time and over-time EKS topology map and network communication including in cluster, in account, communication with AWS services, and from or to the internet.
  • Posture management – Including misconfigurations, compliance, exposed secrets, malware, and external exposures.
  • Real-time threat detection and response for EKS – Detect threats in real time and respond to them at the process, network, file, or system-call level.
  • Vulnerability management for EKS – Discover all vulnerabilities in EKS and prioritize them based on real environmental variables.
  • API security for EKS – Discover and catalog all APIs for EKS resources, monitor API traffic and requests over time, and discover all your API vulnerabilities.
  • Secure EKS identities – View and secure all EKS identities, including AWS Identity and Access Management (IAM) roles, execution roles, cross-account roles, and service accounts.

The following diagram shows the Upwind architecture on Amazon EKS, including the following components in a customer Kubernetes cluster: Kubernetes API sends requests to the Upwind Cluster Manager, which then sends requests to the UpwindOperator and Upwind eBPF sensor inside the node.

The Kubernetes API also sends requests to EKS audit logs on Amazon CloudWatch, which sends data to the Upwind Log ExporterLambda. The AWS account’s customer Kubernetes cluster (Upwind Cluster Manager, Upwind Operator, and Upwind eBPF sensor), EKS audit logs (CloudWatch and Upwind Log ExporterLambda), and customer virtual machine (VM) (Upwind eBPF sensor) all send metrics reporting to the Upwind Cloud Security Platform. In addition to the data from continuous integration and continuous delivery (CI/CD) and cloud APIs.

   Figure 1: Upwind architecture on Amazon EKS

The solution follows these steps:

  1. Amazon EKS users discover the Upwind EKS add-on.
  2. The EKS user subscribes to the Upwind EKS add-on.
  3. The EKS addon will check the subscription.
  4. The EKS add-on deploys the Upwind components.
  5. The EKS has successful communication with the Upwind SaaS.

The following diagram shows these steps.

Figure 2. Showing the steps for an EKS user to deploy the Upwind EKS add-on

Solution walkthrough

After you enable the Upwind Amazon EKS add-on, Upwind can start protecting all existing and new EKS clusters across your AWS accounts.

The Upwind EKS add-on uses a lightweight, high performance eBPF sensor, installed on Kubernetes clusters.

The Amazon EKS add-on capability simplifies Upwind deployment:

  • Existing clusters – Deploy Upwind on all EKS clusters with the click of a button.
  • New clusters – Customers can freely launch new EKS clusters, with Upwind as a built-in installation.

Both options help customers to easily deploy and operate Upwind at scale with the click of a button, protecting all existing and future container infrastructure.

Deploying the Upwind EKS add-on through AWS CLI

To deploy the Upwind EKS add-on using the AWS CLI, follow these steps:

1.In AWS CLI, describe the add-on versions for Upwind:

aws eks describe-addon-versions --addon-name Upwind-security_upwind-operator

2. Create the add-on by entering the following command, replacing my-cluster  with the cluster name:

aws eks create-addon \ --addon-name upwind-security_upwind-operator \ --cluster-name <AWS_EKS_CLUSTER_NAME>
HTML

Example output:

{
  "addon": {
    "addonName": "upwind-security_upwind-operator",
    "clusterName": "<AWS_EKS_CLUSTER_NAME>",
    "status": "CREATING",
    "addonVersion": "v0.3.0-eksbuild.1",
    "health": {
      "issues": []
    },
    "addonArn": "arn:aws:eks:<AWS_REGION>:111122223333:addon/<AWS_EKS_CLUSTER_NAME>/upwind-security_upwind-operator/...",
    "createdAt": "2024-01-01T00:00:00.000000+02:00",
    "modifiedAt": "2024-01-01T00:00:00.000000+02:00",
    "tags": {}
  }
}
HTML

3. Check the status of the add-on:

aws eks describe-addon \
--addon-name upwind-security_upwind-operator \
--cluster-name <AWS_EKS_CLUSTER_NAME>
HTML

Expected output:

aws eks describe-addon \
--addon-name upwind-security_upwind-operator \
--cluster-name <AWS_EKS_CLUSTER_NAME>
HTML

The deployment is complete when the status is active.

Evaluating Upwind’s network telemetry capabilities

To simulate a microservice application, deploy this sample webstore application.

Use kubectlto run the application:

kubectl apply -f https://raw.githubusercontent.com/aws-containers/retail-store-sample-app/main/dist/kubernetes/deploy.yaml
kubectl wait --for=condition=available deployments --all
HTML

View AWS resource communication with network telemetry

Using eBPF-powered networking visibility and AWS APIs, Upwind correlates which workloads and applications are talking to AWS services and features, such as Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache, Amazon Simple Storage Service (Amazon S3) buckets, AWS Lambda functions, Amazon Simple Email Service (Amazon SES), Amazon Simple Queue Service (Amazon SQS), Amazon OpenSearch Service, and more. This ability to view end-to-end resource communication gives customers granular visibility into their network topology.

By collecting this networking, process, and application information, Upwind can correlate process execution behavior with malicious activities, map and analyze network flows for topology understanding and suspicious behavior, and detect access to sensitive data. Moreover, this includes extensive analysis of the network protocol (layer 3), the IP addresses (layer 4), APIs, and DNSs (layer 7) to resolve the internal IP addresses and AWS elastic network interfaces information. This is used for AWS services, such as Amazon RDS, AWS Lambda, Amazon SQS, Amazon SES, Amazon ElastiCache, Amazon DynamoDB, the S3 buckets, Amazon API Gateway connections, and more.

To use these capabilities, open the Upwind console after deploying the Upwind EKS add-on. Under the Inventory module, select the Map tab. To expand the map, select the AWS icon.

Figure 3: Upwind’s real-time Amazon EKS topology map showing communication by layers 3, 4, and 7 in cluster, in account, and to the internet

Upwind enriches this information even further by combining DNS and API endpoint data with process-level visibility to show where requests came from and which AWS service is involved in the path. This integrates with cloud APIs such as AWS CloudTrail, EKS audit logs, control plane logs, and more.

Upwind then correlates all this runtime data with software development lifecycle (SDLC) context through version control systems and CI/CD pipeline integrations, providing end-to-end visibility and protection from runtime to build time.

To use SDLC context within the Upwind platform, integrate with your current CI/CD and version control tooling. For additional information, visit the Upwind Documentation Center and visit the sections on setting up integrations with continuous integration, continuous delivery, and version control tooling.

For Upwind users who choose not to integrate with CI/CD or version control tooling, you’ll still be able to view continuous delivery information and confirm when images were first discovered by the Upwind platform. To view this information, navigate to the Inventory module and select the Images & CI/CD tab.

Figure 4: Upwind’s Images tab shows the Upwind icon under Build time, indicating that the image was discovered by Upwind upon deployment

Upwind will automatically discover an image when it’s released to a production environment, even without additional CI/CD or version control integrations. This is indicated by the Upwind icon under the Build time column, showing that Upwind discovered the image within a production environment. To view additional continuous delivery information, select the name of a specific image, after which you’ll notice a side pane with the image overview and the option to choose the Continuous delivery tab. This will display continuous delivery information and version change information, including delivery time as discovered by the Upwind platform upon deployment.

Figure 5: Upwind users will notice a side pane after selecting an image name in the Images & CI/CD tab. This image was discovered by Upwind without any CI/CD or version control integrations, showing Upwind’s discovery of every new image version that has been released to the user’s production environment.

Real-time Kubernetes threat detection and response

In addition to end-to-end network and application-level visibility, Upwind’s EKS add-on provides real-time Kubernetes threat detection and response, allowing Amazon EKS customers to identify malicious activity in their environment and provide a surgical response. The response can come in different levels, such as:

  • Process level – The ability to target and terminate a specific malicious process
  • Network level – The ability to stop network-level attacks such as data exfiltration
  • System call level – The ability to block a ransomware attack by blocking unusual file encryption system calls

Evaluating Upwind’s response capabilities

To demonstrate Upwind’s network telemetry and real-time response capabilities, the following instructions show how to deploy an Nginx-based container configured to run a reverse shell for testing purposes in a Kubernetes cluster. This container listens on port 4444 and can be used to evaluate Upwind’s Response feature. The reverse shell will trigger Upwind’s Reverse Shell detection policy, and the following steps walk through how to apply a response.

You can deploy the Nginx reverse shell container directly using the following kubectlcommand:

kubectl apply -f https://upwind-templates.s3.us-east-2.amazonaws.com/nginx-reverse-shell.yaml

This command will create a deployment in your Kubernetes cluster based on the configuration provided at the specified URL.

Verify the deployment

To confirm the deployment was successful, check the status:

kubectl get deployments

Confirm that the nginx-reverse-shell deployment is listed, and the desired number of replicas are running (1/1).

Viewing the event and applying the response

On the Upwind console, under Threat -> Detection, a new detection identified as, “A container is executing a reverse shell,” will be generated. The image will take time to download, schedule, and start all network connections, and the event may take 1–2 minutes before it’s visible in the Upwind platform. When clicking on this Event, you’ll observe a button with the ability to Respond to the event.

Follow the prompts to activate the response and apply an automated response policy to continue to apply for all future processes within the same deployment.

Verify the response

After selecting Apply, you can verify that the process was terminated successfully by checking the logs of the pod:

kubectl logs $(kubectl get pod -l app=nginx-reverse-shell -o jsonpath="{.items[0].metadata.name}")

Review the Upwind console’s response to view the process action on the timeline, as shown in the following screenshot.

View threat detection and response for AWS resources

The Upwind sensor uses multiple intelligent threat detection feeds to identify and respond to malicious activities in containers, such as abnormal data access, lateral movements, and privilege escalations, as well as behavioral analysis of workloads profiles and baselines and detection of abnormal behavior.

To view threat detections and the response options for AWS resources, open the Upwind console and choose the Threats tab.

Figure 6: Upwind’s Threats module displays detections over time and ranks individual detections by severity, as determined by real-time environmental context

Under the Detections tab, you can observe a timeline of all threat detections, an overview of all active threat detections and their severity, and a list of individual detections sorted by threat, by resource, by account, or by time. To view additional context about a threat, select the policy name and then the resource name. You’ll observe a side pane with additional information about the resource and the threats detected in relation to it.

Figure 7: Upwind’s Threats module displays an individual resource and an overview of the threat detections related to it

To respond to a threat and block it at the process level, choose Respond. You’ll be given an option to block the process and the option to create a preventative policy that will automatically block any future processes that attempt to run for a set period of time.

Cleanup

After evaluating Upwind’s real-time network topology and threat detection and response capabilities, remove the Upwind EKS add-on to avoid any incidental charges. To do so, enter the following command:

aws eks delete-addon \
  --cluster-name <my-cluster> \
  --addon-name Upwind-security_upwind-operator
HTML

Customer success story

Yotpo, an early Upwind customer that runs multiple EKS clusters, says that using Upwind as an EKS add-on simplified their onboarding process, allowing them to scale with speed and security.

“Using the Upwind EKS add-on made it extremely simple for us to discover and provide full-coverage protection for all of our EKS clusters. We use Upwind for Kubernetes security as well as additional DevOps insights and context, resulting in better communication and collaboration for our dev, sec, and ops teams in scaling and protecting our AWS Cloud infrastructure,” said Gadi Rapaport, Global IT Director at Yotpo.

Conclusion

Use Upwind’s EKS add-on to instantly start protecting your existing EKS clusters and bake in real-time security to your future clusters with Kubernetes threat detection and response. For more information, refer to the following references:

  • To learn more about Amazon EKS add-ons in AWS Marketplace, read the AWS Blog
  • To try out the new add-ons experience, visit AWS Marketplace.

If you’re an AWS Partner, start using AWS Marketplace and Amazon EKS add-ons to provide a better experience for your customers. To onboard your software to AWS Marketplace, visit Getting started as a seller and Container-based products  in the AWS documentation. If you have any questions, email aws-mp-eks@amazon.com.

About the Authors

Denise Ashur

Denise Ashur is head of product marketing at Upwind and has over a decade of product marketing experience. Focusing on Kubernetes and cloud-based technologies, she breaks down technical subjects to support cloud-based advancements and spotlight emerging cloud security trends.

Tomer Hadassi

Tomer Hadassi is part of the founding team at Upwind, where he currently serves as Chief of Staff and helps lead organizational growth and cross-team coordination globally. Before joining Upwind, Tomer served as Head of Field Engineering at Spot.io, and he later served as Head of Strategy after it was acquired by NetApp for $450 million in 2020.

Elamaran Shamugam

Elamaran (Ela) Shanmugam is a senior container specialist solutions architect at Amazon Web Services with over 15 years of experience in enterprise systems and infrastructure. Ela specializes in container technologies, app modernization, observability, and machine learning, helping AWS customers and partners design scalable and secure container workloads. Based in Tampa, Florida, Ela contributes to open source projects, speaks at events, mentors, and creates technical content. You can find Ela on Twitter @IamElaShan and on GitHub.

Wendy (Sikirat) Jabitta

Wendy Sikirat Jabitta is a Senior Technical Business Development Manager at Amazon Web Services (AWS). She works with AWS technology partners to develop joint solutions, drive go-to-market strategies, and accelerate customer adoption. Outside of work, Wendy is passionate about wellness and enjoys competing in fitness challenges.