On 2017-06-12 10:50, Florence Blanc-Renaud via FreeIPA-users wrote:
> Hi,
> 
> the team is starting investigations regarding the deployment of IPA
> using Ansible, and we would like to get community feedback. Ansible
> already provides a few community-maintained Identity Modules [1]
> allowing to manage users, groups, hosts, hbac rules, roles, sudo rules,
> but in a first phase, we are focusing on IPA client installation.
> 
> The command line ipa-client-install is configuring various components
> (hostname, NTP client, IPA client, SSSD, PAM and NSS, Kerberos client +
> host keytab, DNS, ssh, OpenLDAP client, NIS, automount, firefox prefs...)
> Because of this modularity, a possible strategy would be to provide an
> Ansible role for ipaclient, decomposing the installation into reusable
> Ansible parts (kerberos client role, OpenLDAP client etc).
> In order to avoid maintaining 2 different installation mechanisms, we
> could rewrite ipa-client-install so that it internally calls Ansible to
> perform the configuration. Note that this would include a new dependency
> on Ansible, and we need to make sure that this is acceptable, keeping in
> mind that we are not targeting only RHEL and Fedora but also other Linux
> distributions.
> 
> Another strategy would be to have Ansible call the current
> ipa-client-install command, but the limitation is that this CLI is not
> idempotent. It exits on error when the host is already configured as an
> IPA client.
> A few community-provided IPA roles (client or server) are already using
> this approach. They can be found in Galaxy [2].
Thanks for your summary, Flo.

It sounds like we both agree that the second strategy (simply run
ipa-client-install and catch error) is not the best approach. The
simplistic variant has multiple issues. On the other hand
ipa-client-install does a lot of stuff. I don't think we can deliver a
full replacement in Ansible within the development phase of 4.6 or 4.7.
It may be more feasible to augment the ipa-client-install command and
expose installation steps as subcommands? A check or state subcommand
could be added to get the installation state.

$ ipa-client-install check
$ ipa-client-install enroll
$ ipa-client-install dns
$ ipa-client-install openldap
$ ipa-client-install ssh-client
...

The subcommands and checker could be re-used by puppet, too. What do you
think?


My biggest concern is insecure enrollment with username and password.
Every playbook I known -- including my own one -- passes username and
password to the client machine. For Ansible automation, we should not
use admin credentials but rather push for OTP. To make OTP enrollment
work idempotent, multiple steps with extra checks are required. The OTP
approach eliminates the need to delegate GSSAPI to a client machine.

Example:

* A->C check if client is IPA enrolled
  * A->I check if client has a host entry
    * A->I create host entry
  * A->I generate OTP for host entry
  * A->C enroll client with OTP

A: Ansible control machine
C: new client machine
I: IPA master

Regards,
Christian


-- 
Christian Heimes
Senior Software Engineer, Identity Management and Platform Security

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to