Advanced Cluster Settings

Porter exposes advanced cluster configuration options for customers with specific compliance, security, or networking requirements. These settings are available on the Advanced tab of your cluster settings for AWS, GCP, and Azure clusters.

AWS
GCP
Azure

Networking

Private cluster

When Private cluster is enabled, Porter provisions the EKS cluster with both public and private API server endpoint access, and restricts the public endpoint to an IP allowlist containing Porter’s control-plane IPs plus any customer CIDRs you add. This configuration is SOC2 / HIPAA compliant.

Setting	Description
Private cluster	Restricts the EKS API server’s public endpoint to an IP allowlist (Porter’s IPs plus any customer-supplied CIDRs). The private endpoint inside your VPC remains reachable from VPC-attached resources.
CIDR allowlist	Additional CIDR ranges (beyond Porter’s required IPs) that may reach the public endpoint.

Porter intentionally does not enable EKS “private-only” endpoint mode. Private-only forces every control-plane call — including Porter’s — through a VPN or VPC-peered path, which adds operational complexity and has historically caused outages for customers. Public + private with a tight IP allowlist meets the same compliance requirements and is significantly more reliable.

The Tailscale integration is a separate layer that carries traffic for porter kubectl and porter helm commands; it does not control how the EKS API server endpoint itself is exposed.

Load balancer

Configure the type of load balancer used for your cluster’s ingress. Changing this setting causes downtime while the load balancer is recreated.

Type	Description
NLB	Network Load Balancer — operates at Layer 4, routes TCP/UDP traffic, and provides ultra-low latency and high throughput.
ALB	Application Load Balancer — operates at Layer 7, routes HTTP/HTTPS traffic, and supports wildcard domains, ACM certificates, and WAFv2.

When ALB is selected, the following additional settings become available. See Custom domains with ALB for end-to-end setup instructions.

Setting	Description
Wildcard domains	Domains to issue ACM certificates for. Do not include the `.` prefix — Porter creates a SAN for `.<domain>` automatically. Comma-separate multiple domains.
IP allow list	Comma-separated list of CIDR ranges (e.g. `160.72.72.58/32,160.72.72.59/32`) permitted to reach the ALB.
Certificate ARNs	Existing ACM certificate ARNs to attach to the ALB.
AWS tags	Key/value tags applied to the ALB and related AWS resources.
WAFv2 enabled	Attaches a Regional WAFv2 web ACL to the ALB.
WAFv2 ARN	ARN of the Regional WAFv2 web ACL to attach. Only Regional WAFv2 is supported.

Do not use this setting. Use the Application load balancer setting that follows. Porter continues to support this setting on clusters that already use it.

Application load balancer

This setting adds one more public ALB to the cluster. It does not replace the default load balancer of the cluster. Because each service selects the load balancer that serves it, you can move the domains one at a time.

Setting	Description
Add application load balancer	Porter provisions a public layer 7 ALB in front of the cluster. The ALB listens on port 80 and port 443. The ALB terminates TLS at the edge. The ALB does not redirect HTTP traffic to HTTPS.
Root domains	The domains that this load balancer serves. Write one domain in each row, for example `alb.example.com`. Porter requests one ACM certificate for each root domain. Each certificate includes `*.<root>`, so the load balancer can serve all subdomains of that root domain. You must give a minimum of one root domain.
DNS provider	The provider that hosts the root domains. ACM uses this provider to validate the certificate. Cloudflare and AWS Route53 are currently supported.
DNS credentials	API token for Cloudflare. This field shows only when the DNS provider is Cloudflare. The token must have permission to read the zone that serves each root domain, and to create DNS records in that zone. Route53 needs no credentials, because Porter writes the records with the AWS account of the cluster.
Web application firewall	Porter provisions a Regional WAFv2 web ACL with a Porter-managed name (`porter-alb-waf-<hash>`). Porter then associates the web ACL with the ALB.

