WLCG AuthZ Call
Previous Actions:
- Action: Tom to send an email to request topics and issues for discussion, and then we can plan a schedule of meetings upcoming
- Done - initial plan to focus on Accounting & Tokens
- Will ping for further requests
- Action: Maarten to tidy up and review open issues and pull requests for the token profile, and then circulate a potential 2.0 draft
- Action: Maarten to look at reviving the RTE Task Force
Proposed agenda:
- Token Accounting Cont.
- Profile updates.
Zoom meeting:
Link below, in the videoconference section. Please ensure you are signed in to Indico to see the meeting password!
Next Meeting:
- TBC
Present: Adrian (APEL), Berk, Dave D, John, Maarten (notes), Matt, Mia, Mischa, Patrick, Petr, Roberta, Stephan, Tom
Notes:
Petr asks what the plans are for updating the IAM services at CERN? Berk answers 1.12 is being tested and if all looks OK, upgrades can be scheduled in 2 weeks. Furthermore, a 1.13 test image will be stress-tested in the next days, to see by how much the token rates improve when access tokens are no longer stored in the DB. Petr is particularly interested in the storage scopes patch that was backported to 1.11.2. Berk replies he will update the services to that version if he happens to find a blocker with 1.12.
Berk reports he has prepared an improvement for the way the CERN IAM instances get the CA trust anchors updated: currently there is a dependence on CephFS shares that have caused us some problems, while the new way has that functionality provided by a sidecar. He will first have it checked by the Kubernetes hosting team.
Next week, the small VOs will have the VO root automatically added as a group to each new account, as already done for the LHC experiments. Also, the CMS instance now allows secondary CERN accounts to be linked to IAM accounts. Quite some MRs have been prepared by Mia and Patrick, waiting to be reviewed. For example, a new GUI button that can be configured to point to a page with details for getting help, which is particularly important for the small VOs.
Next, Maarten will inform the WG when he has made progress with the MRs for the WLCG token profile. For the accounting, the HTCondor devs need to check, merge and release the patches provided by Petr. We then can again ask 1 or 2 volunteer sites to try it out, before looking into a deployment campaign, for which we can use the WLCG repository for convenience. The HTCondor+Slurm use case will also need to be checked further, but only affects a few sites. Reviving the Resource Trust Evolution (RTE) WG remains on the to-do list as well. Matt points out there is an overlap between the RTE WG and the Token Trust and Traceability (TTT) WG. Maarten replies such overlaps are to be expected between the various WGs and TFs looking into different aspects of security framework evolution. From time to time, the bigger picture can be presented to a wider audience e.g. in Open Technical Forum meetings, while for meetings dedicated to a particular topic we may need more than the usual 1-hour slot, at times.
Petr asks what the plans are for allowing long-lived tokens: will the TTT WG deal with that and will the token profile be updated accordingly? To both questions the answer is yes. In v2.0 of the profile we will at least need to indicate that short lifetimes are recommended by default, whereas for certain workflows, e.g. involving FTS or grid jobs, longer lifetimes are deemed acceptable, because of mitigating circumstances in scopes and/or audiences. Today, experts know where to ignore what v1.0 of the profile says: we want to rectify those areas for v2.0.
Next, Petr reports an issue observed in ATLAS and other VOs: when a service account is moved to a new owner (because the previous owner has moved on), its CERN employee ID will change and IAM will get out of sync. Was that handled better in VOMS(-Admin)? Maarten replies the same happened in the past. Berk replies that IAM 1.12 has functionality to deal with service accounts better: the AUP can be disabled for them, but possibly more could be done. He proposes to follow up offline. Petr adds that account suspension is driven by the HR DB and hence the person ID. Berk replies the person ID is just a label that can be changed through the API. Maarten suggests that service accounts could be exempted, but Petr is concerned about service accounts becoming orphaned without anyone noticing. To be continued.
The next meeting is tentatively planned for July 10, but may be canceled if there is little to discuss. Because of another engagement, Maarten may join a bit late.