- Cromwell is NOT on its own a security appliance!
- Only YOU are responsible for your own security!
- Please be sure to check with your security team before setting up your Cromwell server
- Some recommendations and suggestions on security can be found below
This is intended as helpful guidance only, and is not endorsed by the Broad Institute.
Cromwell running in server mode accepts all connections on the configured webservice port. Without taking additional measures to protect your Cromwell server, this can leave your Cromwell server and therefore all information stored by and accessible by your Cromwell server vulnerable to anyone who is able to access the server. For instance, an unprotected Cromwell server running against the Google Cloud backend would leave you vulnerable to outside users running workflows that will cost you money, and potentially access the data files you use within your workflows!
The simplest way to restrict access is by putting an authenticating proxy server in between users and the Cromwell server:
- Configure a firewall rule on the Cromwell server host to deny access to the webservice port (e.g. 8000) from all addresses except a secure proxy host.
<YourFavoriteWebProxy>on the proxy host with
<YourFavoriteAuthMechanism>, to proxy authenticated traffic from the world to the Cromwell server. Using Apache
httpdweb server for example with basic
htpasswordfile-based authentication, the configuration might look something like:
<Location /cromwell> Order deny,allow Allow from all AuthType Basic AuthName "Password Required" AuthUserFile /path/to/my/htpasswdfile Require user someone someoneelse ProxyPass http://184.108.40.2067:8000 # address of cromwell server web service </Location>
Users now hit
http://my.proxy.org/cromwell with authenticated requests, and they're forwarded to port 8000 on the Cromwell server host.
Multiple Servers on one Host
The above scheme extends easily to multiple Cromwell instances, for use by different groups within an organization, for example. If multiple instances are running on the same host, then each instance should be run as its own dedicated user (such as service account when using a Google Cloud backend), e.g.
cromwell2 etc so that processes running under one Cromwell instance cannot access the files of another. Different webservice ports must also be configured separately in order to not clash. If persistent database storage is being used, then each instance must be configured with its own database. The proxy configuration above is extended simply by adding another
<Location /cromwell1> Order deny,allow Allow from all AuthType Basic AuthName "Password Required" AuthUserFile /path/to/my/htpasswdfile1 Require user stillanotherperson andanother ProxyPass http://220.127.116.117:8001 </Location>
Multiple Tenants in one Cromwell Server
Even with a proxy in place, a single Cromwell server does not provide authorization for individual users hitting the endpoints. This allows, for instance, one authenticated user to view the metadata for a workflow run by another authenticated user. Due to this limitation, it is important that all users of this Cromwell server be trusted.
With the exception of the use of the
google_compute_service_account scheme in the Configuration for the Google Cloud backend), Cromwell servers are setup to access files for use in workflows using a single set of credentials. This means that all users of these Cromwell servers will have access to the same files that any other user has access to. The
google_compute_service_account scheme is the only way to ensure data is protected among multiple users of a Cromwell server, however the aforementioned caveats of authorization for endpoints still applies.
Various parts of the Cromwell server Configuration contain sensitive information, e.g. username and password for your persistent database. It is strongly recommended to protect the configuration files from any untrusted users, for instance by limiting who can access your Cromwell server host or using a technology such as HashiCorp Vault.
Additionally, the contents of the Cromwell database can contain sensitive information, so it is recommended to limit the access of the database only to trusted users.