Proposal: FreeIPA Role for Fedora Servers Using Cockpit

At last week’s Fedora Server Working Group meeting, we encountered some confusion as to what exactly a role should look like. We seemed to be of differing opinions, technologically, on how to implement the roles. I recommended that we take a step back and try to design the user experience that a role should accomplish first. I recommended that we probably wanted to take one example and provide a user story for it and use that as a straw-man to work out the more general cases of server roles.

What is FreeIPA?

FreeIPA is a comprehensive identity-management and domain controller system, providing LDAP and Kerberos services.

How would I get it up and running?

Traditional APproach

In the world of Fedora 20 and earlier, the expected behavior would be that the user would first install the appropriate set of packages (either as part of installation using the GUI or kickstart or by installing the packages manually using yum on a running system). They would then run a command-line tool (ipa-server-install) to perform the configuration and initial setup of the domain (being prompted with a lot of low-level information). Joining other machines to that new domain would then be done manually or via scripts using other command-line tools.

The process to enroll additional FreeIPA domain controllers (aka replicas) is very similar: install all of the patches and then run ipa-replica-install, providing the necessary configuration information in an answer file or interactive prompt.

Role-Based Approach

The goal of the role-based approach would be to present the minimal amount of information to the user necessary to produce a working FreeIPA domain. Additionally, it should be easy to determine from a management console which machines are configured in this manner. For this proposal, I am going to use a hypothetical Cockpit role interface to describe and illustrate the process. Please note that these are mock-ups and not representative of a final design.

Top-level Cockpit View

Once we connect to the machine, we would first want to examine the roles currently assigned to that machine.
roles-2Presuming that the FreeIPA/Domain Controller role is not already on the machine, we would then elect to deploy one there. (We’ll assume this is the first such machine now and defer discussion of replicas).

roles-3

From here, we select the FreeIPA Domain Controller and proceed to query the user for the minimal set of information necessary to deploy a FreeIPA server.

roles-4

Here, the minimal set of information is the domain name (which may be auto-guessed from the machine’s `hostname -d` as well).

The next step here shows the majority of the operations representative of my view of a role. It’s not enough to install the necessary packages and then leave things to the administrator to complete (or script) the setup. Up until this point, we are doing the information-gathering for a role deployment.

roles-5Here, we demonstrate the actual deployment of a role. At this point, Cockpit (or whatever other management tool we are using) should be relaying the gathered data to the managed system and the role-installation mechanism should take over. In the FreeIPA case, this means:

  • Package Installation
  • Hostname/Domain configuration
  • Installation and configuration of the FreeIPA server (unattended execution of ipa-server-install)
  • Opening of the appropriate firewall ports
  • Configuring the services to start immediately and persistently

Once installation is complete, we should be able to view the status of the FreeIPA services through either the role or services tabs in Cockpit. This display should also include a link to the FreeIPA Web UI for full management.

roles-7

Additionally, the role interface should also offer simplified deployment of descendant roles, such as adding DNS services to a FreeIPA domain, but that’s not currently represented in the mock-ups (due to time-constraints).

All images above are copyright “The Cockpit Project” and licensed CC-BY-SA 3.0.

About these ads

5 responses to “Proposal: FreeIPA Role for Fedora Servers Using Cockpit

  1. Roles are explicitly for managing ACLs on the Directory server. We’ve looked in to expanding the use of roles beyond that, and there are a couple of reasons to resist.

    First is that there is a lack of standards of what roles should look like. I think that is what you are trying to address in this article.

    Second, and probably as important, is that a Role is only for cross cutting concerns in the Identity Management domain, so for HBAC etc, yes. But not for roles in an application deployed on top of an IPA based system. The term I’ve used in the past is “centralized authentication, local authorization” for that.

    Note that I wrote up several blog posts about delegation and roles in FreeIPA a few years ago that describe how to manage a subordinate grouping, whether for users, hosts, or DNS:

    http://adam.younglogic.com/2012/02/group-managers-in-freeipa/
    http://adam.younglogic.com/2012/02/hostgroup-managers-freeipa/
    http://adam.younglogic.com/2012/02/netgroup-managers-in-freeipa/
    http://adam.younglogic.com/2012/02/dns-managers-in-freeipa/

    I would suggest that there be two roles to support the above use cases:

    1. host-enroller: this would be a minimal role used only for enrolling hosts that do not have an OTP and host entry in FreeIPA prior to enrolling. It would bascially put a host in “enrolled, least priviledges” mode.

    2. replicator: for setting up replication agreements.

    Deploying a FreeIPA server obviously is going to predate any roles enforced by the IPA server. I am assuming that you are talking about using the term Roles for an application that is then going to deploy FreeIPA for you. “The goal of the role-based approach would be to present the minimal amount of information to the user necessary to produce a working FreeIPA domain.”

    A role is typically a grouping of finer grained permissions. The idea is that by granting someone a role, you are granting them all of the permissions they need to get a specific job done.

    • I think I may have been unclear in my explanation above. Unfortunately, there’s an overlap on the term “roles”. I was actually talking about roles of a MACHINE, not roles interacting with FreeIPA. (“Role” is almost as bad as “domain” for overuse).

      I’m talking about server roles. So things like saying “That (physical or virtual) server over there is now a FreeIPA domain controller” and “That one over there is a PostgreSQL database server”. Basically, package installation plus minimum configuration to make it useful (if not efficient).

  2. Pingback: Fedora Server Working Group: Dec 3 Meeting | Fedora Server Working Group

  3. Dave Malcolm

    If I understand your proposal correctly, some synonyms for the meaning of “role” that you’re using are:
    * “duty”
    * “responsibility”
    * “assignment”
    * “mission”
    along with synonyms like “task” and “function” which are clearly not usable due to overuse elsewhere. FWIW I rather like “duty”/”duties” as a term.

    Hope this is constructive

  4. I would just like to say this looks weary cool. i hope some thing like this gets implemented in Cockpit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s