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 |