Overview

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

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, it is assumed that the customer will configure Security Groups.

Cluster Authentication

Every managed cluster is issued a unique identity (certificate) by the Controller. The Kubernetes Management Operator uses this to establish a control channel with the Controller. These credentials are automatically rotated behind the scenes by the controller before they expire. The controller requires the use of mutual certificate based authentication to establish the secure TLS connection. Only the Kubernetes Management Operator deployed on managed clusters are able to establish secure connections with the controller using unique client credentials.

The sequence diagram below shows the high level steps by which the Rafay Kubernetes operator installed on a managed cluster is provided with a unique identity (certificate) for mutual authentication.

Rafay OperatorClusterControllerRafay OperatorClusterControllerGenerate CSR (with unique token)Verify token and Sign CSROnly accept connections with valid client certificateProvision/Import Cluster (unique token)Start Rafay OperatorSend CSRSend Signed CertificateEstablish long running mTLS connectionUses secure connection for cluster operations

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 " noreply-rcloud@rafay.co" 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

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

Our security team maintains a comprehensive Security Technical White Paper. Please contact us if you would like to receive a copy.