Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Image RemovedImage Added

📙 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

Note

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 ThreadFix 3.0 System RequirementsRecommendations 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:

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:

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.

    Code Block
    mkdir -p myValues

  2. Create a “eks.yaml” file:

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

     

    Follow the External Database Setup Instructions (Kubernetes) guide and append -f eks.yaml to the helm install command to apply the load balancer settings to the installation. Example:

    Code Blockhelm install tf denimgroup/threadfix -f myValues.yaml -f eks.yaml
  3. Finish any other tasks from the Installation Checklist , then Install with Helm.

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.

Code Block
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.

Code Block
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster-4
  region: eu-north-1

vpc:
  subnets:
    private:
      eu-north-1a:
        id: "subnet-0b2512f8c6ae9bf30"
      eu-north-1b:
        id: "subnet-08cb9a2ed60394ce3"
      eu-north-1c:
        id: "subnet-00f71956cdec8f1dc"
nodeGroups:
  - name: ng-1
    instanceType: t3a.xlarge
    desiredCapacity: 3
    privateNetworking: true 

Table of Contents

Table of Contents