Hello Alexander,
Thank you for answering this quickly.
-----Original message-----
From: Alexander Bokovoy <abokovoy(a)redhat.com>
Sent: Wednesday 29th April 2020 15:48
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Julien Rische <julien.rische(a)cern.ch>
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.
The "member manager" feature looks convenient indeed to avoid configuring an
extra role and permission for the service administrators group. That's
especially something less to cleanup in case the hostgroup is deleted.
I would have 2 extra questions about the "managedBy" attribute:
- What is the exact list of the permissions it is granting (in addition to
write permission on "userCertificate" service attribute and service key
creation)?
- Would it make sense to extend its scope to hostgroups?
>- 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.
So relying on the automember plugin we could import the principal alias from an
attribute of the member host. Here also, I guess the main advantage is there
would be no need to cleanup the service principal alias list whenever a host is
removed from the hostgroup.
It's a shame we cannot generate the service principal alias itself, but I
suppose it would require some sort of string composition plugin:
===
dn: krbCanonicalName=HTTP/web.example.com,cn=services,cn=accounts,dc=example,dc=com
service: HTTP
...
dn: fqdn=web01.example.com,cn=computers,cn=accounts,dc=example,dc=com
memberof: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com
...
dn: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com
member: fqdn=web01.example.com,cn=computers,cn=accounts,dc=example,dc=com
...
dn: cn=web-krb-aliases,...
format: "%/%(a)EXAMPLE.COM"
replace: %
nparam: 2
param1dn:
krbCanonicalName=HTTP/web.example.com(a)EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com
param1attr: service
param2dn: cn=computers,cn=accounts,dc=example,dc=com
param2attr: fqdn
param2filter: (memberof=cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com)
targetdn: krbCanonicalName=HTTP/web.example.com,cn=services,cn=accounts,dc=example,dc=com
targetattr: krbPrincipalName
===
I had a look at RHDS documentation about CoS[1], it looks like a kind of
template engine. I am not sure to understand if it can be used to concatenate
multiple values. Is it the case?
>
>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
Best regards,
---
Julien Rische
Systems engineer
CERN
[1]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...