Skip to content


Frequently asked questions Customers and Partners may have about the security of the SaaS Controller.


Please contact the security team at for questions not covered in the documentation.


This section captures details about the SaaS Controller that customers can use to optionally whitelist inbound (emails) and outbound (control channel destinations) in their firewalls and proxies.

Email Whitelisting

A 3rd Party service is used for emails sent by the Controller (i.e. for first time user activation, password resets, notifications etc). To guarantee delivery of emails from the SaaS Controller to users in the Tenant/Organization, we strongly recommend that customers "whitelist" the IP address used for sending emails in their inbound email security systems.

The dedicated IP address currently used for sending emails from the Controller is ""

Network Firewall Rules

The Controller has been specially designed so that customers can deploy and manage their clusters in both Internet (public IP) and on-premises (private IP) type environments.

Deployment Model
Internet Facing, Public IP
Non Internet Facing, Private IP

To onboard an on-premise or cloud-based cluster onto the Controller for ongoing operations and lifecycle management

  • A “Kubernetes Operator” is installed on each managed cluster.
  • This establishes and maintains a "long-running" outbound TLS based control channel to the Controller (hosted in Amazon Web Services (AWS) for SaaS).
  • No Inbound Ports need to be opened on the customer's external firewall for control plane traffic.

Outbound Ports

The Kubernetes Operator uses only "TCP Port 443, Outbound" to communicate with the Controller.

Outbound Port Security Purpose
443/tcp TLS with Mutual Auth All Control Plane functionality

Controller Details

Customers that wish to lock down communication further can optionally whitelist the IP addresses of the SaaS Controller in their firewalls to ensure that outbound connectivity is only allowed to these IPs.

IP Addresses

The SaaS Controller is currently deployed in a highly available manner across three availability zones (AZ) on AWS. The three IP Addresses for the Controller are:

Server IP Address
IP Address 1
IP Address 2
IP Address 3

Controller FQDNs

The k8s operator components will access the Controller on the following FQDNs. Add these to your firewall's whitelist if necessary.

Controller FQDNs

System Container Registry

The System Container Registry (RCR) is available as an option for customers to manage their container images. This is based on Docker Registry v2. It uses OAuth2 for authentication (laptops etc using the RCTL CLI).

Users are automatically redirected to an OAuth service which uses the provided credentials in docker login to authenticate and authorize the request for a resource on the registry. For successful requests, a bearer token is returned, which is used to access a resource on the Container Registry.

Please ensure that the network security policies implemented either in the corporate network OR the endpoint are configured to allow outbound connections from the RCTL CLI to the Controller on the ports listed below.

Outbound Port Security Purpose
443/tcp TLS (https) Access the Controller Platform via REST APIs

Please add the following ports if you wish to use the System Container Registry.

Outbound Port Security Purpose
5001/tcp TLS (https) OAuth Authentication Service for Hosted Container Registry
6000/tcp TLS (https) Access to Hosted Container Registry

Network Security at Clusters

The customer is responsible for providing network security for their on-prem datacenters where the clusters may be provisioned. In a public cloud environments, the cluster is expected to sit behind a customer's primary firewall. For example, in an Amazon AWS deployment, a customer will configure Security Groups.

User Authentication and Authorization

All non SSO users in an Org are required to verify access to their registered email address before they are allowed access. Org admins can optionally enable and enforce the use of MFA for all users in their organization. See Users and Roles for additional details.

Customers are recommended to whitelist "" in their email platform to ensure that emails sent to users are not inadvertently classified as spam or blocked.

VPN and Zero Trust KubeCTL

Authorized end users do not require a VPN to securely access their clusters operating behind corporate firewalls using Zero Trust KubeCTL.

However, if a VPN is configured or in use, please ensure that "*" FQDN is whitelisted in the proxy configuration.

Zero Trust KubeCTL uses mutual authentication to secure the connection from the end user to the KubeCTL access proxy in the controller. Man-in-the-middle proxies that terminate the connection will break the security model and users will see an error message from the KubeCTL CLI.

Unable to connect to the server: x509: certificate signed by unknown authority

Audit Logs

All actions performed by authorized users are audited. A reverse chronological audit log is available for users via the Console.

Role based Access Control (RBAC)

The Controller supports a number of roles that can be associated with users. See roles for additional details.

Key Management

The Controller utilizes a central vault (based on a HSM backed KMS) for managing secrets across the entire infrastructure. Secrets are programmed into local cluster secret stores from the central vault when necessary.

Data Encryption

The disks are encrypted per-Org with a unique key for the organization. See key management above for additional information.

Transport Encryption

All communication channels between the Managed Clusters and the Controller are done over TLS. A private PKI is utilized to generate certificates for inter component mTLS. All customer and partner facing API and Web Console utilize TLS as well.

Security White Paper

Upon request, we can provide you with a comprehensive "Security Technical White Paper". Please contact for details.