Choose timezone
Your profile timezone:
Token Trust & Tracebility WG August 2024 Call
→
Europe/Zurich
Token Tracebility and Traceability WG
TTT 27th August 2024
===
Attending: Matt, ML, HS, MH, JCL
Apologies: Linda, DaveK, TomD, DavidC
Actions
---
Matt: Make a start on the CHEP submission. Done (for certain values of done). See later.
CHEP submission
---
See google doc sent to the list. General request for input, although I realise there's a lack of real content to comment on.
Marcus' AARC-G081 Token Lifetime Recommendation draft is a strong influence.
Trying to distill information from our meetings, but there's always the chance I grabbed the wrong end of a stick somewhere.
--ML had some feedback, on the decisions being "per workflow".
Eventually will endorse configrations/practices.
Best practice informs polices. This will (perhaps) move this responsibility from the AuthZ group to the TTT.
IAM has a policy engine that is up for replacement (with a better one), to avoid random people being able to do too much. This is months away though.
Things to aim for.
Marcus mentions the token lifetime document, had some "negative" feedback about what should be in there. Move impact assessment to appendix, and just give min/max guidence on lifetime, and suggest scoping and limiting the token elsewhere.
Will discuss document in AARC architecture group, and will invite this group as a stakeholder.
Impact already moved to the Appendix.
ML reminds us that we can have things better then we ever had it, but don't need to be perfect right away.
Marcus wanders if there's scope for excepting "expired tokens"
-ML, already the case for some refresh tokens, which have a grace period in IAM and US implimentations.
Hopefully we don't need to make use of this.
Was discussed in a recent-ish AuthZ meeting, but the consensus there was also it shouldn't have to be used.
JCL - notes that having a grace period is essentially just default extending the lifetime. Not something that is enabled by default.
MH - not quite the same, as limit scope after the grace period.
ML - Describes case of ALICE output files, known well in advance - give a long lifetime with incredibly fixed scope rather than relying on refresh/grace period.
-a corner case, but something we can have an "opinion" on.
--note to refer to Marcus' document in the presentation, a few summary bullet points etc, and how it fit.
--traceability and logging examples, shared in gitlab example from HS, xrootd example. Awareness of what a token "looks like", to prevent accidental sharing.
JCL mentions that credentials that shouldn't be in the URL, we all agreed.
ML almost punished for making tokens so small, easy to put in URL.
Notes the DC experieince, locking down of FTS logs, FTS devs redacted the logs from the code. Xrootd devs not keen on changing the way of doing stuff.
This might require a major protocol increase before we can change this and rely on it everywhere.
FTS/Xroot workshop in a few weeks, Matt will ask some colleagues who are going to ask about this.
Matt to inform the TTT list with any decent sized updates.
Issues in GIT
---
A simple reminder, thanks to Mischa for the comments:
https://github.com/TTT-WG/TTT-WG/issues
Can use this to inform the subject of future meetings.
Setting some Objectives/Deadlines
---
CHEP is a good start.
Leave discussing this until CHEP is behind us.
Previous examples of efforts (like xrootd docs from earlier).
Brainstorming for
ML- note that the CHEP presentation is an output.
We are still early days.
ATLAS have started testing new model for rucio to interact with FTS and IAM, using lessons learned from the DC. Hope it will all be fine, but currently the tests are low rate so maybe we have scalability issues. Not storing token in DB needs new version.
--tokens per file for real production transfers, scratchdisk endpoints. Will move to proddisk.
tokens long lived, so no need to deal with refresh, if token runs out of time transfer just fails, which we can live with.
for reads we should take advantage of an observation of the fact that in a VO there are no secrets, so can give a wide scope for a token withread access across the space.
But even if reads get own tokens we can manage.
We can perform a risk analysis on this once its settled.
Let's not produce somethign quickly of limited value.
All to be discovered in the autumn.
Rucio knows it needs to be able to cope with mutliple user methods (for example astronomers). FTS will support two code paths to deal with the wide scope of methodologies.
We will be in a good position if we can reduce the read token rate to (almost) zero.
Discussion
---
See above :-)
AOB
---
Next Meeting
---
Matt's on leave for the next "regular" meeting date of the 24th of September, shall someone else take the chair or would we rather shift to a convenient slot at the start of October?
Will arrange an Ad Hoc meeting, Matt will do a doodle.
There are minutes attached to this event.
Show them.
