]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | ================================ |
2 | CephFS Client Capabilities | |
3 | ================================ | |
4 | ||
9f95a23c | 5 | Use Ceph authentication capabilities to restrict your file system clients |
7c673cae FG |
6 | to the lowest possible level of authority needed. |
7 | ||
f67539c2 | 8 | .. note:: Path restriction and layout modification restriction are new features |
7c673cae FG |
9 | in the Jewel release of Ceph. |
10 | ||
f67539c2 | 11 | .. note:: Using Erasure Coded(EC) pools with CephFS is supported only with the |
9f95a23c TL |
12 | BlueStore Backend. They cannot be used as metadata pools and overwrites must |
13 | be enabled on the data pools. | |
14 | ||
15 | ||
7c673cae FG |
16 | Path restriction |
17 | ================ | |
18 | ||
f67539c2 TL |
19 | By default, clients are not restricted in what paths they are allowed to |
20 | mount. Further, when clients mount a subdirectory, e.g., ``/home/user``, the | |
21 | MDS does not by default verify that subsequent operations are ‘locked’ within | |
22 | that directory. | |
7c673cae FG |
23 | |
24 | To restrict clients to only mount and work within a certain directory, use | |
25 | path-based MDS authentication capabilities. | |
26 | ||
27 | Syntax | |
28 | ------ | |
29 | ||
30 | To grant rw access to the specified directory only, we mention the specified | |
f67539c2 | 31 | directory while creating key for a client using the following syntax:: |
7c673cae | 32 | |
f67539c2 | 33 | ceph fs authorize <fs_name> client.<client_id> <path-in-cephfs> rw |
7c673cae | 34 | |
f67539c2 TL |
35 | For example, to restrict client ``foo`` to writing only in the ``bar`` |
36 | directory of file system ``cephfs_a``, use :: | |
7c673cae | 37 | |
92f5a8d4 | 38 | ceph fs authorize cephfs_a client.foo / r /bar rw |
7c673cae | 39 | |
11fdf7f2 TL |
40 | results in: |
41 | ||
42 | client.foo | |
43 | key: *key* | |
44 | caps: [mds] allow r, allow rw path=/bar | |
45 | caps: [mon] allow r | |
46 | caps: [osd] allow rw tag cephfs data=cephfs_a | |
47 | ||
7c673cae | 48 | To completely restrict the client to the ``bar`` directory, omit the |
d2e6a577 | 49 | root directory :: |
7c673cae | 50 | |
92f5a8d4 | 51 | ceph fs authorize cephfs_a client.foo /bar rw |
7c673cae FG |
52 | |
53 | Note that if a client's read access is restricted to a path, they will only | |
9f95a23c | 54 | be able to mount the file system when specifying a readable path in the |
7c673cae FG |
55 | mount command (see below). |
56 | ||
9f95a23c | 57 | Supplying ``all`` or ``*`` as the file system name will grant access to every |
f67539c2 TL |
58 | file system. Note that it is usually necessary to quote ``*`` to protect it |
59 | from the shell. | |
7c673cae | 60 | |
f67539c2 TL |
61 | See `User Management - Add a User to a Keyring`_. for additional details on |
62 | user management | |
7c673cae | 63 | |
f67539c2 TL |
64 | To restrict a client to the specified sub-directory only, we mention the |
65 | specified directory while mounting using the following syntax:: | |
7c673cae | 66 | |
f67539c2 | 67 | ceph-fuse -n client.<client_id> <mount-path> -r *directory_to_be_mounted* |
7c673cae | 68 | |
f67539c2 TL |
69 | For example, to restrict client ``foo`` to ``mnt/bar`` directory, we will |
70 | use:: | |
7c673cae | 71 | |
f67539c2 | 72 | ceph-fuse -n client.foo mnt -r /bar |
7c673cae FG |
73 | |
74 | Free space reporting | |
75 | -------------------- | |
76 | ||
77 | By default, when a client is mounting a sub-directory, the used space (``df``) | |
78 | will be calculated from the quota on that sub-directory, rather than reporting | |
79 | the overall amount of space used on the cluster. | |
80 | ||
9f95a23c | 81 | If you would like the client to report the overall usage of the file system, |
7c673cae | 82 | and not just the quota usage on the sub-directory mounted, then set the |
f67539c2 | 83 | following config option on the client:: |
7c673cae | 84 | |
7c673cae FG |
85 | |
86 | client quota df = false | |
87 | ||
88 | If quotas are not enabled, or no quota is set on the sub-directory mounted, | |
9f95a23c | 89 | then the overall usage of the file system will be reported irrespective of |
7c673cae FG |
90 | the value of this setting. |
91 | ||
7c673cae FG |
92 | Layout and Quota restriction (the 'p' flag) |
93 | =========================================== | |
94 | ||
95 | To set layouts or quotas, clients require the 'p' flag in addition to 'rw'. | |
96 | This restricts all the attributes that are set by special extended attributes | |
97 | with a "ceph." prefix, as well as restricting other means of setting | |
98 | these fields (such as openc operations with layouts). | |
99 | ||
11fdf7f2 | 100 | For example, in the following snippet client.0 can modify layouts and quotas |
f67539c2 | 101 | on the file system cephfs_a, but client.1 cannot:: |
7c673cae FG |
102 | |
103 | client.0 | |
104 | key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw== | |
105 | caps: [mds] allow rwp | |
106 | caps: [mon] allow r | |
11fdf7f2 | 107 | caps: [osd] allow rw tag cephfs data=cephfs_a |
7c673cae FG |
108 | |
109 | client.1 | |
110 | key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw== | |
111 | caps: [mds] allow rw | |
112 | caps: [mon] allow r | |
11fdf7f2 TL |
113 | caps: [osd] allow rw tag cephfs data=cephfs_a |
114 | ||
115 | ||
116 | Snapshot restriction (the 's' flag) | |
117 | =========================================== | |
118 | ||
f67539c2 TL |
119 | To create or delete snapshots, clients require the 's' flag in addition to |
120 | 'rw'. Note that when capability string also contains the 'p' flag, the 's' | |
121 | flag must appear after it (all flags except 'rw' must be specified in | |
122 | alphabetical order). | |
11fdf7f2 TL |
123 | |
124 | For example, in the following snippet client.0 can create or delete snapshots | |
f67539c2 | 125 | in the ``bar`` directory of file system ``cephfs_a``:: |
11fdf7f2 TL |
126 | |
127 | client.0 | |
128 | key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw== | |
129 | caps: [mds] allow rw, allow rws path=/bar | |
130 | caps: [mon] allow r | |
131 | caps: [osd] allow rw tag cephfs data=cephfs_a | |
7c673cae FG |
132 | |
133 | ||
134 | .. _User Management - Add a User to a Keyring: ../../rados/operations/user-management/#add-a-user-to-a-keyring | |
11fdf7f2 TL |
135 | |
136 | Network restriction | |
137 | =================== | |
138 | ||
139 | :: | |
140 | ||
141 | client.foo | |
142 | key: *key* | |
143 | caps: [mds] allow r network 10.0.0.0/8, allow rw path=/bar network 10.0.0.0/8 | |
144 | caps: [mon] allow r network 10.0.0.0/8 | |
145 | caps: [osd] allow rw tag cephfs data=cephfs_a network 10.0.0.0/8 | |
146 | ||
147 | The optional ``{network/prefix}`` is a standard network name and | |
148 | prefix length in CIDR notation (e.g., ``10.3.0.0/16``). If present, | |
149 | the use of this capability is restricted to clients connecting from | |
150 | this network. | |
f67539c2 TL |
151 | |
152 | .. _fs-authorize-multifs: | |
153 | ||
154 | File system Information Restriction | |
155 | =================================== | |
156 | ||
157 | If desired, the monitor cluster can present a limited view of the file systems | |
158 | available. In this case, the monitor cluster will only inform clients about | |
159 | file systems specified by the administrator. Other file systems will not be | |
160 | reported and commands affecting them will fail as if the file systems do | |
161 | not exist. | |
162 | ||
163 | Consider following example. The Ceph cluster has 2 FSs:: | |
164 | ||
165 | $ ceph fs ls | |
166 | name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ] | |
167 | name: cephfs2, metadata pool: cephfs2_metadata, data pools: [cephfs2_data ] | |
168 | ||
169 | But we authorize client ``someuser`` for only one FS:: | |
170 | ||
171 | $ ceph fs authorize cephfs client.someuser / rw | |
172 | [client.someuser] | |
173 | key = AQAmthpf89M+JhAAiHDYQkMiCq3x+J0n9e8REQ== | |
174 | $ cat ceph.client.someuser.keyring | |
175 | [client.someuser] | |
176 | key = AQAmthpf89M+JhAAiHDYQkMiCq3x+J0n9e8REQ== | |
177 | caps mds = "allow rw fsname=cephfs" | |
178 | caps mon = "allow r fsname=cephfs" | |
179 | caps osd = "allow rw tag cephfs data=cephfs" | |
180 | ||
181 | And the client can only see the FS that it has authorization for:: | |
182 | ||
183 | $ ceph fs ls -n client.someuser -k ceph.client.someuser.keyring | |
184 | name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ] | |
185 | ||
186 | Standby MDS daemons will always be displayed. Note that the information about | |
187 | restricted MDS daemons and file systems may become available by other means, | |
188 | such as ``ceph health detail``. | |
189 | ||
190 | MDS communication restriction | |
191 | ============================= | |
192 | ||
193 | By default, user applications may communicate with any MDS, whether or not | |
194 | they are allowed to modify data on an associated file system (see | |
195 | `Path restriction` above). Client's communication can be restricted to MDS | |
196 | daemons associated with particular file system(s) by adding MDS caps for that | |
197 | particular file system. Consider the following example where the Ceph cluster | |
198 | has 2 FSs:: | |
199 | ||
200 | $ ceph fs ls | |
201 | name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ] | |
202 | name: cephfs2, metadata pool: cephfs2_metadata, data pools: [cephfs2_data ] | |
203 | ||
204 | Client ``someuser`` is authorized only for one FS:: | |
205 | ||
206 | $ ceph fs authorize cephfs client.someuser / rw | |
207 | [client.someuser] | |
208 | key = AQBPSARfg8hCJRAAEegIxjlm7VkHuiuntm6wsA== | |
209 | $ ceph auth get client.someuser > ceph.client.someuser.keyring | |
210 | exported keyring for client.someuser | |
211 | $ cat ceph.client.someuser.keyring | |
212 | [client.someuser] | |
213 | key = AQBPSARfg8hCJRAAEegIxjlm7VkHuiuntm6wsA== | |
214 | caps mds = "allow rw fsname=cephfs" | |
215 | caps mon = "allow r" | |
216 | caps osd = "allow rw tag cephfs data=cephfs" | |
217 | ||
218 | Mounting ``cephfs1`` with ``someuser`` works:: | |
219 | ||
220 | $ sudo ceph-fuse /mnt/cephfs1 -n client.someuser -k ceph.client.someuser.keyring --client-fs=cephfs | |
221 | ceph-fuse[96634]: starting ceph client | |
222 | ceph-fuse[96634]: starting fuse | |
223 | $ mount | grep ceph-fuse | |
224 | ceph-fuse on /mnt/cephfs1 type fuse.ceph-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other) | |
225 | ||
226 | But mounting ``cephfs2`` does not:: | |
227 | ||
228 | $ sudo ceph-fuse /mnt/cephfs2 -n client.someuser -k ceph.client.someuser.keyring --client-fs=cephfs2 | |
229 | ceph-fuse[96599]: starting ceph client | |
230 | ceph-fuse[96599]: ceph mount failed with (1) Operation not permitted | |
231 | ||
232 | Root squash | |
233 | =========== | |
234 | ||
235 | The ``root squash`` feature is implemented as a safety measure to prevent | |
236 | scenarios such as accidental ``sudo rm -rf /path``. You can enable | |
237 | ``root_squash`` mode in MDS caps to disallow clients with uid=0 or gid=0 to | |
238 | perform write access operations -- e.g., rm, rmdir, rmsnap, mkdir, mksnap. | |
239 | However, the mode allows the read operations of a root client unlike in | |
240 | other file systems. | |
241 | ||
242 | Following is an example of enabling root_squash in a filesystem except within | |
243 | '/volumes' directory tree in the filesystem:: | |
244 | ||
245 | $ ceph fs authorize a client.test_a / rw root_squash /volumes rw | |
246 | $ ceph auth get client.test_a | |
247 | [client.test_a] | |
248 | key = AQBZcDpfEbEUKxAADk14VflBXt71rL9D966mYA== | |
249 | caps mds = "allow rw fsname=a root_squash, allow rw fsname=a path=/volumes" | |
250 | caps mon = "allow r fsname=a" | |
251 | caps osd = "allow rw tag cephfs data=a" |