Skip to main content
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 and GCP clusters.

​
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.
SettingDescription
Private clusterRestricts 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 allowlistAdditional 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.
TypeDescription
NLBNetwork Load Balancer — operates at Layer 4, routes TCP/UDP traffic, and provides ultra-low latency and high throughput.
ALBApplication 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.
SettingDescription
Wildcard domainsDomains to issue ACM certificates for. Do not include the *. prefix — Porter creates a SAN for *.<domain> automatically. Comma-separate multiple domains.
IP allow listComma-separated list of CIDR ranges (e.g. 160.72.72.58/32,160.72.72.59/32) permitted to reach the ALB.
Certificate ARNsExisting ACM certificate ARNs to attach to the ALB.
AWS tagsKey/value tags applied to the ALB and related AWS resources.
WAFv2 enabledAttaches a Regional WAFv2 web ACL to the ALB.
WAFv2 ARNARN of the Regional WAFv2 web ACL to attach. Only Regional WAFv2 is supported.

​
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.
SettingDescription
Add private load balancerProvisions 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.
SettingDescription
DNS credentialsAPI 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.

​
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.
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 TypeDescription
API Server logsLogs from the Kubernetes API server, useful for debugging API requests
Audit logsRecords of individual users, administrators, or system components that have affected the cluster
Authenticator logsLogs from the AWS IAM authenticator, useful for debugging authentication issues
Controller manager logsLogs from the controller manager, which manages core control loops
Scheduler logsLogs 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.
SettingDescription
AWS CloudWatch Observability agent installed on clusterEnables 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.
SettingDescription
ECR scanning enabledWhen 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 enabling GuardDuty, you must also configure the following in your AWS Console:
  1. Enable EKS Protection in the EKS Protection tab of the GuardDuty console
  2. Enable Runtime Monitoring
For automated agent configuration, enable both:
  • EKS agent auto-configuration
  • EC2 agent auto-configuration
SettingDescription
AWS GuardDuty agent installed on clusterInstalls the GuardDuty security agent on your cluster nodes

​
KMS encryption

Enable AWS Key Management Service (KMS) encryption for Kubernetes secrets stored in etcd.
SettingDescription
KMS encryption enabledEncrypts Kubernetes secrets at rest using a customer-managed KMS key