Driverless AI Security¶
Objective¶
This document describes different aspects of Driverless AI security and provides guidelines to secure the system by reducing its surface of vulnerability.
This section covers the following areas of the product:
Authentication (Also see Authentication Methods)
Authorization
Configuration Security (Also see in depth documentation on configuration security in DAI)
Important things to know¶
Warning
WARNING Security in a default installation of Driverless AI is DISABLED! By default, a Driverless AI installation targets ease-of- use and does not enable all security features listed in this document. For production environments, we recommend following this document and performing a secure Driverless AI installation.
User Access¶
Authentication¶
Driverless AI supports Client Certificate, LDAP, Local, mTLS, OpenID, PAM, none, and unvalidated (default) authentication. These can be configured by specifying the environment variables when starting the Driverless AI Docker image or by specifying the appropriate configuration options in the config.toml file. For more info, see Authentication Methods.
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
Any supported authentication (e.g., LDAP, PAM) method except |
Define user authentication method. |
|
|
Consult your security requirements. |
Number of hours after which a user has to relogin. |
mTLS Authentication¶
Driverless AI supports Mutual TLS authentication (mTLS) by setting a specific verification mode along with a certificate authority file, an SSL private key, and an SSL certificate file. For more information, see the mTLS Authentication Example.
Data Security¶
Data Import¶
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
Configure only needed data sources. |
Control list of available/configured data sources. |
|
|
Configure based on expected file size and size of Driverless AI deployment. |
Limit maximum size of uploaded file. |
|
see config.toml |
It is recommended to limit file types to extension used in the target environment (e.g., |
Supported file formats listed in filesystem browsers. |
|
|
|
Show all available data sources in WebUI (even though there are not configured). It is recommended to show only configured data sources. |
Data Export¶
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
|
Control ability to download any datasets (uploaded, predictions, MLI). Note: if dataset download is disabled, we strongly suggest to disable custom recipes as well to remove another way how data could be exported from the application. |
|
|
|
Replace all downloads on the experiment page to “exports”, and
allow users to push to the artifact store configured with
|
|
|
|
Stores a MOJO on a file system directory denoted by
|
|
|
|
File system location where artifacts will be copied in case
|
Notes about Artifacts:
Currently,
file_system
is the only option that can be specified forartifacts_store
. Additional options will be available in future releases.The location for
artifacts_file_system_directory
is expected to be a directory on your server.When these artifacts are enabled/configured, the menu options on the Completed Experiment Page page change. Specifically, all “Download” options (with the exception of AutoDoc) change to “Export.” Refer to Exporting Artifacts for more information.
Logs¶
The Driverless AI produces several logs:
audit logs
server logs
experiment logs
The administrator of Driverless AI application (i.e., person who is responsible for configuration and setup of the application) has control over content which is written to the logs.
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
|
Number of days to keep audit logs. The value |
|
see config.toml |
— |
Contain list of configuration options which are not recorded in logs. |
|
|
see config.toml |
Define verbosity of logging |
|
|
|
Dump server logs with experiment. Dangerous because server logs can contain information about experiments of other users using Driverless AI. |
|
|
— |
Log level for OSS H2O instances used by custom recipes. |
|
|
|
Enable debug logs. |
|
|
|
Dump a custom recipe source code into logs. |
User Data Isolation¶
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
Specify proper name and location of directory. |
Directory where Driverless AI stores all computed experiments and datasets |
|
|
|
Hide |
|
|
|
Enable path filter for |
|
|
Include a list of folder paths or |
List of absolute path prefixes to restrict access to in |
|
|
|
Directory where Driverless AI searches for the updated AutoDoc templates. Providing empty value |
Client-Server Communication Security¶
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
|
Enable HTTPS |
|
|
Correct private key. |
Private key to setup HTTPS/SSL communication. |
|
|
Correct public certifikate. |
Public certificate to setup HTTPS/SSL. |
|
|
|
Prevents an SSLv2 connection. |
|
|
|
Prevents an SSLv3 connection. |
|
|
|
Prevents an TLSv1 connectiona. |
|
|
|
Prevents an TLSv1.1 connection. |
|
|
|
Prevents a TLSv1.2 connection. |
|
|
|
Prevents a TLSv1.3 connection. |
HTTP Cookie Attributes¶
By default, HTTP cookies used by Driverless AI are issued with the following attributes:
HTTPOnly
:True
SameSite
:Lax
If either of these needs to be overridden, or if more custom attributes need to be set, you can use the config http_cookie_attributes
to specify key-value pairs of so-called cookie morsels. For a list of supported keys, see the official Python documentation.
Response Headers¶
The response headers which are passed between Driverless AI server and client (browser, Python/R clients) are controlled via the following option:
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
See below |
Configure HTTP header returned in server response. |
Recommended Response Headers¶
Header |
Description |
Example value |
Link |
---|---|---|---|
|
The header lets a web site tell browsers that it
should only be accessed using HTTPS, instead of
using HTTP. The |
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security |
|
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting and data injection attacks. Controls from where the page can download source. |
Note: The Driverless AI is still requires to have |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://infosec.mozilla.org/guidelines/web_security#Examples_5 |
|
Controls where a page can get source to render
in a frame. The value here overrides the default,
which is |
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options |
|
Prevents the browser from trying to determine the content-type of a resource that is different than the declared content-type. |
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options |
|
The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. When value is set to 1 and a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts). |
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection |
Other Headers to Consider¶
Header |
Documentation |
---|---|
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS |
Web UI Security¶
Note
The Driverless AI UI is design to be user-friendly, and by default all features like auto-complete are enabled. Disabling the user-friendly features increases security of the application, but impacts user-friendliness and usability of the application.
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
|
Control auto-completion in Web UI elements (e.g., login inputs). |
|
|
|
Disable use of web browser local storage. |
|
|
|
Show all available data sources in WebUI (even though there are not configured). It is recommended to show only configured data sources. |
|
|
|
Verifies each request IP against IP which initialized the session. |
|
|
|
Disable concurrent sessions (logins). |
|
|
|
Enable XSRF (cross-site request forgery) protection. |
|
|
|
Enable SECURE cookie flag. Note that HTTPS must be enabled. |
Custom Recipe Security¶
Note
By default Driverless AI enables custom recipes as a main route for the way data-science teams can extend the application capabilities. In enterprise environments, it is recommended to follow best software engineering practices for development of custom recipes (i.e., code reviews, testing, stage releasing, etc.) and bundle only a pre-defined and approved set of custom Driverless AI extensions.
Option |
Default Value |
Recommended Value |
Description |
---|---|---|---|
|
|
|
Enable custom Python recipes. |
|
|
|
Enable uploading of custom recipes. |
|
|
|
Enable downloading of custom recipes from external URL. |
|
|
|
Include custom recipes in default inclusion lists. (warning: enables all custom recipes) |
|
|
|
Enable code static analysis for custom recipes |
Note
custom_recipe_security_analysis_enabled
is disabled by default, because enabling it can cause problems with
old experiments using recipes, which cannot pass security analysis. Due to that, you may not be able to score new datasets
with those experiments and you’ll need to re-upload the recipes again. It is still recommended to enable this
options for security reasons.
Configuration Security¶
Driverless AI provides the option to store sensitive or secure configuration information in an encrypted keystore as an alternative to keeping security settings as clear text in the config.toml file. Encrypting sensitive information is highly recommended. For more information, see Configuration Security.
Baseline Secure Configuration¶
The following Driverless AI configuration is an example of secure configuration. Ensure that all necessary config options are specified. For more information, see Using the config.toml File.
#
# Authentication
#
# Configure auth method
authentication_method="PAM"
# Redirect user to login page after 24 hours
authentication_default_timeout_hours=24
#
# Data
#
# Configure available connectors
enabled_file_systems="hdfs"
show_all_filesystems=false
# Restrict downloads
enable_dataset_downloading=false
#
# Logs
#
# Enable removal of audit log records every five days
audit_log_retention_period=5
# Disable collection of server logs
collect_server_logs_in_experiment_logs=false
#
# User data isolation
#
# Disable access to DAI data_directory from file browser
file_hide_data_directory=true
# (Optional) Enable usage of path filters
# file_path_filtering_enabled=true
# (Optional) Specify a list of absolute path prefixes to restrict access to in file browser
# file_path_filter_include = "['/data']")
# (Optional) Specify a directory containing updated AutoDoc templates
# autodoc_additional_template_folder = ""
#
# Client-Server Communication
#
enable_https=true
ssl_key_file="<<FILL ME>>"
ssl_crt_file="<<FILL ME>>"
# (Optional) Disable support of TLSv1.2 on server side only if your environment supports TLSv1.3
# ssl_no_tlsv1_2=true
#
# Web UI security
#
allow_form_autocomplete=false
allow_localstorage=false
verify_session_ip=true
allow_concurrent_sessions=false
enable_xsrf_protection=true
extra_http_headers='{ "Strict-Transport-Security":"max-age=63072000","Content-Security-Policy":"default-src https: ; font-src \'self\'; script-src \'self\' \'unsafe-eval\' \'unsafe-inline\'; style-src \'self\' \'unsafe-inline\'; object-src \'none\'", "X-Frame-Options":"deny", "X-Content-Type-Options":"nosniff", "X-XSS-Protection":"1; mode=block" }'
#
# Custom Recipes
#
enable_custom_recipes=false
enable_custom_recipes_upload=false
enable_custom_recipes_from_url=false
include_custom_recipes_by_default=false
custom_recipe_security_analysis_enabled=true