This section is coming soon.
Access Policies Overview
Access Policies Overview
Setting up Infrastructure
Requirements:
The requirements to setup control plane in each of the scenarios is as follows:- Billing and STS must be enabled for the AWS account.
- Please make sure you have enough quotas for GPU/Inferentia instances on the account depending on your usecase. You can check and increase quotas at AWS EC2 service quotas
- Please make sure you have created a certifcate for your domain in AWS Certificate Manager (ACM) and have the ARN of the certificate ready. This is required to setup TLS for the load balancer.
- Postgres database with the following requirements:
- Version: >= 13
- Instance Types:
db.t3.mediumordb.t4g.medium - Storage: 20GB of type
gp3with autoscale enabled to 30GB - Encryption: Enabled
- For PostgreSQL 17+: Set
force_sslparameter to0(off) in parameter group if you need to allow non-SSL connections (default is1) - Security Group: Ensure RDS security group allows inbound traffic from EKS node security groups
- S3 bucket to store the intermediate code while building the docker image.
- Egress Access to TrueFoundry:
- https://auth.truefoundry.com - Central Authentication Server for licensing and authentication
- https://login.truefoundry.com - Login UI for the central authentication server
- https://catalogue.truefoundry.com - Central Repository for fetching catalogues for latest model, their public cost, mcp servers, etc.
- https://analytics.truefoundry.com - Analytics Server for sending usage analytics to TrueFoundry.
- DNS: Domain for control plane and service endpoints. One endpoint to point to the control plane service (e.g., platform.example.com) and the other to point to the compute plane service (e.g., tfy.example.com/service1). The control-plane URL must be reachable from the compute-plane. The developers will need to access the TrueFoundry UI at the provided domain.
- We will need a certificate ARN (for the domain provided above) to attach to the loadbalancer so as to terminate TLS traffic at the load balancer. This will allow the services we deploy on the cluster to be accessed via HTTPS. We recommend using AWS Certificate Manager to add TLS to the load balancer. You can read the instructions in Step 2 below on how to create the certificate in AWS Certificate Manager.
- You need to have enough permissions on the AWS account to create the resources needed for the compute plane. Check this for more details. We usually recommend admin permission on the AWS account, but if you need the exact set of fine-grained permissions, you can check the list of permissions below:
- New VPC and New EKS Cluster
- Existing VPC and New EKS Cluster
- Existing EKS Cluster
- The new VPC should will have a CIDR range of /20 or larger, at least 2 availability zones and private subnets with CIDR
/24or larger. This is to ensure capacity for ~250 instances and 4096 pods. - If you want to use a smaller network range for your EKS cluster, TrueFoundry supports EKS custom networking as well.
- A NAT gateway will be provisioned to provide internet access to the private subnets.
- We should have egress access to
public.ecr.aws,quay.io,ghcr.io,tfy.jfrog.io,docker.io/natsio,nvcr.io,registry.k8s.ioso that we can download the docker images for argocd, nats, gpu operator, argo rollouts, argo workflows, istio, keda, etc.
Setting up control plane
TrueFoundry control plane infrastructure is provisioned using OpenTofu/Terraform. You can download the OpenTofu/Terraform code for your exact account by filling up your account details and downloading a script that can be executed on your local machine. To perform the below steps, you need to register an account on TrueFoundry and login to the platform.Enable Deployment Feature in the Platform (Optional)
- In the left hand navigation, go to
SettingsthenPlatform Feature VisibilityunderPreferences - Click on
Editbutton. Then enable the toggle forEnable Deployment

- Click on
Savebutton.

Choose to create a new cluster or attach an existing cluster
Clusters. Add the following value at the end of your URL &controlPlaneSetupEnabled=true. This will enable the control plane installation for you. You can click on Create New Cluster or Attach Existing Cluster depending on your use case. Read the requirements and if everything is satisfied, click on Continue.
Get Domain and Certificate ARN
*.services.example.com - we will be creating a DNS record with this later in Step 6. We recommend using AWS Certificate Manager (ACM) to create the certificate since it’s easier to manage and renew the certificates automatically. To generate a certificate ARN, please follow the steps below. If you are not using AWS Certificate Manager, you can skip this step and continue to the next step.Create the certificate in AWS Certificate Manager
Create the certificate in AWS Certificate Manager
- Navigate to AWS Certificate Manager in the AWS console
- Request a public certificate
- Specify your domain (e.g.,
*.services.example.com) - Choose DNS validation (recommended)
- Add the CNAME records provided by ACM to your DNS provider. Follow the official AWS guide for DNS validation. For detailed steps on adding CNAME records, see AWS documentation on DNS validation
- Wait for the certificate to change to “Active” status (this may take 30 minutes or longer)
- Copy the certificate ARN for the next step (format will be like:
arn:aws:acm:region:account:certificate/certificate-id)
Fill up the form to generate the opentofu/terraform code
Submit when done- Create New Cluster
- Attach Existing Cluster
Cluster Name- A name for your cluster.Region- The region where you want to create the cluster.Network Configuration- Choose betweenNew VPCorExisting VPCdepending on your use case.Authentication- This is how you are authenticated to AWS on your local machine. It’s used to configure OpenTofu/Terraform to authenticate with AWS.S3 Bucket for OpenTofu/Terraform State- OpenTofu/Terraform state will be stored in this bucket. It can be a preexisting bucket or a new bucket name. The new bucket will automatically be created by our script.Control Plane Configuration- Control plane URL and the database details. You can chose betweenPostgreSQL on kubernetesorManaged PostgreSQL (RDS)orExisting PostgreSQL configurationdepending on your use case.Load Balancer Configuration- This is to configure the load balancer for your cluster. You can choose betweenPublicorPrivateLoad Balancer, it defaults toPublic. You can also add certificate ARNs and domain names for the load balancer but these are optional.

