Contents

User Roles

User - End user that uses Redgate Clone to provision their own database instances and images. Users can choose to share their images with other users. Access is controlled via OIDC.

Admin User - End users that also have full access to all database instances and images created by any user. Users are granted admin rights based on the value of the OIDC claim, rgclone_admin, set by the OIDC Identity Provider.

Cluster Admin - Anyone who has access to the Admin Console, Monitoring Dashboard, the underlying Redgate Clone cluster and its related infrastructure. Cluster Admins configure, maintain and update the Redgate Clone installation.

Note: These roles are not enforced by Redgate

Redgate Clone components

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.

Admin Console - Online service used by Redgate Clone to download its components and updates.

Image Creation

Creating an image requires access to the file share. The database instance that is used to create the image is given full access to the file share - not just the individual backups selected. It is therefore possible, using the pre/post-script options, for Redgate Clone users to access the entire file share. 

Communication

General concerns about Redgate Clone cluster access

Redgate Clone exposes multiple endpoints for different needs and use cases. Based on your needs these endpoints can be additionally secured by network security configuration (e.g., firewall) for the subnet containing Redgate Clone cluster. 

1. User using rgclone CLI to communicate with Redgate Clone API

Communication: HTTP(S) requests from rgclone CLI to Redgate Clone’s API 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 (set in Admin Console). Subsequent requests use a renewable JWT.

1.1. Authentication JWT lifetime

For OpenID device flow issued JWT has a limited lifespan, which is reset each time the user makes a new request before expiration.

For authentication tokens the access doesn't expire.

2. User authenticating using OpenID service

Communication: Standard OIDC device flow authentication using a browser.

Transport security and authentication: Based on the provided OpenID service.

3. User accessing a data container

Communication: Regular communication with a database service instance of a given type (MSSQL, PostgreSQL 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 status and configuration via a Web UI. For additional details around providing support bundles to Redgate see the Generate Support Bundles page.

Transport security: Secured by a TLS certificate if this is provided during the setup.

Authentication: Authenticated by a separate Admin Console password.

5. Admin accessing Monitoring Dashboard

Communication: Grafana UI with a diagnostic status of the cluster that doesn't include sensitive configuration.

Transport security: Secured by a TLS certificate if this is provided during the setup.

Authentication: Username and password, automatically generated during installation.

6. Cluster 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 Cluster Admin.

6.1. Remote access to Kubernetes infrastructure

Optionally, 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.

7. 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: Relies on the file share setup.

Authentication: Redgate Clone uses credentials specified in the configuration to access the file share.

8. Redgate Clone accessing the Redgate Admin Console

Communication: Redgate Clone checks for latest updates and downloads new versions when instructed. The Admin Console 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.

9. Inter-node communication in a multi-node setup

Communication: Different communication between multiple services deployed across nodes in a multi-node Redgate Clone cluster. This communication can be limited to the cluster subnet and isolated from the intranet using a firewall.

Transport security: TLS is not used for communication between the nodes..

Authentication: Internal Redgate Clone authentication depending on the specific service.

Limitations

• There is no concept of team in the product and thus no segregation of responsibilities or visibility between teams.