As we reach the end of September 2024, ThreadFix version 3.x on-premises has officially reached its End-of-Life. Therefore, there is no longer support or updates for this version of the product. We have fully transitioned our product and development teams to focus ThreadFix SaaS and migrating all customers over from the on-premises versions. Our Customer Success and Support teams are here to help you in migrating to ThreadFix SaaS and maximizing the value you see from this improved offering from Coalfire. This is the next phase of ThreadFix and our team is looking forward to continuing to support you on this journey.

EKS

Owned by Daniel Colon
Last updated: Oct 29, 2021
4 min read

You will learn

How to Integrate ThreadFix with EKS clusters.

Prerequisites

Audience: IT Professional
Difficulty: Intermediate
Time needed: Approximately 15 minutes
Tools required: N/A

Worker Nodes

Currently, ThreadFix only supports running on EC2 worker nodes backed by EBS volumes. Fargate is not supported.

The sum of the worker nodes in the cluster must meet the requirements listed in the System Recommendations guide. Additionally, due to the requirements of individual pods, do not use worker nodes smaller than “xlarge”. ThreadFix currently recommends t3a.xlarge for worker nodes.

Networking

If the user does not wish to integrate the EKS cluster for ThreadFix into an existing AWS infrastructure and is using an AWS EKS provided CloudFormation template or eksctl, the user may use the default network provided by these tools. If choosing to use the default network, all of the external resources that ThreadFix depends on (e.g. SQLServer, Checkmarx, SSO) must be publicly accessible.

If intending to integrate the EKS cluster for ThreadFix into an existing AWS infrastructure, the user will need to setup the AWS VPC subnets that the EKS cluster will use prior to setting up the EKS cluster. The subnets must have the following properties:

  • All subnets in the same VPC, within the same block of IPs

  • Sufficient available IP addresses (minimum of 128)

  • Sufficient number of subnets (minimum of 2)

  • Internet and/or NAT gateways configured correctly

  • Routing tables with correct entries and a functional network

  • Tagging of subnets:

    • kubernetes.io/cluster/<cluster_name> tag set to either shared or owned

    • kubernetes.io/role/internal-elb tag set to 1 for private subnets

    • kubernetes.io/role/elb tag set to 1 for public subnets

What qualifies as “configured correctly” and “functional” depends on how ThreadFix will access external resources like the ThreadFix database, security applications (like Checkmarx, Fortify, etc), and supporting infrastructure (like LDAP or SMTP servers).

Additionally, ThreadFix recommends the cluster use “private-only” networking when installed.

Additional Resources

Load Balancing

Ingress into the ThreadFix application is controlled by a Kong API gateway which creates a load balancer that exposes the application. By default, Kubernetes "LoadBalancers" will not attach themselves to an AWS subnet. The subnet must be appropriately tagged.

If the ThreadFix application is not available and the load balancer is stuck in the state <pending>, it is likely that the load balancing settings need to be fixed.

Public Subnet

If the user wishes to publicly expose the ThreadFix installation, the user must tag the subnet so Kubernetes understands how to use those subnets for external load balancers. To tag a public subnet for use by EKS Elastic Load Balancer, navigate to the subnet in the AWS Console and add the following tag:

Key

Value

kubernetes.io/role/elb

1

Private Subnet

If the user does not wish to publicly expose the ThreadFix instance, the user will need to tag the private subnets so Kubernetes understands which subnets to use for internal load balancers. To tag a private subnet for use by EKS Elastic Load Balancer, navigate to the subnet in the AWS Console and add the following tag:

Key

Value

kubernetes.io/role/internal-elb

1

By default, load balancers will only run on public subnets. If the user wants the ThreadFix application to be only accessible from internal networks, the user will have to add an annotation to the Kong API gateway instructing Kubernetes to use the internal load balancer subnet from the previous step.

  1. Create a folder named ‘values’ if one doesn’t exist.

    mkdir -p myValues

     

  2. Create a “eks.yaml” file:

    echo "kong: proxy: annotations: service.beta.kubernetes.io/aws-load-balancer-internal: true" > myValues/eks.yaml

     

  3. Finish any other tasks from the Installation Checklist , then Install with Helm.

Additional Links

eksctl

eksctl is a command line utility for creating and managing EKS clusters. More information on how to setup and use eksctl can be found at https://eksctl.io/ . The following are sample configurations for setting up a minimum cluster capable of running ThreadFix. These are samples only, the specifics will vary depending on the user’s existing AWS infrastructure.

Sample configuration with no existing AWS infrastructure

The following configuration will create a basic cluster with default network settings. ThreadFix will be exposed publicly and will have no access to other resources on AWS.

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-1 region: us-east-2 nodeGroups: - name: ng-1 instanceType: t3a.xlarge desiredCapacity: 2

Sample configuration for existing VPC

This sample configuration is for a cluster in the EU north 1 (Stockholm) region with 3 existing private subnets. In this example, the subnets must be setup prior to installation with the properties described in the Networking section above.

 

 

www.threadfix.it | www.coalfire.com
Copyright © 2024 Coalfire. All rights reserved.

This Information Security Policy is CoalFire - Public: Distribution of this material is not limited.