Project

General

Profile

Strong AuthN and AuthZ for CephFS » History » Version 1

Jessica Mack, 06/09/2015 07:30 PM

1 1 Jessica Mack
h1. Strong AuthN and AuthZ for CephFS
2 1 Jessica Mack
3 1 Jessica Mack
h3. Summary
4 1 Jessica Mack
5 1 Jessica Mack
This is a proposal to address two security features:
6 1 Jessica Mack
# to add a kerberos plugin which can be used in place of cephx, marrying kerberos authentication with ceph capabilities;
7 1 Jessica Mack
# to address how POSIX ACLs may be both implemented and enforced by all of the client, MDS, and OSD.
8 1 Jessica Mack
9 1 Jessica Mack
h3. Owners
10 1 Jessica Mack
11 1 Jessica Mack
* Andrea Ieri, Andreas Peters, Dan van der Ster, Arne Wiebalck (all at CERN)
12 1 Jessica Mack
13 1 Jessica Mack
h3. Interested Parties
14 1 Jessica Mack
15 1 Jessica Mack
* Yan, Zheng (Intel)
16 1 Jessica Mack
* Greg Farnum (Inktank)
17 1 Jessica Mack
* Name
18 1 Jessica Mack
19 1 Jessica Mack
h3. Current Status
20 1 Jessica Mack
21 1 Jessica Mack
Conceptual phase.
22 1 Jessica Mack
23 1 Jessica Mack
h3. Detailed Description
24 1 Jessica Mack
25 1 Jessica Mack
The current security model of Ceph (cephx) authenticates users in similar way as Kerberos does: a client host authenticates to a monitor and acquires a session key which is subsequently used to communicate with the Ceph servers (mon, mds, osd).
26 1 Jessica Mack
This model is not well suited for shared environments like interactive clusters or personal desktop machines/laptops:
27 1 Jessica Mack
* the model relies on the fact that client machines can be trusted;
28 1 Jessica Mack
* the model authenticates the client machine (not the individual user, which would be needed for file system authorization checks like mode bits or ACLs);
29 1 Jessica Mack
* the model does not scale well operationally (key distribution, key management);
30 1 Jessica Mack
* the model cannot be integrated with existing authentication systems, like an Active Directory Domain Controller.
31 1 Jessica Mack
32 1 Jessica Mack
The first proposal is to kerberize Ceph, which can be used in place of cephx:
33 1 Jessica Mack
* users, not client hosts, should acquire per user service tickets for a Ceph service from a central KDC infrastructure outside Ceph;
34 1 Jessica Mack
* users should use the service ticket / session key pair to authenticate to Ceph;
35 1 Jessica Mack
* after having proven his identity, a user’s uid can now be used for any authorization (on the pool or for file system access), using either cephx-like capabilities and/or mode bits or POSIX ACLs.
36 1 Jessica Mack
37 1 Jessica Mack
Due to the similarity between cephx and kerberos, this should be a relatively simple change. Each kerberos user would still need to be known by Ceph (e.g. ceph auth create …) but Ceph would not store a secret for each user. For example, a kerb user could be:
38 1 Jessica Mack
<pre>
39 1 Jessica Mack
[client.krb.user1@REALM]
40 1 Jessica Mack
key = !krb/user1@REALM
41 1 Jessica Mack
caps mds = "allow"
42 1 Jessica Mack
caps mon = "allow r"
43 1 Jessica Mack
caps osd = "allow x, allow rwx pool=data, allow rwx pool=metadata"
44 1 Jessica Mack
</pre>
45 1 Jessica Mack
46 1 Jessica Mack
Or another approach would be to assign a default capability for all users in a kerberos realm, e.g.:
47 1 Jessica Mack
<pre>
48 1 Jessica Mack
[client.krb.*@REALM]
49 1 Jessica Mack
key = !krb/*@REALM
50 1 Jessica Mack
caps mds = "allow"
51 1 Jessica Mack
caps mon = "allow r"
52 1 Jessica Mack
caps osd = "allow x, allow rwx pool=data, allow rwx pool=metadata"
53 1 Jessica Mack
</pre>
54 1 Jessica Mack
55 1 Jessica Mack
The second aspect of this proposal is for the enforcement of POSIX ACLs by the MDS and OSDs. One security implication of the current CephFS implementation is that while users having the osd rwx pool=data capability may be blocked by ACLs enforcement on their kernel, these users may still bypass the MDS and modify any object in the data pool directly. This may lead to intentional or accidental data corruption, and hence, this mechanism needs adaptation to work with untrusted clients.
56 1 Jessica Mack
Since clients are not trusted, it is not useful to rely on the authorization checking on the client side. This is however currently done for the user/group/world mode bits and is also planned for more sophisticated ACL schemes.
57 1 Jessica Mack
To overcome this, the MDS could hand out time-limited signed leases for extra Ceph capabilities for a given user, pool and object name: as these leases are signed by the MDS with the service key, the client has no way to manipulate these while passing them on to the OSD. The current capabilities in Ceph seem sufficient for POSIX ACLs, so integrating the check of these additional capabilities should be relatively easy to integrate. The basic idea is that we would change each kerberos user’s (or realm default) base capabilities to exclude full rwx access to the data pools, e.g.
58 1 Jessica Mack
<pre>
59 1 Jessica Mack
[client.krb.*@REALM]
60 1 Jessica Mack
key = !krb/*@REALM
61 1 Jessica Mack
caps mds = "allow"
62 1 Jessica Mack
caps mon = "allow r"
63 1 Jessica Mack
caps osd = "allow x"
64 1 Jessica Mack
</pre>
65 1 Jessica Mack
66 1 Jessica Mack
And then in the signed lease, the MDS would generate an extra capability which would be temporarily appended to the base capabilities for the duration of a transaction, e.g. add
67 1 Jessica Mack
<pre>
68 1 Jessica Mack
caps osd = "allow rwx pool=data object_prefix=<CephFS object name>"
69 1 Jessica Mack
</pre>
70 1 Jessica Mack
71 1 Jessica Mack
This temporary additional capability would be sent and used only by the relevant OSDs, not appended to the main auth list on the MONs.
72 1 Jessica Mack
In Sage’s thesis, this concept is already mentioned (chapter 3.2.1: “File I/O capabilities”), but it is unclear how far this has gone in the actual CephFS code (at a quick glance it seems it is not there).
73 1 Jessica Mack
74 1 Jessica Mack
*Questions:*
75 1 Jessica Mack
* Can the shared secret (cephx client keys) be replaced by Kerberos session keys issued for a “Ceph Service” from a centralized standard KDC?
76 1 Jessica Mack
* Can an ACL implementation do the checks server-side to account for untrusted clients?
77 1 Jessica Mack
* Do capabilities need to stay for CephFS pools? If so, how do they interact with ACLs?
78 1 Jessica Mack
* What would be the expected performance impact of a kerberized CephFS?
79 1 Jessica Mack
* Should/could an implementation offer “security flavors” with varied encryption, like “none”, “only MDS”, “only header”, “full” to let users find their compromise between security and performance?
80 1 Jessica Mack
 
81 1 Jessica Mack
h3. Work items
82 1 Jessica Mack
83 1 Jessica Mack
h3. Coding tasks
84 1 Jessica Mack
85 1 Jessica Mack
# Task 1
86 1 Jessica Mack
# Task 2
87 1 Jessica Mack
# Task 3
88 1 Jessica Mack
89 1 Jessica Mack
h3. Build / release tasks
90 1 Jessica Mack
91 1 Jessica Mack
# Task 1
92 1 Jessica Mack
# Task 2
93 1 Jessica Mack
# Task 3
94 1 Jessica Mack
95 1 Jessica Mack
h3. Documentation tasks
96 1 Jessica Mack
97 1 Jessica Mack
# Task 1
98 1 Jessica Mack
# Task 2
99 1 Jessica Mack
# Task 3
100 1 Jessica Mack
101 1 Jessica Mack
h3. Deprecation tasks
102 1 Jessica Mack
103 1 Jessica Mack
# Task 1
104 1 Jessica Mack
# Task 2
105 1 Jessica Mack
# Task 3