FEATURES

Access control

Deliver databases securely to authorized users using Azure Vault, AWS Secrets, Hashicorp Vault, Active Directory, LDAP, or other authentication services

The need to democratize database access creates a greater need for data governance and privacy. Several authentication and authorization services are available on-prem or cloud such as Azure Key vault, Amazon Secrets manager and more. By combining these services with on-demand database delivery, your organization can democratize database access in a secure manner for developers, testers, analysts, etc.

Windocks provides access controls based on Windocks groups, Active Directory groups or secrets in vaults such as Azure Vault, Amazon Secrets manager and more. Simply specify the access controls in the image specification along with the details of the databases and masking. Windocks orchestration will do the work in enforcing the access controls.

 
access-control-banner.
Windocks-DevOps

Authorization

Specify in the dockerfile specification which users are authorized for which action and then build the image. From the image, two authorized actions are possible - a) Create the database container and clone from the image and b) Log in to the container and access the databases. Only authorized users can perform the authorized actions as described below.

Authorization mechanism Authorized Actions Description
Vault secret (Azure key vault, AWS secrets manager, Google secrets manager, Hashicorp vault)

Create database container and clone from image

Log in to container and access database clones

The key name for the secret is specified in the image.

User provides the secret while creating the container and clone. Windocks will call the vault with the key name and get the secret and authorize the user by comparing the secret provided by the user with the secret from the vault.

Further, Windocks sets the SYS or SA password to the secret it retrieved from the vault. User provides the secret to log into the container as SYS (Oracle) or SA (SQL Server).

The secret is never stored by Windocks, it is always retrieved from the vault when needed.

Active Directory user group Log in to container and access database clones The Active Directory groups that are authorized to log in to the container are specified in the image. When Windocks creates the container, it adds the Active Directory group as a sysadmin for SQL Server. Only users in that group can log into the container.
Windocks user group Create database container and clone from image The Windocks groups are specified in the image. Only Windocks users who are part of those groups can create containers and database clones from the image.

 

Steps to get started with synthetic data generation

1. Install Windocks

Download the Windocks Community Edition or email support@windocks.com for a full featured evaluation edition.

 

Provision a Windows Server VM (Server 2016, 2019, or 2022), install SQL Server (for SQL database delivery) and then install Windocks as described here.

 

For Oracle database delivery, also install the Windocks service for Linux as described here.

2. Provide the spec to the Windocks orchestrator to build a master image

Specify:

  • the path to one or more SQL backup or database files or Azure SQL BACPAC files, which database cloning to use  Windocks database cloning or volume cloning from other companies)
  • where to deliver the database clones (Windocks SQL Server Windows containers or SQL Server instances)
  • how often to refresh from production, customizations such as database scripts to be applied
  • which masking software to use (Windocks masking, other masking solutions or scripts)
  • authorization controls

The spec is provided in the form of a dockerfile. Build the image via a web application, command line or REST API.

 

Tutorial for SQL Server

Tutorial for Oracle

Tutorial for PostgreSQL, MySQL

3. Add access controls to the dockerfile spec

Start with the sample in windocks\samples\accesscontrol. Add a single line to the dockerfile to specify who has access to the databases in the image. For Windocks and ActiveDirectory groups, simply add a line as below:

ENV IMAGE_PERMISSIONS=Windocks_group2,Windocks_group3, DOMAINNAME\AD_Group1, MACHINENAME\AD_Group2

For vaults, add a single line to the dockerfile specifying the vault type, and key to use from the vault
ENV IMAGE_PERMISSIONS={Vault:Azure, Key: Key_For_Prod_Db}

Register the Windocks application with the Vault and get the credentials for the Windocks application from the vault. Put the credentials from the vault in the windocks\config\node.conf as specified in the node.conf file. Restart the Windocks service after changing the node.conf file

Active Directory groups are supported for SQL Server only. Windocks groups and vaults are supported for SQL Server, Oracle, and other databases.

4. Deliver containers with database clones from the image

From the image, deliver database clones to containers or instances. The image you built defines where the databases are delivered to. You may define an image that delivers containers with clones as well as clones to instances. To deliver containers and clones, use the web application or use the docker command line or the REST API.

If the image had access controls based on Windocks auth groups or Active directory groups, then only users in those groups can access the databases in the container.

If the image had access controls based on vaults, the user needs to specify the secret for the key while creating the container and clone in an environment variable or the user interface.
docker create -e VAULT_SECRET=secret yourimagename

Extend CI/CD to your data layer