Frequently asked questions Customers and Partners may have about the security of the SaaS Controller.
Please contact the security team at firstname.lastname@example.org 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.
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 "22.214.171.124"
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.
|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.
The Kubernetes Operator uses only "TCP Port 443, Outbound" to communicate with the Controller.
|443/tcp||TLS with Mutual Auth||All Control Plane functionality|
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.
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:
|IP Address 1||126.96.36.199|
|IP Address 2||188.8.131.52|
|IP Address 3||184.108.40.206|
The k8s operator components will access the Controller on the following FQDNs. Add these to your firewall's whitelist if necessary.
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.
|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.
|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 "email@example.com" 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 "*.user.kubeapi-proxy.rafay.dev" 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
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.
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.
The disks are encrypted per-Org with a unique key for the organization. See key management above for additional information.
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 firstname.lastname@example.org for details.