Certificate validation

ACM validates the certificate with DNS records, which are automatically managed for both DNS providers.If you use Route53, each root domain must have a public hosted zone in the AWS account of the cluster.If you use Cloudflare, you must upload an API token in the DNS credentials field. The token must have read and write permissions for the zone that serves each root domain.Validation records are required to renew the certificate after it has been provisioned.

Point DNS at the ALB

The ALB has its own address, so the records that point at the default load balancer do not change. For each root domain, point a wildcard record at the ALB, for example *.alb.example.com. On AWS, this address is a hostname, so you must use a CNAME record or a Route53 alias record. After Porter provisions the ALB, the address shows in the Custom domains area of the Networking tab of a service.

Web application firewall

Porter creates the web ACL with a default action of allow. Porter does not add rules. Add managed rule groups, rate-based rules, or IP sets in the AWS WAF console. Porter does not change these rules. Porter supports only Regional WAFv2.If you turn off this setting, Porter detaches the web ACL but does not delete it, so your rules remain if you turn on the setting again.

Route a service through the ALB

After the ALB serves traffic, the Networking tab of each web service shows a Public ALB option next to Public LB. In porter.yaml, use loadBalancers:

services:
  - name: api
    type: web
    loadBalancers:
      - public_alb
    domains:
      - name: api.alb.example.com

The domains of a service that the ALB serves must be below a registered root domain. When you change the load balancer of a service, the change takes effect at the next deployment. Move the DNS record of the domain to the address of the new load balancer.

Private load balancer

In addition to the default public cluster load balancer, you can provision an internal load balancer that only accepts traffic from inside your VPC (or networks peered to it). Use this when you want to expose services to internal clients, for example an internal admin tool, a service consumed only by other VPCs, or a workload that must not be reachable from the public internet.

Setting	Description
Add private load balancer	Provisions a private NLB alongside the existing public cluster load balancer. Only NLB private load balancers are supported.

Once enabled, you must configure a DNS provider so Porter can issue and renew TLS certificates for ingress hostnames attached to the private load balancer. The following DNS providers are supported: Cloudflare and AWS Route53.

We recommend serving private ingress from a dedicated internal zone (for example, internal.example.com) rather than a zone that also serves production domains. This avoids record conflicts with production DNS and keeps DNS access scoped to internal hostnames only.If that isn’t practical, you can still keep credentials off your production zone. See Delegating certificate validation below.

Cloudflare
Route53

Setting	Description
DNS credentials	API token for Cloudflare. The token must have permission to create and delete `TXT` records on the zones used by your private ingress hostnames.

Save the credentials before updating the cluster. You can rotate the token later with Edit credentials, or remove the integration entirely with Remove. Removing credentials stops certificate issuance and renewal for private load balancer ingress.

When the cluster is on AWS, you can use Route53 instead of Cloudflare. Porter authenticates to Route53 through an EKS Pod Identity scoped to a single hosted zone, so no API tokens are stored.

Setting	Description
Route53 domain	The DNS zone the private ingress serves certificates for (for example, `internal.example.com`). At install time, Porter resolves the matching public Route53 hosted zone in the same AWS account and provisions a cert-manager pod identity scoped to that zone.

The domain must already exist as a public hosted zone in the cluster’s AWS account, and the zone name must match the domain exactly. If only a parent zone is present (for example, example.com for a domain of internal.example.com), Porter cannot issue certificates for it, and the domain requires its own dedicated hosted zone.

Delegating certificate validation

On AWS Route53 this isn’t necessary. Create a dedicated hosted zone for the subdomain and provide it as the Route53 domain (the Route53 option above); Porter scopes access to that zone directly.

1. Add the delegation CNAME records. Pick a low-privilege zone to hold the validation records (for example, acme.example-internal.com). In the zone that hosts your private hostnames, add a CNAME for each validation record, pointing at a record in the delegated zone:

