On Wed, May 30, 2018 at 9:39 AM, Volker Theile <vtheile@xxxxxxxx> wrote: > > > Am 30.05.2018 um 16:27 schrieb Casey Bodley: >> >> On 05/30/2018 10:18 AM, Volker Theile wrote: >>> I've enhanced the RGW Admin OPS API to get the metadata of the user >>> without using the URL /admin/metadata/user?key=<username>, instead the >>> URL /admin/metadata/user?myself will return the metadata of the user >>> that is used to sign the request. >>> >>> You're asking what this is good for? >>> >>> In the Dashboard it is necessary to check if a RGW user that is going to >>> be deleted is not the user account that is used to access the RGW Admin >>> OPS API (see feature https://tracker.ceph.com/issues/24335). The problem >>> is that the Dashboard only knows about the access/secret key of the >>> administration account. With the above feature it is easy to retrieve >>> the user name of the administration account by requesting the metadata >>> via /admin/metadata/user?myself. >>> >>> You can find the already working implementation at >>> https://github.com/votdev/ceph/commit/581374fb22734ba3fd904407210add6351df59cd. >>> >>> >>> Is this a good approach or can this be done better? Feel free to comment >>> this email. >>> >>> >>> Volker >>> >> >> That looks reasonable enough to me. If the mgr/dashboard is the one >> creating this user, maybe it would be easier to store its user id >> along with the access/secret keys? > > That's an option and i already suggested this to make the user ID a > prerequisite, but the response was not overwhelming. > > Currently the dashboard has to be configured with > > $ ceph dashboard set-rgw-api-access-key <accesskey> > $ ceph dashboard set-rgw-api-secret-key <secretkey> > > and that's it. No more information is stored about the RGW Admin OPS API > administration account. These settings are required. But there is an > optional setting called > > $ ceph dashboard set-rgw-api-user-id <userid> > > but if this is not configured, it is not possible to find out if the > user that is going to be deleted is the admin account. To solve this my > proposal is to enhance the Admin OPS API to be able to fetch the > necessary information after the first connection has been established > and store the user ID during the session. > > By the way i think this enhancement is not only useful for exactly this > situation. > In the case of specifically specifying the uid there's the danger of providing the wrong uid. A workaround for this api would be to create a bucket, get its owner, remove it. But this is way cleaner. Yehuda > Volker > >> >> Casey >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > Volker Theile > Software Engineer | openATTIC > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) > Phone: +49 173 5876879 > E-Mail: vtheile@xxxxxxxx > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
