- Created by Daniel Colon, last modified on Oct 26, 2021
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 2 Next »
📙 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 ThreadFix 3.0 System Requirements 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 |
---|---|
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 |
---|---|
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.
Create a folder named ‘values’ if one doesn’t exist.
mkdir -p myValues
Create a “eks.yaml” file:
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 thehelm install
command to apply the load balancer settings to the installation. Example:helm install tf denimgroup/threadfix -f myValues.yaml -f eks.yaml
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.
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
- No labels