_acme-challenge.app.internal.example.com.  CNAME  _acme-challenge.acme.example-internal.com.

2. Scope the credentials to the delegated zone. Create an API token scoped to the delegated zone only, with:

Zone.DNS → Edit
Zone.Zone → Read

The token does not need any access to your production zone.3. Verify the delegation. Confirm the CNAME resolves publicly:

dig +short CNAME _acme-challenge.app.internal.example.com
# expected: _acme-challenge.acme.example-internal.com.

Certificates are issued automatically when you attach a hostname to a service through its load balancer config. Porter then publishes each validation record into the delegated zone through the CNAME.If you need help setting this up, reach out to Porter support.

Observability

CloudWatch control plane logs

Configure which EKS cluster control plane log types are sent to AWS CloudWatch. These logs help with debugging, auditing, and monitoring your cluster’s control plane components.

Log Type	Description
API Server logs	Logs from the Kubernetes API server, useful for debugging API requests
Audit logs	Records of individual users, administrators, or system components that have affected the cluster
Authenticator logs	Logs from the AWS IAM authenticator, useful for debugging authentication issues
Controller manager logs	Logs from the controller manager, which manages core control loops
Scheduler logs	Logs from the scheduler, useful for debugging pod scheduling decisions

CloudWatch Observability agent

You may also enable the CloudWatch Observability agent as an EKS add-on for enhanced cluster monitoring.

Setting	Description
AWS CloudWatch Observability agent installed on cluster	Enables the CloudWatch Observability add-on for metrics and logs collection

Security

ECR scanning

Enable Amazon ECR image scanning to automatically scan container images for software vulnerabilities.

Setting	Description
ECR scanning enabled	When enabled, images pushed to ECR are automatically scanned for vulnerabilities

AWS GuardDuty

AWS GuardDuty provides intelligent threat detection for your EKS cluster, monitoring for malicious activity and unauthorized behavior.When you enable the GuardDuty agent, Porter:

Installs the agent as an EKS add-on.
Turns on GuardDuty and Runtime Monitoring in the cluster’s region, if either is off.
Creates a guardduty-data VPC endpoint, which the agent sends its findings through, if the cluster’s VPC has none.

Turning the agent off removes it and any endpoint Porter created. GuardDuty and Runtime Monitoring stay on.

If a delegated administrator account manages GuardDuty for your organization, turn on Runtime Monitoring from that account.

Leave GuardDuty’s automated agent configuration for EKS off. Porter manages the agent’s version and reverts agent updates that GuardDuty makes.The endpoint Porter creates accepts traffic only from the cluster, but its DNS name applies to the whole VPC.

Setting	Description
AWS GuardDuty agent installed on cluster	Installs the GuardDuty agent on your cluster nodes

KMS encryption

Enable AWS Key Management Service (KMS) encryption for Kubernetes secrets stored in etcd.

Setting	Description
KMS encryption enabled	Encrypts Kubernetes secrets at rest using a customer-managed KMS key

Advanced Networking Config

Modifying these advanced network settings can impact cluster connectivity and performance. Ensure you understand the implications before making changes.

Setting	Description	Default
Egress NAT IPs Count	Number of egress NAT IPs. Cannot be decreased once set.	1
Min Ports per VM	Configures the minimum number of ports allocated per VM for GKE	64
Enable Endpoint Independent Mapping	Recommended for most use cases. Affects Cloud NAT behavior.	Enabled
Enable Dynamic Port Allocation	Allows GKE to dynamically allocate more ports to VMs that need them	Disabled

Networking

Private load balancer

In addition to the default public cluster load balancer, you can provision an internal load balancer on GKE that only accepts traffic from inside your VPC (or networks peered to it). Use this when you want to expose services to internal clients, for example an internal admin tool, a service consumed only by other VPCs, or a workload that must not be reachable from the public internet.

Setting	Description
Add private load balancer	Provisions a GKE internal load balancer alongside the existing public cluster load balancer.

