doc/admin/restricting-upload-download.html.textile.liquid

   1 ---
   2 layout: default
   3 navsection: admin
   4 title: Restricting upload or download
   5 ...
   6
   7 {% comment %}
   8 Copyright (C) The Arvados Authors. All rights reserved.
   9
  10 SPDX-License-Identifier: CC-BY-SA-3.0
  11 {% endcomment %}
  12
  13 For some use cases, you may want to limit the ability of users to upload or download data from outside the cluster.  (By "outside" we mean from networks other than the cluster's own private network).  For example, this makes it possible to share restricted data sets with users so that they may run their own data analysis on the cluster, while preventing them from easily downloading the data set to their local workstation.
  14
  15 This feature exists in addition to the existing Arvados permission system.  Users can only download from collections they have @read@ access to, and can only upload to projects and collections they have @write@ access to.
  16
  17 There are two services involved in accessing data from outside the cluster.
  18
  19 h2. Keepproxy Permissions
  20
  21 Permitting @keepproxy@ makes it possible to use @arv-put@ and @arv-get@.  It works in terms of individual 64 MiB keep blocks.  It prints a log line each time a user uploads or downloads an individual block. Those logs are usually stored by @journald@ or @syslog@.
  22
  23 The default policy allows anyone to upload or download.
  24
  25 <pre>
  26     Collections:
  27       KeepproxyPermission:
  28         User:
  29           Download: true
  30           Upload: true
  31         Admin:
  32           Download: true
  33           Upload: true
  34 </pre>
  35
  36 h2. WebDAV and S3 API Permissions
  37
  38 Permitting @WebDAV@ makes it possible to use WebDAV, S3 API, and upload/download with Workbench 2.  It works in terms of individual files.  It prints a log each time a user uploads or downloads a file.  When @WebDAVLogEvents@ (default true) is enabled, it also adds an entry into the API server @logs@ table.
  39
  40 When a user attempts to upload or download from a service without permission, they will receive a @403 Forbidden@ response.  This only applies to file content.
  41
  42 Denying download permission does not deny access to access to XML file listings with PROPFIND, or auto-generated HTML documents containing file listings.
  43
  44 Denying upload permission does not deny other operations that modify collections without directly accessing file content, such as MOVE and COPY.
  45
  46 The default policy allows anyone to upload or download.
  47
  48 <pre>
  49     Collections:
  50       WebDAVPermission:
  51         User:
  52           Download: true
  53           Upload: true
  54         Admin:
  55           Download: true
  56           Upload: true
  57       WebDAVLogEvents: true
  58       </pre>
  59
  60 When a user or admin creates a sharing link, a custom scoped token is embedded in that link. This effectively allows anonymous user access to the associated data via that link. These custom scoped tokens are always treated as user tokens for the purposes of restricting download access, even when created by an admin user. In other words, these custom scoped tokens, when used in a sharing link, are always subject to the value of the @WebDAVPermission/User/Download@ configuration setting.
  61
  62 If that custom scoped token is used with @arv-get@, its use will be subject to the value of the @KeepproxyPermission/User/Download@ configuration setting.
  63
  64 h2. Shell node and container permissions
  65
  66 Be aware that even when upload and download from outside the network is not allowed, a user who has access to a shell node or runs a container still has internal access to Keep.  (This is necessary to be able to run workflows).  From the shell node or container, a user could send data outside the network by some other method, although this requires more intent than accidentally clicking on a link and downloading a file.  It is possible to set up a firewall to prevent shell and compute nodes from making connections to hosts outside the private network.  Exactly how to configure firewalls is out of scope for this page, as it depends on the specific network infrastructure of your cluster.
  67
  68 h2. Choosing a policy
  69
  70 This distinction between WebDAV and Keepproxy is important for auditing.  WebDAV records 'upload' and 'download' events on the API server that are included in the "User Activity Report":user-activity.html,  whereas @keepproxy@ only logs upload and download of individual blocks, which require a reverse lookup to determine the collection(s) and file(s) a block is associated with.
  71
  72 You set separate permissions for @WebDAV@ and @Keepproxy@, with separate policies for regular users and admin users.
  73
  74 These policies apply to only access from outside the cluster, using Workbench or Arvados CLI tools.
  75
  76 The @WebDAVLogEvents@ option should be enabled if you intend to the run the "User Activity Report":user-activity.html .  If you don't need audits, or you are running a site that is mostly serving public data to anonymous downloaders, you can disable in to avoid the extra API server request.
  77
  78 h3. Audited downloads
  79
  80 For ease of access auditing, this policy prevents downloads using @arv-get@.  Downloads through WebDAV and S3 API are permitted, but logged.  Uploads are allowed.
  81
  82 <pre>
  83     Collections:
  84       WebDAVPermission:
  85         User:
  86           Download: true
  87           Upload: true
  88         Admin:
  89           Download: true
  90           Upload: true
  91
  92       KeepproxyPermission:
  93         User:
  94           Download: false
  95           Upload: true
  96         Admin:
  97           Download: false
  98           Upload: true
  99       WebDAVLogEvents: true
 100 </pre>
 101
 102 h3. Disallow downloads by regular users
 103
 104 This policy prevents regular users (non-admin) from downloading data.  Uploading is allowed.  This supports the case where restricted data sets are shared with users so that they may run their own data analysis on the cluster, while preventing them from downloading the data set to their local workstation.  Be aware that users won't be able to download the results of their analysis, either, requiring an admin in the loop or some other process to release results.
 105
 106 <pre>
 107     Collections:
 108       WebDAVPermission:
 109         User:
 110           Download: false
 111           Upload: true
 112         Admin:
 113           Download: true
 114           Upload: true
 115
 116       KeepproxyPermission:
 117         User:
 118           Download: false
 119           Upload: true
 120         Admin:
 121           Download: true
 122           Upload: true
 123       WebDAVLogEvents: true
 124 </pre>
 125
 126 h3. Disallow uploads by regular users
 127
 128 This policy is suitable for an installation where data is being shared with a group of users who are allowed to download the data, but not permitted to store their own data on the cluster.
 129
 130 <pre>
 131     Collections:
 132       WebDAVPermission:
 133         User:
 134           Download: true
 135           Upload: false
 136         Admin:
 137           Download: true
 138           Upload: true
 139
 140       KeepproxyPermission:
 141         User:
 142           Download: true
 143           Upload: false
 144         Admin:
 145           Download: true
 146           Upload: true
 147       WebDAVLogEvents: true
 148 </pre>
 149
 150
 151 h2(#audit_log). Accessing the audit log
 152
 153 When @WebDAVLogEvents@ is enabled, uploads and downloads of files are logged in the Arvados audit log. These events are included in the "User Activity Report":user-activity.html. The audit log can also be accessed via the API, SDKs or command line. For example, to show the 100 most recent file downloads:
 154
 155 <pre>
 156 arv log list --filters '[["event_type","=","file_download"]]' -o 'created_at desc' -l 100
 157 </pre>
 158
 159 For uploads, use the @file_upload@ event type.
 160
 161 Note that this only covers upload and download activity via WebDAV, S3, and Workbench 2.
 162
 163 The @arv-get@ and @arv-put@ tools upload via @Keepproxy@, which does not log activity to the audit log because it operates at the block level, not the file level. @Keepproxy@ records the uuid of the user that owns the token used in the request in its system logs. Those logs are usually stored by @journald@ or @syslog@. A typical log line for such a block download looks like this:
 164
 165 <pre>
 166 Jul 20 15:03:38 keep.xxxx1.arvadosapi.com keepproxy[63828]: {"level":"info","locator":"abcdefghijklmnopqrstuvwxyz012345+53251584","msg":"Block download","time":"2021-07-20T15:03:38.458792300Z","user_full_name":"Albert User","user_uuid":"ce8i5-tpzed-abcdefghijklmno"}
 167 </pre>
 168
 169 It is possible to do a reverse lookup from the locator to find all matching collections: the @manifest_text@ field of a collection lists all the block locators that are part of the collection. The @manifest_text@ field also provides the relevant filename in the collection. Because this lookup is rather involved and there is no automated tool to do it, we recommend disabling @KeepproxyPermission.User.Download@ and @KeepproxyPermission.User.Upload@ for sites where the audit log is important and @arv-get@ and @arv-put@ are not essential.