[Freeipa-users] Re: Administration delegation for multiple hosts services

From: Alexander Bokovoy <abokovoy(a)redhat.com&gt; Sent: Wednesday 29th April 2020 15:48 To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org&gt; Cc: Julien Rische <julien.rische(a)cern.ch&gt; Subject: Re: [Freeipa-users] Administration delegation for multiple hosts services On ke, 29 huhti 2020, Julien Rische via FreeIPA-users wrote: >Hello everyone, > >To properly support load-balanced services, we need FreeIPA-managed service >hosts to be able to retrieve the following elements, without the intervention >of any user (only starting with the host keytab): > >- Keytab containing keys for: >    - Service canonical principal >        - When accessed via service DNS alias (Kerberos rDNS lookup disabled) >    - Service principal alias for host >        - When accessed via service DNS alias (Kerberos rDNS lookup enabled) >        - When accessed via host canonical FQDN >- X.509 certificate for: >    - Service alias FQDN >    - Host actual FQDN > >In order to obtain each element of this list, we need to: > >- Allow the host to retrieve the service key >    - Creation/reset of the key should be forbidden >- Allow the host to request a certificate for both its own FQDN and the service >  DNS alias (which matches the service canonical principal) >    - Preferably only these 2 subject names should be allowed >- Create a service principal alias matching the host's FQDN > >We are managing hundreds of services spread across tens of thousands of hosts. >Each service is managed by a different user group, hence we can't afford to >grant all these users the "Service Administrators" privilege. > >Ideally, each service would be configured just once (with just maybe a few >exceptional updates). On the contrary, hostgroup(s) containing the service >hosts would be continuously updated. This way, FreeIPA administrator would give >their blessing at service creation, and then let service administrators manage >hosts membership. > >We think the following configuration could be applied for each service: > >- A hostgroup containing all the service hosts, allowed to: >    - Retrieve the service key >    - Request certificate with alternative suject name by: >        - Being assigned the to "managedBy" service attribute >        - Or being granted the permission to write the "userCertificate" >          service attribute >- A service administrators group, allowed to: >    - Write the "member" attribute of the hostgroup >    - Create/reset the service key > >The keytab creation/retrieval part is quite straight forward to deal with. But >this is not necessarily the case for certificates and service principal aliases: > >We observed the "managedBy" setting has 2 downsides: > >- It grants the host the permission to request a certificate with subject >  alternative names, but it also grants the permission to create/reset the key, >  which we don't want. >- It consists of a list of hosts that must be continuously maintained, since it >  cannot refer to the hostgroup directly. > >Therefore it seems that a permission granting the hostgroup to update the >service's "userCertificate" attribute sounds more flexible. But both options >have the downside of granting any host from the hostgroup to request any other >as the alternative subject name. > >Regarding the service principal aliases, we haven't found any way to >dynamically update the list as the service hostgroup changes. We could either >grant the service hostgroup the permission to update the "krbPrincipalName" >service attribute, but it sounds like an excessive permission. We could also >implement a background service continuously updating principal alias list of >services according to their associated hostgroups. > >So I would summarise my questions this way: > >- Are assumptions used in this message true? Yes. Quite good summary, thanks for that. >- Is granting write permissions on "userCertificate" service attribute the best >  alternative to "managedBy" for our use case? With FreeIPA 4.8.4+ we have support for member managers which define who can write to the member attribute of the group. See https://freeipa.readthedocs.io/en/latest/designs/membermanager.html for more details. Since this applies to any group, you can have a service administrators group to manage a hostgroup membership and to define a group that has write permissions to userCertificate through the normal role/permissions mechanism.

>- What is the best way to keep a service principal alias list up-to-date with a >  hostgroup? To add a KrbPrincipalName alias to a specific service principal on a hostgroup change, it is probably would be easier to extend automember feature (see details in 'ipa help automember'). Right now it is hard-coded to use two types: hostgroup and group even though automember plugin in 389-ds allows to define an attribute that would be used for grouping feature and define what entry's attribute to use to populate the value. The problem is that it only takes a value as it is from the entry, there is no way to transform it to some other value. If you'd look into install/updates/40-automember.update file, you'll see that hostgroup poluation is taking a 'dn' value of an entry and asks to add that as a 'member' of a hostgroup: dn: cn=Hostgroup,cn=automember,cn=etc,$SUFFIX default: objectclass: autoMemberDefinition default: cn: Hostgroup default: autoMemberScope: cn=computers,cn=accounts,$SUFFIX default: autoMemberFilter: objectclass=ipaHost default: autoMemberGroupingAttr: member:dn So I would imagine that one could do something like that for krbPrincipalName:some-attribute. And that 'some-attribute' needs to be populated in the (host) entry itself to be used by the automember plugin. This is not implemented right now in the 389-ds automember plugin. To dive deeper into a rabbit hole, we can generate krbPrincipalName in the service entries with the help of CoS plugin. This is a bit more weird plugin and you need to read a lot of details about it in RHDS documentation, but you can see how I did desktop profile rules pull into a host entry with https://github.com/abbra/freeipa-desktop-profile. Specifically, https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/updat... defines CoS configuration that pulls ipaDeskData attribute into the host entry.

> >Since it is my first message on this mailing list, I would like to pay tribute >to the development team of FreeIPA and its community. Even if there is still >work to do, FreeIPA is a quite impressive piece of work given the complexity of >the environment it is trying to integrate into, and the variety of use cases it >has to support. > >Kind regards, > >--- >Julien Rische >Systems engineer >CERN -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland