[Gluster-infra] Centralized syslog, and freeipa in place

[Michael Scherer]

Le vendredi 13 novembre 2015 à 13:36 +0100, Niels de Vos a écrit :
> On Thu, Nov 12, 2015 at 11:33:03PM +0100, Michael Scherer wrote:
> > Hi,
> > 
> > so i managed to finally make freeipa work as I want with salt, so now,
> > any EL 7 system installed and added to salt is automatically added to
> > freeipa.
> > 
> > So that mean that we have a proper central authentication system, which
> > can be used to distribute ssh keys as well, and can manage certificates.
> 
> Nice, great progress!
> 
> We currently have a "Workflow Guide" [1] that I would like to see
> renamed to "Contributors Guide". I think that would be a suitable place
> to start documenting bits about the infrastructure. Could you put some
> things together there so that others can follow a little more what you
> are doing?

yeah, i was not sure on where to document infra. I wanted to go on the
wiki, since that's not gluster documentation, but maybe a different git
repo would have been good, or some place on the website. 

I will take a look.

> > Which bring me to the 2nd part, ie secure syslog centralisation for the
> > servers that we converted ( as I need to have a CA/ssl certification
> > system for syslog over the internet ). 
> > 
> > next stuff to do:
> > - make sure we have a replica of the freeipa setup
> > - add more server in the pool ( for now, only a few EL7 are there )
> > - convert the jenkins host to EL7 and start to use LDAP based access 
> > 
> > This also bring the question of "how do we give access", ie what kind of
> > organisation do we want.
> 
> Could you give an example or suggestion on what you mean by this?

In the old model, the download mirror was open to a lot of people, as
root. Which had the unfortunate consequence of making it unadutiable and
giving too much access to too much people. 

I would like to have a identified set of people with upload access, a
identified set of people with jenkins access, etc, etc, and say "this is
the group of people who are responsible for the jenkins builder", and
have a unified access. IE, if you have access on the interface as admin,
we also expect you to have access by ssh on the builder and expect you
to fix builder issues. 

If you have access to upload stuff, then you are some kind of rel-eng,
and so expect everybody in the group to have the same access and duties.

Kinda like the group in our github org.

Otherwise, we will struggle to know who take care of what, and who have
what access. Since for example, we used every possible way to use sudo
( ie, group based, config /etc/sudoers based and /etc/sudoers.d/ based
), it was a pain to audit what access could have been compromised or
not, and to revoke the access.

With a group based framework, we would just say "this access was
compromised, so we remove it for now" and that's it. And "we have this
person to access, we add it", and no more searching for what is missing.

When someone leave the community (for good or jsut go on vacation), we
can see where we are missing people directly, etc, etc.


-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20151113/d79a34e3/attachment.sig>