Hostgroup Managers in FreeIPA

Last article I discussed delegating the authority to manage group membership using FreeIPA. A related topic delegating the ability to manage groups of hosts. There are two different collections for managing hosts: host groups, and netgroups. The approach to delegating authority for managing each of these is similar, but with important differences. First up: hostgroups.

To create a hostgroup for Beowulf hosts:

[root@f16server ~]# ipa hostgroup-add beowulf-hosts
Description: Hosts for the Beowulf project
-------------------------------
Added hostgroup "beowulf-hosts"
-------------------------------
  Host-group: beowulf-hosts
  Description: Hosts for the Beowulf project

Unlike the user groups, there is no preset form of ACI Permission for specifying a host group. Instead, we will have to specify the LDAP object that we wish to grant permission on. Again, it will be on the “member” attribute. Lets look at what we just created. To Look at the underlying LDAP object of something in FreeIPA, we use the entity-show command coupled with the –raw and –all flags

[root@f16server ~]# ipa hostgroup-show beowulf-hosts --all --raw
  dn: cn=beowulf-hosts,cn=hostgroups,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
  cn: beowulf-hosts
  description: Hosts for the Beowulf project
  ipauniqueid: 70999114-5513-11e1-bde4-525400ff995b
  mepmanagedentry: cn=beowulf-hosts,cn=ng,cn=alt,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
  objectclass: ipaobject
  objectclass: ipahostgroup
  objectclass: nestedGroup
  objectclass: groupOfNames
  objectclass: top
  objectclass: mepOriginEntry

In order to specify this object, we will use the combination of the objectclass an a unique identifier. The best unique ID is the text value of the host group name, held in the common name field: cn: beowulf-hosts. THe appropriate objectclass is ipahostgroup, as that is the only one that indicates this is a group of hosts, all of the other objectclasses can potentially be used for other things. Here’s what creating the ACI Permission looks like (to include adding it to the privilege).

[root@f16server ~]# ipa permission-add 'beowulf-hostgroup-modify'  --permissions=write --attrs=member  --filter='(&(cn=beowulf-hosts)(objectclass=ipahostgroup ))'
-------------------------------------------
Added permission "beowulf-hostgroup-modify"
-------------------------------------------
  Permission name: beowulf-hostgroup-modify
  Permissions: write
  Attributes: member
  Filter: (&(cn=beowulf-hosts)(objectclass=ipahostgroup ))
[root@f16server ~]# ipa privilege-add-permission beowulf-manage --permission=beowulf-hostgroup-modify
  Privilege name: beowulf-manage
  Description: Manage the Assets of the Beowulf project
  Permissions: beowulf-manage, beowulf-manage-group, beowulf-dns-manage,
               beowulf-hostgroup-modify
  Granting privilege to roles: beowulf-managers
-----------------------------
Number of permissions added 1
-----------------------------

Since the user admiyo already has a role that contains this privilege, that user should now be able to manage adding and removing hosts from that host group.

[root@f16server ~]# kinit admiyo
Password for admiyo@F16SERVER.AYOUNG.BOSTON.DEVEL.REDHAT.COM: 
[root@f16server ~]# ipa hostgroup-add-member beowulf-hosts --hosts www1.ayoung.boston.devel.redhat.com
  Host-group: beowulf-hosts
  Description: Hosts for the Beowulf project
  Member hosts: www1.ayoung.boston.devel.redhat.com
-------------------------
Number of members added 1
-------------------------

It took me a few tries to get the filter correct for this one. Note that the operators are prefix. Some filters will get through the CLI fine, but won’t select the object you want. To confirm that you do have the right object, I recommend using ldapsearch to get the query right before adding the permission.

[root@f16server ~]#  ldapsearch -x -b "dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com" "(&( cn=beowulf-hosts)(objectclass=ipahostgroup))"
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (&( cn=beowulf-hosts)(objectclass=ipahostgroup))
# requesting: ALL
#

# beowulf-hosts, hostgroups, accounts, f16server.ayoung.boston.devel.redhat.com
dn: cn=beowulf-hosts,cn=hostgroups,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
objectClass: ipaobject
objectClass: ipahostgroup
objectClass: nestedGroup
objectClass: groupOfNames
objectClass: top
objectClass: mepOriginEntry
cn: beowulf-hosts
description: Hosts for the Beowulf project
ipaUniqueID: 70999114-5513-11e1-bde4-525400ff995b
mepManagedEntry: cn=beowulf-hosts,cn=ng,cn=alt,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com
member: fqdn=www1.ayoung.boston.devel.redhat.com,cn=computers,cn=accounts,dc=f16server,dc=ayoung,dc=boston,dc=devel,dc=redhat,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

2 thoughts on “Hostgroup Managers in FreeIPA

  1. Hello Adam,
    Thanks for the post. I see its a pretty old post. but let me try my luck!

    In my use case i have two hostgroups and i have two admins – i want admin of one hostgroup not be able to add or delete the hosts from other hostgroup and vice versa. the setup you have mentioned makes the admin to add or delete any hosts which i dont want. I want to restrict to based to only those hosts those are part of the hostgroup i have created. Any idea how this fine-grained access control can be achieved in freeIPA?

  2. So, creating or deleting hosts is one operation. Adding the host to a hostgroup is a separate operation. I have not done anything in this post to lock down who can/cannot add or delete hosts.

    (cn=beowulf-hosts) means that the permission added is only applicable to the beowulf-hosts hostgroup. Thus if user1 should be able to add/delete to/from hg1 and user 2 should be able to add/delte to/from hg2 the corresponding cns in the ACL should be (cn=hg1) and (cn=hg2).

    I suspect that the follow on rule would be that, before deleting a host, it should be in 0 host groups but I don’t know how to enforce that…..

Leave a Reply

Your email address will not be published. Required fields are marked *