Once enabled, you must configure a DNS provider so Porter can issue and renew TLS certificates for ingress hostnames attached to the private load balancer. Cloudflare is supported as a DNS provider for private load balancer ingress.

Setting	Description
DNS credentials	API token for Cloudflare. The token must have permission to create and delete `TXT` records on the zones used by your private ingress hostnames.

Delegating certificate validation

By default, the DNS credentials you give Porter need write access to the zone that hosts your private hostnames. If those hostnames live under a zone that also serves production domains, those credentials can reach your production records too, which is more privilege than you may want to grant.You can avoid that by delegating just the validation records to a separate, lower-privilege zone. You add a CNAME from each validation record in your zone to the delegated zone, then scope the credentials to that zone only. Porter handles the rest with no extra configuration on its side.1. Add the delegation CNAME records. Pick a low-privilege zone to hold the validation records (for example, acme.example-internal.com). In the zone that hosts your private hostnames, add a CNAME for each validation record, pointing at a record in the delegated zone:

_acme-challenge.app.internal.example.com.  CNAME  _acme-challenge.acme.example-internal.com.

2. Scope the credentials to the delegated zone. Create an API token scoped to the delegated zone only, with:

Zone.DNS → Edit
Zone.Zone → Read

The token does not need any access to your production zone.3. Verify the delegation. Confirm the CNAME resolves publicly:

dig +short CNAME _acme-challenge.app.internal.example.com
# expected: _acme-challenge.acme.example-internal.com.

Observability Settings

Configure observability features for the GKE cluster control plane.

Setting	Description
Enable Control Plane Logging	Enable the collection of logs from the Kubernetes control plane components (e.g., API server, scheduler)
Enable Control Plane Metrics	Enable the collection of metrics from the Kubernetes control plane components

Networking

Private load balancer

In addition to the default public cluster load balancer, you can provision an internal load balancer on AKS that only accepts traffic from inside your VNet (or networks peered to it). Use this when you want to expose services to internal clients, for example an internal admin tool, a service consumed only by other networks, or a workload that must not be reachable from the public internet.

Setting	Description
Add private load balancer	Provisions an internal Azure load balancer alongside the existing public cluster load balancer.

Setting	Description
DNS credentials	API token for Cloudflare. The token must have permission to create and delete `TXT` records on the zones used by your private ingress hostnames.

Delegating certificate validation

_acme-challenge.app.internal.example.com.  CNAME  _acme-challenge.acme.example-internal.com.

2. Scope the credentials to the delegated zone. Create an API token scoped to the delegated zone only, with:

Zone.DNS → Edit
Zone.Zone → Read

The token does not need any access to your production zone.3. Verify the delegation. Confirm the CNAME resolves publicly:

dig +short CNAME _acme-challenge.app.internal.example.com
# expected: _acme-challenge.acme.example-internal.com.

​Networking

​Private cluster

​Load balancer

​Application load balancer

​Certificate validation

​Point DNS at the ALB

​Web application firewall

​Route a service through the ALB

​Private load balancer

​Delegating certificate validation

​Observability

​CloudWatch control plane logs

​CloudWatch Observability agent

​Security

​ECR scanning

​AWS GuardDuty

​KMS encryption

​Advanced Networking Config

​Networking

​Private load balancer

​Delegating certificate validation

​Observability Settings

​Networking

​Private load balancer

​Delegating certificate validation

Networking

Private cluster

Load balancer

Application load balancer

Certificate validation

Point DNS at the ALB

Web application firewall

Route a service through the ALB

Private load balancer

Delegating certificate validation

Observability

CloudWatch control plane logs

CloudWatch Observability agent

Security

ECR scanning

AWS GuardDuty

KMS encryption

Advanced Networking Config

Networking

Private load balancer

Delegating certificate validation

Observability Settings

Networking

Private load balancer

Delegating certificate validation