Copy the curl command and execute it on your local machine
curl command to download and execute the script. The script will take care of installing the pre-requisites, downloading OpenTofu/Terraform code and running it on your local machine to create the cluster. This will take around 40-50 minutes to complete.
Create DNS Record
LoadBalancer in the istio-system namespace. You can run the following command to get the IP address.Attach the compute plane to the control plane
Clusters. Click on Attach Existing Cluster and fill in the details of the control plane cluster. The key fields to fill up here are:Cluster Name- The name of the cluster.Cluster Addons- Unselect all the addons as we have installed them while bringing up the control plane.Network Configuration- Networking configuration of the control plane cluster.Authentication- This is how you are authenticated to AWS on your local machine. It’s used to configure OpenTofu/Terraform to authenticate with AWS.S3 Bucket for OpenTofu/Terraform State- OpenTofu/Terraform state will be stored in this bucket. It can be a preexisting bucket or a new bucket name. You can use the same bucket that we used for the control plane and change the bucket key to be used for OpenTofu/Terraform state file.Platform Features- This is to decide which features like BlobStorage, ClusterIntegration, ParameterStore, DockerRegistry and SecretsManager will be enabled for your cluster. To read more on how these integrations are used in the platform, please refer to the platform features page.

Copy the curl command and execute it on your local machine
curl command to download and execute the script. The script will take care of installing the pre-requisites, downloading OpenTofu/Terraform code and running it on your local machine to create the cluster. This will take around 40-50 minutes to complete.
Verify the cluster is showing as connected in the platform
Enable the deployment of workloads on the cluster from the platform
- In the left hand navigation, go to
SettingsthenPlatform Feature VisibilityunderPreferences - Click on
Editbutton. Then enable the toggle forEnable Deployment - Click on
Savebutton.
Start deploying workloads to your cluster
FAQ
How do I tag all the AWS resources (cost-center, environment, team, etc.)?
How do I tag all the AWS resources (cost-center, environment, team, etc.)?
tags variable in the generated OpenTofu/Terraform code to a map of your tags:tofu plan (or terraform plan) first and confirm the diff is tag-only before applying.Tags flow through two layers so every AWS resource TrueFoundry provisions gets consistent labels:truefoundry-* audit tags without affecting your own tags, set:Can I use cert-manager to add TLS to the load balancer and not use AWS Certificate Manager?
Can I use cert-manager to add TLS to the load balancer and not use AWS Certificate Manager?
Can I use my own certificate and key files to add TLS to the load balancer?
Can I use my own certificate and key files to add TLS to the load balancer?
How to enable SSL for PostgreSQL connections?
How to enable SSL for PostgreSQL connections?
DB_SSL_MODE environment variable in your truefoundry-values.yaml.Supported DB_SSL_MODE values:no-verify)This is the simplest option for AWS RDS. It encrypts the connection but skips server certificate validation.require)This mode encrypts the connection and validates the server certificate. You must provide the AWS RDS CA bundle so the application can verify the RDS server certificate.Download the RDS CA bundle and create a Kubernetes Secret:truefoundry-values.yaml to mount the CA bundle and set DB_SSL_CA_PATH:How to enable and access control plane monitoring (Grafana)?
How to enable and access control plane monitoring (Grafana)?
truefoundry-values.yaml:- Replace
<your-truefoundry-control-plane-url>with your actual control plane domain (e.g.,app.example.com) and<tenant-name>with your TrueFoundry tenant name provided during onboarding. - Only users with the admin role can access this endpoint.
- Make sure to include the trailing
/at the end of the URL. - If you already have Prometheus or VictoriaLogs in your cluster, you can point the monitoring stack to them using
externalServicesinstead of installing new instances.
How to remove all AWS resources created with Terraform/OpenTofu?
How to remove all AWS resources created with Terraform/OpenTofu?
Connect to the EKS cluster
Delete LoadBalancer services
Delete Karpenter NodePools
From the folder with your generated OpenTofu/Terraform code
How to Harden the WAFv2 Web ACL using Terraform snippets?
How to Harden the WAFv2 Web ACL using Terraform snippets?
Overview
This section provides ready-to-use Terraform snippets forwaf.tf that remediate the following findings on an AWS WAFv2 Web ACL:waf.tf. Snippets that add a rule { ... } block are meant to be inserted inside the existing aws_wafv2_web_acl.this resource, alongside the other rules; snippets that define a full resource block can be dropped anywhere in the file.variables.tf: waf_app_name, waf_app_environment, waf_team, waf_it_owner_email, waf_geo_allowed_country_codes. See Required variables at the bottom of this page.Optional trusted IP set
Defines a reusable IP set of trusted addresses. It’s only created whenvar.waf_ip_allowlist is non-empty, and is referenced later by the allowlist rule. Skip this snippet if you don’t need an IP allowlist.Web ACL skeleton and default action (WAF-016)
This is the top-levelaws_wafv2_web_acl resource. All rule { ... } snippets below are inserted inside this resource’s body. The default action is kept as allow — non-matching traffic passes through, and the rules that follow block bad traffic explicitly.default_action { block {} }) alternative. Switching to deny-by-default requires an explicit allow rule that covers all trusted traffic first (otherwise you break the app), so it’s intentionally left as allow here. If you want to move to deny-by-default later, add a catch-all allow rule at priority 0 before flipping this.Managed rule: Known Bad Inputs
Blocks requests matching AWS’s curated list of known malicious request patterns (e.g. exploitation of Log4j, credential stuffing patterns). Set at priority0.Managed rule: SQL Injection Rule Set
Applies AWS’s managed SQL injection detection ruleset across the request. Set at priority1.Managed rule: Amazon IP Reputation List
Blocks traffic from IP addresses that AWS’s threat intelligence has flagged as sources of botnets, scanners, or other malicious activity. Set at priority2.Managed rule: Common Rule Set (OWASP baseline)
Applies AWS’s Core Rule Set (broad OWASP-style protections). Two rule-level overrides are included:SizeRestrictions_BODY is set to allow (so large but legitimate request bodies aren’t blocked), and NoUserAgent_HEADER is set to count (monitor requests without a User-Agent header, rather than blocking them). Set at priority 3.Rate limiting on /api/ traffic (Custom-Rule-85)
Remediates the Critical finding by changing the previous count {} action to block {}, and scoping the rate limit to requests whose path starts with /api/ — so UI, health check, and static asset traffic isn’t rate-limited alongside API calls. Set at priority 4.Trusted IP allowlist rule
Allows traffic from the IP set defined earlier to bypass the rules that follow it. Only rendered when the allowlist IP set was created. Set at priority5.Managed rule: Anonymous IP List (WAF-009)
Blocks requests originating from VPNs, Tor exit nodes, proxies, and hosting providers — sources commonly used to mask the true origin of malicious traffic. Set at priority6.Standalone SQL injection block rule (Custom-Rule-85)
A dedicated SQLi detection rule scoped to the request body, independent of the managed SQLi rule set above. Deployed incount {} (monitor-only) mode at priority 7 — check CloudWatch metrics and sampled requests for false positives before switching the action to block {}.Standalone XSS block rule (Custom-Rule-85)
A dedicated cross-site scripting detection rule scoped to all query string arguments. Also deployed incount {} (monitor-only) mode at priority 8 — switch to block {} once validated against real traffic.Geo-location restriction (Custom-Rule-84)
Blocks any request whose source country is not in the approved list, using anot_statement wrapped around a geo_match_statement. Configure the approved countries via var.waf_geo_allowed_country_codes. Set at priority 9.Data protection / field redaction (WAF-021)
Substitutes the values of sensitive request headers —authorization, cookie, x-api-key, x-auth-token — before they’re written to any WAF logging destination (CloudWatch Logs, sampled requests, etc.). This block goes directly inside aws_wafv2_web_acl.this, alongside the default_action and rules.Logging (WAF-013, unchanged)
Creates the CloudWatch log group and logging configuration for the Web ACL. This was already compliant and is included here unchanged for completeness — the log group name must be prefixed withaws-waf-logs-, which AWS enforces.Associating the Web ACL with an ALB
Associates the Web ACL with an Application Load Balancer. Only needed if the ALB was created outside of the AWS Load Balancer Controller — pass its ARN viavar.waf_associate_alb_arn; otherwise leave that variable empty and skip this snippet.Required variables
Add these tovariables.tf if they don’t already exist (used for Custom-Rule-37 mandatory ownership/application tagging, and the geo-block rule):waf_app_namewaf_app_environmentwaf_teamwaf_it_owner_emailwaf_geo_allowed_country_codes
local.waf_required_tags local referenced throughout the snippets above, and applied to every WAF resource.