dmwm / PHEDEX

CMS data-placement suite
8 stars 18 forks source link

Grant datasvc_delete ability on T0_CH_CERN_Disk and T2_CH_CERN nodes to 'T0 Operator:DataOps' role #994

Closed nikmagini closed 8 years ago

nikmagini commented 9 years ago

As requested by Dirk:

The Tier-0 needs the ability to perform a delayed clean up of blocks from T0_CH_CERN_Disk/T2_CH_CERN after processing is complete.

Currently this is performed granting the 'Data Manager' role in SiteDB on T0_CH_CERN/T2_CH_CERN to the Tier-0 service certificate:

https://cmsweb.cern.ch/sitedb/prod/people/tier0%40vocms15.cern.ch

But this is potentially dangerous because it also allows the Tier-0 to delete blocks from T0_CH_CERN_MSS

Since the service certificate also has the 'T0 Operator:DataOps' role in SiteDB, it would be better to grant a 'datasvc_delete' ability to this role, restricted to the required target nodes.

The datasvc authz supports node regexps for scope, so IIUC it would be sufficient to add a line like this to the datasvc conf:

https://github.com/dmwm/PHEDEX/blob/master/PhEDExWeb/DataService/conf/datasvc-app.conf

auth: datasvc_delete:^(T0_CH_CERN_Disk|T2_CH_CERN)$:cert:T0 Operator:DataOps

Cheers N.

TonyWildish commented 9 years ago

that ought to work, but: the datasvc-app.conf file is no longer picked up from PhEDEx. Lassi 'stole' it from us a few years back, and put it under HTTP group control. It's now located at https://github.com/dmwm/deployment/blob/master/phedex/app-datasvc.conf.

I don't want to delete the file from PhEDEx, it's still a useful reminder of the format to have it there, but we should at least document it internally. I'll take care of that.

TonyWildish commented 9 years ago

I've added that 'auth' line to the config file in https://phedex-dev.cern.ch/, so now we just need someone to test it there. The test procedure should verify that:

1) someone with the 'T0 Operator:DataOps' role can still delete from T0_CH_CERN_Disk and T2_CH_CERN* 2) that same person should not be able to delete from T0_CH_CERN_MSS

I guess the easy way to test that is to inject a fake block of data (in the Debug instance, preferably) and then try to delete it. Possible approaches for that are:

a) load the 'T0 Operator:DataOps' certificate into a browser (e.g. pick one of Safari/Firefox/Opera/Chrome that you don't normally use and use it for this test) and see if you can (dis)approve the request correctly. b) use the datasvc API with curl or wget and specify the certificate on the command-line. This can be error-prone, but is an option.

TonyWildish commented 9 years ago

I've also added an entry for a 'T0 Delete:DataOps' role in phedex-dev.cern.ch, with the same authentication Nicolo' suggested above. So this role should only be able to delete from T0_CHCERN{Disk,Buffer} and from T2_CH_CERN. It shouldn't be able to delete anywhere else, nor to approve requests.

If people prefer to use that, instead of modifying the T0 Operator:DataOps role, that's an option, but again it will need testing.

T

nikmagini commented 8 years ago

Tested by Meric in a private dev instance, working as expected:

Deletion: Allowed at T0_CH_CERN_Disk and T2_CH_CERN https://phedex-datasvc-magini.cern.ch/phedex/test/Request::View?request=13506

Properly rejected at other sites:

nikmagini commented 8 years ago

Deployed in prod on cmsweb in HG1510:

https://github.com/dmwm/deployment/commit/009d7306995a0d7f4b78b5f205d5ec4e7db1e789

Closing