Security

Below are a few aspects of SneaQL which are important to consider with regards to security:

• Secrets management (passwords, etc)
• Environment Variables
• SQL injection
• SneaQL Extensions

Secrets management

The default behavior of SneaQL is to accept database passwords as Environment Variables passed into the process at run time. When running SneaQL locally, you can store these secrets in a sneaql.env file (which should never be checked into source control).

sneaql.env works great for local development, but storing plain text passwords in a production environment is not a good practice. If you don't already have a secrets management tool or platform, and you are running SneaQL in AWS, we suggest using the full360/sneaql Docker Image, as it has integrated support for secrets management by way of the open source biscuit utility. Biscuit creates an easy to use abstraction for the Amazon KMS service, which allows you to store an encrypted copy of the keys in a http store (such as Amazon S3) then decrypt the keys at the time of container start up. The secrets file created by biscuit is useless unless you have access to KMS for decryption. Access to KMS can be restricted to the necessary AWS resources and users.

Biscuit will also work in a non-AWS version environment, but it will rely upon AWS credentials and access to the API for decryption.

Environment Variables

All Environment Variables are passed into SneaQL when it starts running. Users being able to reference environment variables in their scripts would potentially allow them to expose secrets by way of the SQL and or logging. In a shared or production environment this will not do!

SNEAQL_AVAILABLE_ENV_VARS environment variable allows you to provide a comma-delimited list of "whitelisted" environment variables that can be passed to the transform:

SNEAQL_AVAILABLE_ENV_VARS=USER_PARAM_1,DATA_DATE,ANOTHER_SAFE_VALUE

SQL Injection

With it being possible to pass parameters into SneaQL by way of Environment Variables it is important to evaluate the risk of SQL injection.

By default, SneaQL has a simple regular expression based filter that is applied to the Environment Variables at the time they are parsed. This filter will prevent you from using any variables with values containing ; ' or other basic SQL statements such as drop user dbadmin. The filter will raise an error that will exit the transform if any funny business is passed in.

If you have an application where you are collecting parameters from users before passing them into a SneaQL transform (by way of Environment Variables), you should create your own validations at the time of parameter collection in order to insure that malicious SQL is not being passed in. In a public facing application you should not rely on the regular expression based filter that is integrated into SneaQL.

SneaQL Extensions

Extending SneaQL through jruby is achieved by way of a ruby gem. In order to include the gem at runtime the following conditions must be true:

• Extension gem must be installed into the same jruby context as the SneaQL gem
• SNEAQL_EXTENSIONS environment variable provides a comma-delimited list of extensions that can be used at runtime

SNEAQL_EXTENSIONS=sneaql-aws,my-custom-extension