The Keep-web server provides read/write access to files stored in Keep using WebDAV and S3 protocols. This makes it easy to access files in Keep from a browser, or mount Keep as a network folder using WebDAV support in various operating systems. It serves public data to unauthenticated clients, and serves private data to clients that supply Arvados API tokens. It can be installed anywhere with access to Keep services, typically behind a web proxy that provides TLS support. See the godoc page for more detail.
It is important to properly configure the keep-web service to so it does not open up cross-site-scripting (XSS) attacks. A HTML file can be stored in collection. If an attacker causes a victim to visit that HTML file through Workbench, it will be rendered by the browser. If all collections are served at the same domain, the browser will consider collections as coming from the same origin and thus have access to the same browsing data (such as API token), enabling malicious Javascript in the HTML file to access Arvados as the victim.
There are two approaches to mitigate this.
keep-web is served on its own virtual host. This allows for file with executable content to be displayed in-browser securely. The virtual host embeds the collection uuid or portable data hash in the hostname. For example, a collection with uuid xxxxx-4zz18-tci4vn4fa95w0zx could be served as xxxxx-4zz18-tci4vn4fa95w0zx.collections.ClusterID.example.com . The portable data hash dd755dbc8d49a67f4fe7dc843e4f10a6+54 could be served at dd755dbc8d49a67f4fe7dc843e4f10a6-54.collections.ClusterID.example.com . This requires wildcard DNS record and wildcard TLS certificate.Downloads links will served from the URL in Services.WebDAVDownload.ExternalURL . The collection uuid or PDH is put in the URL path.
If blank, serve links to WebDAV with disposition=attachment query param. Unlike preview links, browsers do not render attachments, so there is no risk of XSS.
If WebDAVDownload is blank, and WebDAV has a single origin (not wildcard, see below), then Workbench will show an error page
Services:
WebDAVDownload:
ExternalURL: https://download.ClusterID.example.com
Collections will be served using the URL pattern in Services.WebDAV.ExternalURL . If blank, use Services.WebDAVDownload.ExternalURL instead, and disable inline preview. If both are empty, downloading collections from workbench will be impossible. When wildcard domains configured, credentials are still required to access non-public data.
Collections can be served from their own subdomain:
Services:
WebDAV:
ExternalURL: https://*.collections.ClusterID.example.com/
This option is preferred if you plan to access Keep using third-party S3 client software, because it accommodates S3 virtual host-style requests and path-style requests without any special client configuration.
Alternately, they can go under the main domain by including --:
Services:
WebDAV:
ExternalURL: https://*--collections.ClusterID.example.com/
Serve preview links from a single domain, setting uuid or pdh in the path (similar to downloads). This configuration only allows previews of public data (data accessible by the anonymous user) and collection-sharing links (where the token is already embedded in the URL); it will ignore authorization headers, so a request for non-public data may return “404 Not Found” even if normally valid credentials were provided.
Services:
WebDAV:
ExternalURL: https://collections.ClusterID.example.com/
Note the trailing slash.
Whether you choose to serve collections from their own subdomain or from a single domain, it’s important to keep in mind that they should be served from me same site as Workbench for the inline previews to work.
Please check keep-web’s URL pattern guide to learn more.
Services:
WebDAV:
InternalURLs:
http://localhost:9002: {}
If you intend to use Keep-web to serve public data to anonymous clients, configure it with an anonymous token.
Generate a random string (>= 32 characters long) and put it in the config.yml file, in the AnonymousUserToken field.
Users:
AnonymousUserToken: "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
Set Users.AnonymousUserToken: "" (empty string) or leave it out if you do not want to serve public data.
Put a reverse proxy with SSL support in front of keep-web. Keep-web itself runs on the port 9002 (or whatever is specified in Services.WebDAV.InternalURL) while the reverse proxy runs on port 443 and forwards requests to Keep-web.
Use a text editor to create a new file /etc/nginx/conf.d/keep-web.conf with the following configuration. Options that need attention are marked in red.
upstream keep-web {
server 127.0.0.1:9002;
}
server {
listen 443 ssl;
server_name download.ClusterID.example.com
collections.ClusterID.example.com
*.collections.ClusterID.example.com
~.*--collections.ClusterID.example.com;
proxy_connect_timeout 90s;
proxy_read_timeout 300s;
ssl on;
ssl_certificate /YOUR/PATH/TO/cert.pem;
ssl_certificate_key /YOUR/PATH/TO/cert.key;
location / {
proxy_pass http://keep-web;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 0;
proxy_http_version 1.1;
proxy_request_buffering off;
proxy_max_temp_file_size 0;
}
}
If you restrict access to your Arvados services based on network topology — for example, your proxy server is not reachable from the public internet — additional proxy configuration might be needed to thwart cross-site scripting attacks that would circumvent your restrictions.
Normally, Keep-web accepts requests for multiple collections using the same host name, provided the client’s credentials are not being used. This provides insufficient XSS protection in an installation where the “anonymously accessible” data is not truly public, but merely protected by network topology.
In such cases — for example, a site which is not reachable from the internet, where some data is world-readable from Arvados’s perspective but is intended to be available only to users within the local network — the downstream proxy should configured to return 401 for all paths beginning with “/c=”
# dnf install keep-web
# apt-get install keep-web
# systemctl enable --now keep-web
# systemctl status keep-web
[...]
If systemctl status indicates it is not running, use journalctl to check logs for errors:
# journalctl -n12 --unit keep-web
Make sure the cluster config file is up to date on the API server host then restart the API server and controller processes to ensure the configuration changes are visible to the whole cluster.
# systemctl restart nginx arvados-controller
# arvados-server check
We recommend using the Cluster diagnostics tool.
Here are some other checks you can perform manually.
$ curl -H "Authorization: Bearer $system_root_token" https://download.ClusterID.example.com/c=59389a8f9ee9d399be35462a0f92541c-53/_/hello.txtIf wildcard collections domains are configured:
$ curl -H "Authorization: Bearer $system_root_token" https://59389a8f9ee9d399be35462a0f92541c-53.collections.ClusterID.example.com/hello.txtIf using a single collections preview domain:
$ curl https://collections.ClusterID.example.com/c=59389a8f9ee9d399be35462a0f92541c-53/t=$system_root_token/_/hello.txt
The content of this documentation is licensed under the
Creative
Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the
Apache License, Version 2.0.