Delphix Appliance

[Jacinda Saleeby]

TheDelphix Engine is delivered and maintained as a closed virtual software appliance. Like all virtual appliances, the Delphix Engine is a tightly integrated combination of a special-purpose operating system and business logic. A single engine can be configured for data virtualization or data masking.

The product is delivered as a closed appliance because there are dependencies between software components within the virtual appliance, which require end-to-end testing. As such, we do not provide administrative access to the operating system for any reason, including installing software, making customizations, or performing security scans. More details about the administrative model will be provided in later sections of this document.

Regardless of the initial packaging used to deploy the Delphix Engine, updates are supplied as a single upgrade image of the new release, and the same image can be used for any prior release from which an upgrade is supported. This upgrade image delivers a completely new appliance, including both the operating system and business logic components.

The upgrade process retains prior configuration and customer data such that no data or configuration is lost during the upgrade process. The upgrade process retains a copy of the previous version of the components for automatic recovery in case an upgrade fails. Installed versions older than the prior version are automatically deleted during the upgrade.

Delphix characterizes software as Major Release, Minor Release, and Maintenance Release in the Delphix Support Policies. These release types indicate the level of feature addition and change. For example, a Major Release may introduce significant new features, interface changes, and many bug fixes. A Maintenance Release or Patch Release may deliver only a small number of bug fixes and no feature additions. In any case, each release delivers a complete upgrade image of the appliance.

There is no component patching of the Delphix Engine; fixes are delivered in new versions of the software as a new software appliance. There is no management of patches involved, and each Delphix Engine version is a consistent, tested virtual appliance.

Administration of the Delphix Engine is effected through product interfaces only. These interfaces provide for the proper configuration and testing of customer infrastructure components, such as network addresses, storage, Domain Name Service (DNS) servers, authentication servers (LDAP), etc. The interfaces also control the business logic and control of the overall platform, including how customer data is used and provisioned by the system.

Although the special-purpose operating system may be accessed by Delphix Support and Engineering personnel for the purpose of diagnostics and problem remediation, there are no customer-accessible interfaces at the operating system level. Customers are not provided access to the underlying operating system nor can any custom software be installed on the appliance.

Delivered by Delphix Services or Integration Partners. These customizations allow for the use of privilege mechanisms other than sudo on Linux and Unix target environments. Sudo is the product default.

These customer-managed scripts allow for custom business logic to be applied to Oracle and SQL Server data sources and virtual databases. The scripts are not integrated into the appliance but are referenced and invoked by the product during data operations.

This section will detail the hardware/software requirements needed todeploy the Delphix Engine with the Masking service. The DelphixEngine is a self-contained operating environment and application that isprovided as a Virtual Appliance. Our Virtual Appliance is certified torun on a variety of platforms including VMware, AWS, and Azure.

The Delphix Engine should be placed on a server where it will notcontend with other VMs for network, storage or other compute resources.The Delphix Engine is a CPU and I/O intensive application, and deploying it inan environment where it must share resources with other virtualmachines can significantly reduce performance.

To use both Continuous Data and Continuous Compliance note, they must bedeployed separately. One Delphix engine is required for each per each service,running both masking and virtualization operations on one engine is notsupported.

For Containerized Masking, the product is delivered as a set of containerswhich is deployed as a Pod in the customer's Kubernetes infrastructure. ThisPod provides a very similar set of functionality as the Delphix Engine VM basedappliance.

Containerized Masking was developed to provide the ability to create ephemeralengines. I.e. small engines that can be spun up quickly for a specific needand then thrown away once that need is fulfilled.

Additionally, some functionality may require additional software be installedon the kebrnetes node systems. For example, if use of NFS mounted filesystemsis planned, each node would need the NFS client software to allow kubernetesto perform the desired NFS mounts.

