[DNM] mon, cephfs: Add auth caps for CephFS fsids by fullerdj · Pull Request #26855 · ceph/ceph

fullerdj · 2019-03-08T16:23:52Z

Add new mon and mds auth caps to restrict access based on fsid.

DNM for now because there is no test yet.

batrick · 2019-03-08T18:08:09Z

PendingReleaseNotes

+  clients based on a new auth cap:
+  [mon] allow rw; allow fsid=1; allow fsid=2
+* Communication with MDS daemons may now be restricted using a new auth cap:
+  [mds] allow fsid=1


Like mds allow rw fsid=1?

This implementation doesn't have a read-only variant. If you're restricted by fsid, the mds will drop all messages for unauthorized fsids. Do we want a read-only variant?

This implementation doesn't have a read-only variant.

I think I was wondering if mds allow r fsid=1 would be allowed. That is, read-only MDS access although I'm not sure who uses that in practice; would that imply a read-only mount?

batrick · 2019-03-08T18:08:44Z

PendingReleaseNotes

+
+* The monitor cluster may now withhold filesystem and/or MDS information from
+  clients based on a new auth cap:
+  [mon] allow rw; allow fsid=1; allow fsid=2


IIRC, the caps are additive. Wouldn't allow rw provide access to all MDSMaps?

batrick · 2019-03-08T18:10:27Z

doc/cephfs/client-auth.rst

+     key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw==
+     caps: [mds] allow rw, allow fsid=1
+     caps: [mon] allow r, allow fsid=1
+     caps: [osd] allow rw tag cephfs data=cephfs_a


I guess we also need to extend these OSDCaps to take an FSCID. Not urgent though.

Well, the OSD does not know the fscid. We could tag the pools with it, though.

The pools tags are good enough now I think. I don't believe we want to move forward anymore with shared data pools. The feature is no longer attractive with the pg_autoscaler.

batrick · 2019-03-08T18:19:38Z

src/mon/Monitor.cc

      }
-      if (mdsmon()->get_fsmap().filesystem_count() > 0) {
-	ss << "    mds: " << spacing << mdsmon()->get_fsmap() << "\n";
+      const FSMap *fsmapp = &mdsmon()->get_fsmap();


nit: const auto& fsmap would be better.

batrick · 2019-03-08T18:19:55Z

src/mon/Monitor.cc

-	ss << "    mds: " << spacing << mdsmon()->get_fsmap() << "\n";
+      const FSMap *fsmapp = &mdsmon()->get_fsmap();
+      if (!fsids.empty()) {
+	FSMap map = *fsmapp;


then just: FSMap map = fsmap.

liewegas · 2019-03-08T18:26:55Z

doc/cephfs/client-auth.rst

+
+ client.0
+     key: AQAz7EVWygILFRAAdIcuJ12opU/JKyfFmxhuaw==
+     caps: [mon] allow r, allow fsid=1, allow fsid=2


ditto. the first allow r applies to all fsids. the fsid= has to be a property of each allow to restrict it.

batrick · 2019-04-05T18:24:52Z

ping @fullerdj

fullerdj · 2019-04-05T18:27:56Z

ack, @batrick . I should be able to get back on this next week.

Now, progress events are part of `WriteCompletion` istead of part of the orchestrator module. It does not yet provide a way to just show orchestrator events. Also fixes issue in the SSH orchestrator Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>

The previous link was to version 2, which is a bit older. Fix to version 3. Signed-off-by: Yaniv Kaul <ykaul@redhat.com>

Add a 'fsid' clause to mon auth caps to restrict a client's view of the FSMap. Example: mon 'allow rw; allow fsid 2' This would restrict the client's view of the FSMap to the MDSMap for fscid 2. Any MDS allocated to a different filesystem will be invisible. Global standby daemons are always visible. To allow multiple fscids, add multiple caps: mon 'allow rw; allow fsid 2; allow fsid 3' Fixes: http://tracker.ceph.com/issues/15070 Signed-off-by: Douglas Fuller <dfuller@redhat.com>

Modify MMDSMap to include the global ID of the Filesystem from the FSMap when bringing up a new MDS. Store the ID in the MDSRank structure for use in security validation. Fixes: http://tracker.ceph.com/issues/15070 Signed-off-by: Douglas Fuller <dfuller@redhat.com>

Add new auth caps to restrict access to clients based on fsid. To specify this, for example: mds 'allow fsid=1' This will restrict client access to fsid 1 only. Messages to active MDS assigned to any other FSMap will be dropped. Standby MDS not associated with an FSMap will accept messages from clients so restricted. Fixes: http://tracker.ceph.com/issues/15070 Signed-off-by: Douglas Fuller <dfuller@redhat.com>

stale · 2019-07-09T15:32:27Z

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

stale · 2019-09-07T17:25:26Z

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

stale · 2019-11-13T23:42:47Z

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

stale · 2020-01-13T19:43:45Z

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

fullerdj · 2020-01-13T19:50:34Z

closed in favor of #32581

fullerdj added feature cephfs Ceph File System needs-test mon DNM labels Mar 8, 2019

fullerdj requested a review from batrick March 8, 2019 16:23

fullerdj force-pushed the wip-djf-15070 branch from 7d2343d to ca0c88e Compare March 8, 2019 16:35

batrick reviewed Mar 8, 2019

View reviewed changes

batrick requested review from gregsfortytwo and liewegas March 8, 2019 18:20

liewegas reviewed Mar 8, 2019

View reviewed changes

sebastian-philipp and others added 2 commits May 9, 2019 16:06

doc: Update link to Red Hat documentation

d70d189

The previous link was to version 2, which is a bit older. Fix to version 3. Signed-off-by: Yaniv Kaul <ykaul@redhat.com>

fullerdj force-pushed the wip-djf-15070 branch from ca0c88e to db63ece Compare May 9, 2019 20:09

Douglas Fuller added 3 commits May 10, 2019 10:35

fullerdj force-pushed the wip-djf-15070 branch from db63ece to e124271 Compare May 10, 2019 14:35

stale bot added the stale label Jul 9, 2019

batrick removed the stale label Jul 10, 2019

stale bot added the stale label Sep 7, 2019

batrick assigned fullerdj Sep 14, 2019

stale bot removed the stale label Sep 14, 2019

stale bot added stale and removed stale labels Nov 13, 2019

rishabh-d-dave mentioned this pull request Jan 9, 2020

mon, cephfs: Add auth caps for CephFS fsids #32581

Merged

3 tasks

stale bot added the stale label Jan 13, 2020

fullerdj closed this Jan 13, 2020

Conversation

fullerdj commented Mar 8, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

batrick commented Apr 5, 2019

Uh oh!

fullerdj commented Apr 5, 2019

Uh oh!

stale bot commented Jul 9, 2019

Uh oh!

stale bot commented Sep 7, 2019

Uh oh!

stale bot commented Nov 13, 2019

Uh oh!

stale bot commented Jan 13, 2020

Uh oh!

fullerdj commented Jan 13, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants