# Redgate Clone - Security Overview ![](https://i.imgur.com/UMZBsE4.png) ## Roles User - End user that uses Redgate Clone to provision database instances. Admin - Administrator that configures, maintains and updates Redgate Clone installation. ## Redgate Clone componets Redgate Clone cluster - A VM or a set of VMs used to host Redgate Clone. For a multi-node (multi-VM) setup the VMs are expected to be in a single subnet, separate from the rest of the intranet. Redgate Portal - Online service used by Redgate Clone to download its components and updates. ## Communication 1. **User using rgclone CLI to communicate wuth Redgate Clone API** Communication: HTTP requests from rgclone CLI to Redgate Clone's CLI endpoint. Transport security: Can be secured by a TLS certificate in Redgate Clone configuration. Authentication: Initial authentication (using rgclone auth command) by an OpenID auth or by an authentication token. Subsequent requests use a renewable JWT. 2. **User authenticating using OpenID service** Communication: Standard OpenID authentication flow using a browser authentication. Transport security and authentication: Based on the provided OpenID service. 3. **User accessing data container** Communication: Regular communication with a database service instance of a given type (MSSQL, PostreSQL etc.) Transport security: TLS-protected. Additional details depend on the database service setup. Authentication: Database service user authentication. Credentials are automatically generated as a part of data container creation process. 4. **Admin accessing Admin Console** Communication: Admins user accessing Redgate Clone configuration via a Web UI. Transport security: Can be secured by a TLS certificate during the setup. Authentication: Authenticated by an Admin Console password (set during initial installation) 5. **Admin accessing cluster infrastructure** As a part of installation and maintenance process admin users need to access the cluster VMs to run system and Kubernetes commands. In that case security is equivalent to the security of the cluster VM and the remote connection used by the admin. 5.1. **Remote access to Kubernetes infrastructure** Optionaly, it's possible to run Kubernetes commands for maintenance and diagnostic from outside the cluster by exporting the Kubernetes configuration. In that scenario best practices for securing a kubeconfig connection should be followed. 6. **Redgate Clone accessing backups on the Backups File Share** Communication: When instructed Redgate Clone loads backups from a file share to use as sources for data images. Transport security: Depends on the file share setup. Authentication: Redgate Clone uses credentials specified in the configuration to access the file share. 7. **Redgate Clone accessing the Redgate Portal** Communication: Redgate Clone checks for latest updates and downloads new versions when instructed. The portal also serves as a Docker image registry, from which Redgate Clone downloads container images for its components (including data containers). Authentication: Internal Redgate Clone authentication based on the product license. 8. **Inter-node communication in a multi-node setup** Communication: Diferent communication between multiple services deployed across nodes in a multi-node Redgate Clone cluster. This communication can be limited to the cluster subnet and isolatedfrom the intranet using a firewall. Transport security: Not guaranteed to be secured at the transport layer. Authnentication: Internal Redgate Clone authentication depending on the specific service.