On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote: > On ke, 14 syys 2022, Stephen Smoogen wrote: > > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy <abokovoy@xxxxxxxxxx> > > wrote: > > > > > > > > Sadly, it cannot be just 'any' certificate, it has to be issued by a > > > certificate authority that is trusted by the KDC as well. For example, > > > by FreeIPA CA which is already ran by the Fedora project infrastructure > > > team. An alternative is to set up certificate mapping and validating > > > rules. > > > > > > If someone from Fedora Accounts team wants to experiment with this, I > > > can guide you what to do. > > > > > > > There is no continual running Fedora Accounts 'team'. There are 2-3 system > > administrators split between releng, operations and continual > > firefighting. There are also a team of developers who are split between > > CentOS Stream initiatives and other work. Changes like this need to have > > more than just an 'oh I have finally an afternoon free where all the other > > crap in the build infra is actually working for once.. lets dive into IPA' > > I understand all of that myself. I think what is important here is to > plan to work together so that eventually we can implement this. Right and while I agree with what smooge says there, I'm definitely interested in improving things as we can. I really would prefer a detailed plan however, not 'lets enable everything we can and see what sticks'. :) > This whole thread is about agreeing or disagreeing whether Fedora as a > project would want to have better security methods to identify and > authenticate its contributors when performing tasks that have large > impact. Yep. I'm in agreement that we want to... but there's always tradeoffs. A few random things to mention: * I don't think requiring FIDO2 for all packagers is tenable. It may well be that we could get donations or funding to get hardware for all packagers, especially if we wait for the current inactive process to finish, but even so, we will run into problems of people who can't get one shipped to them or gets lost in the mail, etc. There would also be a delay "hey, you are now a packager, look for a token in the mail in the next few weeks before you can do anything" * I'd really prefer to avoid going back to certs. People have all kinds of problems with certs. I think it would cause a lot of confusion. (Unless I am misunderstanding what use is proposed for them). > If Fedora contributors would have had access to Fedora's FreeIPA web UI We actually do have external access to the web UI. We just don't advertise it much. > or IPA API directly, we wouldn't even need to have a conversation about > PKINIT and certificates. We could have added instructions how to request > and associate a certificate with your account. But since Fedora Accounts > system is the frontend to Fedora Project's FreeIPA deployment, we cannot > simply do that. However, FreeIPA-wise, smartcards are supported now for > Kerberos authentication, so we as Fedora contributors could benefit from > that. What would this use of certificates do here? Authenticate you to get a kerberos ticket? Allow you to login to the account interface? CentOS folks still use certs for their koji: https://wiki.centos.org/Authentication#TLS_certificate (and thats using the same account system/ipa servers as fedora). > I hope we can plan to work together on this improvement again, similar > how we did with the initial rewrite of Fedora Accounts on top of > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, > perhaps CPA team could consider scheduling this effort as part of the > initiatives. Yeah, I would like that. Perhaps we could setup a meeting soon and dicuss plans? I'm open to video meeting, but we could also do IRC to keep things more open... > Let me round up methods that we have supported now or plan to add in > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to > issuance of a Kerberos ticket that can be used for communicating with > the rest of Fedora services: > - basic password-based authentication > - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an > external RADIUS server for validation of a string passed as > a 'password' or 'token' value > - use of a certificate stored on a supported PKCS11 token (smartcard, > softtoken (SoftHSMv2, NSS) or just in plain keypair files) > - use of OAuth2 device authorization grant against some OAuth2 IdP (new > in FreeIPA 4.9.10+) > - (future) use of a FIDO2/WebAuthn token > > Fedora accounts system implements the management of the first two > methods right now. And possibly the 3rd... What does 'device' mean in the 4th one? :) We do have https pushes using oauth/oidc token right now. Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh keys and thus use FIDO2 for ssh actions if we wish. > > As much as I enjoy better security, everyone should remember that the ones > > affected are either packagers who are volunteering to make spec files for > > software they need for something else.. or developers who only look at spec > > files as the last hassle they need to do before they can mark on their list > > 'shipped and done'. Most of them do not package/build things very often, > > and it takes years for them to get retrained when some change in the > > workflow occurs. > > A particular benefit of using Kerberos authentication to Fedora services > is that it does not need to change the workflow for all those things. > Once you've got your ticket, it works against all the services you are > allowed to access. Sure, actual process of obtaining that ticket might > change -- like with 2FA token one needs to get a wrap ticket first -- > but the rest is the same. Yeah, it's much nicer when everything uses a standard thing and all the various flows stick to that. Right now our auth for commits to src.fedoraproject.org is anything but standard. https and ssh use different paths and this causes a bunch of confusion. > > > They are also the only ones around to do the work. Making workflow changes > > like adding certificates, tokens, etc may be needed but they are going to > > need a lot of documentation, continual training, and coaching to actually > > make function. If there is no staff or people available to do this, then > > the change will fail hard. > > Do we have any statistics of how we stand now that Fedora Accounts is > deployed for more than a year and people were enabled to use 2FA tokens > through it? I could try and gather some. What stats would be helpfull? kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