The VMware based Continuous Compliance engine was deployed conjoined with theContinuous Data product, including its Engine Setup App. The containerizedversion of Continuous Compliance is fully divorced from the Continuous Dataproduct which means that some functionality that was provided or enabled by theEngine Setup App is not available. Some unavailable items are on the roadmapto be re-introduced to Containerized Continuous Compliance in future releases.

The Delphix Engine is an appliance that lets you quickly and cheaply make virtual copies of large datasets. The engine has built-in support for interfacing with certain types of datasets, such as Oracle, SQL Server and ASE.

These plugin operations are the building blocks of the Delphix Engine. From these building blocks, the engine can provide all of the normal Delphix functionality to the datasets you connect to such as:

As of 5.3.0.0, the Continuous Compliance Engine supports Kerberos authentication for Oracle, MS SQL Server, and Sybase connections. Utilizing this service requires the presence of a Kerberos Key Distribution Center (KDC) server as well as additional configuration actions to be done on both the Masking Engine and the database. This document presents configuration instructions for enabling and using Kerberos on the Continuous Compliance Engine, as well as reference configurations for enabling Kerberos on the Databases. Although other configurations are possible, the configurations in this document have been validated by Delphix.

Throughout this document, the following example values are used. To recreate these reference environments, these values must be replaced with real values appropriate for your network environment: - .bar.com - the DNS domain of the network - BAR.COM - the Kerberos domain - me-host - the hostname of the Masking Engine - foo-kcd - the hostname KDC server - krbuser - the Kerberos principal to be granted access to the database for masking

Click the plus symbol to add record(s) for your KDCs, and populate other fields appropriately for your network environment. Upon pressing Save, your configuration will be tested. If the engine is able to authenticate to the KDC with the supplied configuration, the configuration is applied immediately.

For Sybase database Connectors, it is necessary to supply the service principal name as an additional configuration item. For Oracle DB, this value is determined automatically. For MS SQL Server it is determined based on the reverse DNS mapping of the Server Name (refer to the section on MS SQL Server below).

If any changes are made to the underlying krb5.conf configuration file, these changes will not be recognized by the engine until after the next database connection attempt. Therefore, expect to have to hit "Test Connection" twice after making any changes to the krb5.conf file. It does not matter if the first connection attempt succeeds or fails.

The following is a series of reference Kerberos configuration procedures and troubleshooting notes for the supported databases. These are meant to serve as examples to be further customized according to the user's specific network environment and security needs.

This document assumes you already have a kerberized network environment with an MIT Kerberos KDC. These procedures have been tested successfully with Oracle database versions 11.2.0.2, 11.2.0.4 and 12.2.1. Oracle database version 12.1.0.1 did not work in our testing.

You will need the following from your Kerberos environment: - The krb5.conf file - A user principal and associated password or key tab you'd like to use to log into the database - The ability to create a service principal for the Oracle DB and retrieve the associated key tab.

Notice that the hostname is whatever the database system thinks its hostname is - that is, the output of "uname -n" on the database system, rather than the actual DNS name of the database system. Typically, these values would be the same, but this is not always the case.

Connecting via JDBC with Kerberos authentication from Continuous Compliance involves two steps - a Kerberos login, followed by JDBC connect. A failure stack with an error in the login function indicates a misconfiguration on either the engine or KDC - the engine hasn't even attempted to communicate with the database at that point. Failure stacks are saved in the debugging log for masking.

Login exceptions that mention a checksum error mean either the password or keytab supplied doesn't match the expected password/key on the KDC for the principal you're trying to use. Server Setup verifies that your keytab works at configuration time, but it could stop working if the key for your principal is updated on the KDC.

Prior to version 12, Oracle databases instances assume they can create/write a particular temporary file to store Kerberos credentials for the DB. This means if you attempt to run multiple kerberized instances of Oracle 11 on the same system or VM, and the databases run as different system users, the first Oracle instance that performs Kerberos auth will create and own this file. Kerberos authentication will fail to function on all other instances.

3a8082e126