SRA Requirements

Use this page to validate infrastructure requirements before deploying Akeyless Gateway with Secure Remote Access (SRA) and Zero Trust Web Access (ZTWA).

Port values below are default values from the official Helm charts and Docker Compose examples. Exact exposure can vary by deployment model, ingress, and service configuration.

For deeper planning guidance, use Infrastructure and Capacity Planning:

• Runtime Components and Ports
• Scaling and HPA Patterns
• Storage and Recording Capacity

Requirements Checklist

Validate the following requirements before rollout.

Core Infrastructure Requirements

Outbound Connectivity

Allow outbound connectivity to the following destinations:

• Akeyless API endpoint
• Session forwarding target endpoints, when session forwarding is configured
• Recording storage endpoints (for example, S3 or Azure Blob), when RDP recording is configured

Redis Dependency

Redis cache support is required for SRA components. For Gateway-only deployments without SRA, cache is optional.

For Redis defaults and operational guidance, see Redis documentation.

For runtime dependency paths that include Redis, see Runtime Components and Ports.

Minimum Resources

Use at least 1 vCPU and 2 GiB memory for each SRA component.

For autoscaling policy and scale-in protection guidance, see Scaling and HPA Patterns.

Kubernetes-Specific Requirements

• Expose the SSH bastion service with type: LoadBalancer.
• Run the SSH bastion container in privileged mode.
• If metadata-service based cloud detection is restricted, explicitly configure the dispatcher cloud identity type in your deployment values (aws_iam, azure_ad, or gcp).

For platform guidance, see Kubernetes Service type LoadBalancer and Linux kernel security constraints.

Account Region and Authentication Service Configuration

When deploying SRA in regions outside the default account region, configure the bastion authentication service endpoint to match your account location.

For non-default account regions (for example, MEU for European accounts):

• Ensure the UAM_ADDR environment variable in bastion deployment is set to the correct authentication service endpoint for your region.
• Verify account region setting in Gateway console under Remote Access configuration.
• When RDP or other session types fail to connect after authentication succeeds, cross-check the UAM_ADDR variable and account region setting as a first diagnostic step.

Misalignment between account region and UAM_ADDR configuration can result in RDP sessions closing without meaningful error messages in logs.

Gateway Certificate Trust Requirements

If Gateway or ingress endpoints use private or self-signed certificates, make sure SRA components trust that CA chain.

When needed, provide trusted certificate material by configuration so dispatcher and bastion runtime checks can validate TLS connections to Gateway endpoints.

For Gateway TLS configuration context, see Gateway TLS settings.

Docker Compose Profiles

Use Docker Compose profiles as follows:

• gateway
• sra
• metrics

For profile behavior and usage, see Docker Compose profiles.

Session Routing and Cookie Requirements

Session routing, persistence, and cookie controls keep multi-step SRA and ZTWA traffic pinned to the correct backend and preserve authenticated browser state across ingress, load balancer, and proxy hops.

Session Affinity and Sticky Sessions

When SRA services are exposed through an ingress or cloud load balancer, use session affinity (sticky sessions) so follow-up requests remain pinned to the same backend.

Sticky sessions are required for database application access flows (for example, MySQL, MSSQL, and MongoDB) when traffic is routed through ingress.

For NGINX ingress, use cookie-based affinity annotations:

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"

For cloud-provider load balancers, configure the equivalent session-persistence setting in the provider configuration.

If you are not using NGINX ingress, use the equivalent session-persistence policy for your ingress controller. For Envoy Gateway, use a BackendTrafficPolicy-based cookie persistence policy instead of NGINX annotations.

For Envoy policy reference, see Envoy Gateway session persistence.

For scale-event safeguards that reduce sticky-session disruption, see Scaling and HPA Patterns.

SAML and Redirect Size Limits

If SRA is published through identity-aware reverse proxies, validate request URI and redirect limits for your proxy tier.

SAML and JWT-heavy redirects can exceed proxy URI limits in some environments and fail before login completes.

When possible, prefer login flows that reduce query-string payload size and avoid static matching assumptions for dynamic SAML redirect parameters.

For Azure App Proxy behavior, see Microsoft Entra application proxy.

Access Permissions by Connection Mode

Validate RBAC and item permissions separately for each access mode used by your organization.

Direct access and some proxy flows can require item read permissions in addition to SRA allow-access capabilities, depending on mode and product behavior.

Session Cookies

For ZTWA and web-bastion browser sessions, secure cookies should remain enabled for HTTPS endpoints.

For HTTP-only lab environments, use the deployment-specific setting that disables secure cookies for the dispatcher service only when TLS termination cannot be used in that environment.

For configuration context, see SRA Web Access Topology.

Session Timeout and TTL Alignment

Long SSH, RDP, and web sessions can be cut off early by default load balancer or ingress idle timeouts.

Set idle and response timeout values to at least your intended SRA session TTL (for example, 15 to 60 minutes).

If a custom bastion default session TTL is set, align these network timeout values with that TTL.

GKE Ingress Default Timeout Edge Case

In GKE ingress environments, backend timeout defaults can terminate active SRA sessions if left unchanged.

Before production rollout on GKE:

1. Verify the effective backend timeout for SRA-related services.
2. If timeout is still 30s, set a higher timeoutSec value by using BackendConfig or GCPBackendPolicy.
3. Validate long-lived SSH and RDP sessions after applying timeout changes.

Example BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: sra-backendconfig
spec:
  timeoutSec: 3600

Vendor references:

• Google Cloud backend service timeout
• Google Kubernetes Engine ingress configuration
• AWS Application Load Balancers
• AWS Network Load Balancer idle timeout
• Azure Load Balancer TCP idle timeout
• Azure Application Gateway FAQ
• NGINX WebSocket proxying

For autoscaling decisions that should align with these timeout values, see Scaling and HPA Patterns.

Redirect URL Allowlist Requirements

Configure allowed redirect URLs for bastion and web proxy endpoints as part of SRA and ZTWA deployment.

For Helm-based deployments, set:

• allowedBastionUrls
• allowedProxyUrls

For Docker-based SSH bastion deployments, configure ALLOWED_BASTION_URLS.

These allowlists are consumed by SRA keep-alive and bastion metadata flows. In the Zero Trust Portal client, non-allowed user-provided endpoint URLs are removed from local endpoint state.

Session Recording Authentication Compatibility

When session recording upload is enabled, validate the dispatcher authentication path and object-storage upload authentication path together.

If you observe post-session authentication failures, test alternative credential-source combinations for dispatcher runtime authentication and storage-upload authentication, and keep the stable combination for production rollout.

For recording volume estimates, retention planning, and backend lifecycle controls, see Storage and Recording Capacity.

Port Inventory

The following table lists the primary ports by component.

For component topology and namespace isolation implementation patterns, see Runtime Components and Ports.