[CentOS-devel] Switching to centralized authentication for centos.org infra (aka FAS vs IPA)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/11/14 14:29, Xavier Lamien wrote:
> Greetings folks,
> 
> As the principal FAS upstream, I would like to help you guys out
> making - as much as possible - (the right?) move by having the
> right information.
> 
> First of all, let's start by a short FAS introduction.
> 
> FAS has been designed to be community oriented by providing to the 
> community a way to operate by itself through teams management (i.e
> group membership/management). As a result, our web interface has to
> be more than just an administrative interface to manage users &
> groups like other does. I recommend to go read more about it at
> https://admin.fedoraproject.org/accounts/about before go further.
> 
> While keeping the openness, we also added: 1. A plugin Interface
> which let you add any new feature Plugin we had developed: *
> asterisk (no longer in prod however the plugin still is maintain) *
> yubikey (some of our group requires their members to have a key to 
> access bound hosts) * OTP 2 factor auth (in a branch)
> 
> 2. A non-standard API (current master) which let registered people 
> and/or 3rd parties (from login mechanism) to read-only from FAS.
> 
> Next is, my feedback after reviewed the wiki page and previous
> msg:
> 
>>> project URL
> 
> The project is mainly active on github (fedorahosted.org 
> <http://fedorahosted.org> has been set as backup) v2:
> https://github.com/fedora-infra/fas v3.0:
> https://github.com/fedora-infra/fas/tree/FAS_3.0
> 
>>> packages available natively in the distro
> 
> We do provide rpm's for rhel (e.g. 
> http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noarch.rpm)
>
> 
FAS v3 package will be in distro as it will be no Fedora project specific.
> 
> 
>>> multi-master replication
> 
> Is this our we can replicate FAS from a master image? I really
> didn't get that one. If someone could explain it to me, that would
> be great.
> 
> 
>>> kerberos support:
> 
> Not supported at this time. We do think of it for a v3.xx though. 
> But it's not in my priority list unless someone is interesting to
> work on it.
> 
>>> LDAP support:
> 
> FAS v2: no. FAS v3.2: yes however, the LDAP support will be for
> group and people management. We will keep the DB as FAS is not
> about user and group management only.
> 
>>> It's more or less a "Users CMDB" and cron jobs/scripts are
> creating/removing/modifying users/groups locally on each managed
> system.
> 
> Naa, we have a fas-client which actually does the job to
> synchronize accounts on hosts. fas-client has been cron'd as the v2
> is a non-daemon tools. We do have a daemon option though that
> listen to fedmsg and update hosts on demand. However, we set up a
> push-mode into Fedora infra.
> 
>>> Mainly written to discuss with the fedmsg bus, and so
>>> targetting all
> Fedora Applications
> 
> FAS has not been written to talk to 3rd parties (as stated in
> introduction). fedmsg cames few years after FASv2 launch. fedmsg is
> for FAS just another notification mechanism.
> 
>>> Written for one project
> 
> It has been the case for quite a while before I started work on
> FAS. For the record, I maintain the RPM Fusion infra and are using
> FAS there as well. even though this is related to fedora project,
> RPM Fusion are not providing the same level of services and doesn't
> have the same team structure (we don't use license agreement
> feature, nor asterisk's one, nor bugzilla feature atm).
> 
>>> but we are working on a new fas 3 version that will use flask.
> 
> Naa.. FAS 3 is a pyramid app.
> 
>>> I guess it would be easier for everybody too, as just for today
>>> I've
> read that FAS3 would be in fact based on IPA so not on the actual
> FAS setup
> 
> Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with
> our need as stated in introduction. However, we may look at their
> kerberos and directory server implementation as a plugin for FAS.
> 
> If you have any question which are not answered here, please feel
> free to ask. Also, as Kevin said, the v3 is being writing and will
> come up with lot of features so question here are much appreciate
> ;)
> 
> - Xavier
> 

(trying to resurrect that thread, as no real momentum/traction at the
moment it seems)

So, the major request is for SIGs developers to get access to our
Community Builders (http://cbs.centosr.org). We currently use a custom
wrapper/script using an internal CA to create keys/certs and have
those distributed to SIGs people having access to koji.
It's not clear if FAs provides an easy way to retrieve such key/cert
easily : as an example, I don't see any automatically created key/cert
in my FAS account when logged on
https://admin.fedoraproject.org/accounts (or is that hidden and only
available to people in certain groups ?)

To also be clear : we'll *not* switch all centos.org nodes auth to
that centralized authentication (there is no current need for that,
and especially for nodes that are just mirrors/rsync targets, on which
user accounts with rights are already managed by puppet)

So, using a centralized auth is for new apps (and then why not
considering merging existing ones to use that solution too) :
 * koji (we need the central tool to let people auto-register
themselves and retrieve their keys/signed x509 certs)
 * Git authentication : gitblit (backend for git.centos.org) supports
multiple auth mechanisms, including x509 so we'll reuse that (actually
it's only using embedded localdb for users/groups)

For the future, it would be good to see if we can centralize other
solutions to use that central auth :
 * Wiki (actually moin)
 * Forums (phpbb so probably better to not use ldap, but try to use OAuth)

- -- 

Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlR9c6EACgkQnVkHo1a+xU57owCgh6ZaGznrVFX09gPDRlMoAcG5
9n4An2ltj69qKwMLN2z08DG4V6ZvDoAA
=d2Bx
-----END PGP SIGNATURE-----