Please contact the security team at email@example.com 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.
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.
sequenceDiagram Controller->>Cluster: Provision/Import Cluster (unique token) Cluster-->> Rafay Operator: Start Rafay Operator Note right of Rafay Operator: Generate CSR (with unique token) Rafay Operator-->>Controller: Send CSR Note left of Controller: Verify token and Sign CSR Controller->> Rafay Operator: Send Signed Certificate rect rgb(191, 223, 255) Rafay Operator->>+Controller: Establish long running mTLS connection Note left of Controller: Only accept connections with valid client certificate Controller->>-Rafay Operator: Uses secure connection for cluster operations end
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 "firstname.lastname@example.org" 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¶
Our security team maintains a comprehensive Security Technical White Paper. Please contact us if you would like to receive a copy.